OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: Web-browser Binding Vulnerabilities + "Cures"


David,
I can't say I have tested a lot of browsers but so far as I know this method
is used by Passport.com which is the SSO of Hotmail.com
/Anders

----- Original Message ----- 
From: "Orchard, David" <dorchard@jamcracker.com>
To: <"SMTP:sach"@sap.com'
Sent: Tuesday, January 16, 2001 21:24
Subject: RE: Web-browser Binding Vulnerabilities + "Cures"


> And how do you do cross domain cookies so that domain A can send info to
> Domain B?  We haven't found many browsers that support this lack of cookie
> privacy.
> 
> Dave Orchard
> XML Architect
> Jamcracker Inc.,    14000 Homestead Dr., Sunnyvale, CA 94086
> p: 408.864.5118     f: 408.725.4310
> 
> Named to Red Herring's list of 100 Most Important Companies:
> www.redherring.com/mag/issue79/herring100/jamcracker.html
> 
> 
> > -----Original Message-----
> > From: Paulus, Sachar [mailto:sachar.paulus@sap.com]
> > Sent: Monday, January 15, 2001 11:25 PM
> > To: 'Anders Rundgren'; S2ML
> > Subject: RE: Web-browser Binding Vulnerabilities + "Cures"
> > 
> > 
> > That is what SAP experienced too. Therefore, our SSO solution uses
> > (digitally signed user info in) cookies....
> > 
> > -----Original Message-----
> > From: Anders Rundgren [mailto:anders.rundgren@telia.com]
> > Sent: Freitag, 12. Januar 2001 13:30
> > To: S2ML
> > Subject: Web-browser Binding Vulnerabilities + "Cures"
> > 
> > 
> > The following does IMO apply to many schemes including S2ML:
> > 
> > The use of references to assertions etc. in the form of URLs which are
> > usually given to an
> > authenticated client by a credential issuer using an HTTP 301 
> > (redirect) has
> > at least one
> > problem: A credential consumer cannot easily determine if it 
> > is the original
> > client that
> > handed over the URL containing such a reference. A simple 
> > browser URL window
> > snooper program could "snatch" such tokens and transport them 
> > to somebody
> > else.
> > In spite of secure https transports.
> > 
> > The only "cures" I can think of are putting the critical data 
> > in a cookie
> > [sorry :-( ], which requires a
> > fairly deep browser hack [open source would make it trivial 
> > though :-) ] to
> > snatch, and IP bindings.
> > The latter is not universal due to proxies (all clients on 
> > the same proxy
> > looks like one IP for the credential
> > consumer) etc. but it does improve the binding a bit.
> > 
> > Note: I don't insist that the current binding scheme should 
> > be changed, this
> > is simply "information".
> > 
> > Anders
> >



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC