atom feed13 messages in Web-browser Binding Vulnerabiliti...
FromSent OnAttachments
Anders RundgrenJan 12, 2001 4:32 am 
Paulus, SacharJan 15, 2001 11:25 pm 
Orchard, DavidJan 16, 2001 12:26 pm 
Anders RundgrenJan 16, 2001 1:36 pm 
Mishra, PrateekJan 16, 2001 1:56 pm 
Anders RundgrenJan 16, 2001 10:08 pm 
Orchard, DavidJan 16, 2001 10:33 pm 
Orchard, DavidJan 16, 2001 10:44 pm 
Anders RundgrenJan 17, 2001 5:21 am 
Paulus, SacharJan 17, 2001 7:16 am 
Hal LockhartJan 17, 2001 7:20 am 
Anders RundgrenJan 17, 2001 7:31 am 
Hal LockhartJan 17, 2001 8:32 am 
Subject:Re: Web-browser Binding Vulnerabilities + "Cures"
From:Anders Rundgren (
Date:Jan 16, 2001 1:36:41 pm

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

----- Original Message ----- From: "Orchard, David" <> To: <"SMTP:sach"' 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:

-----Original Message----- From: Paulus, Sachar [] 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 [] 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".