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"


Prateek
comments in line

> Before going much further into cookies, passport etc.,
> i dont understand how the scenario you have outlined
> can take place over HTTPS.
 
> > 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.
> > 
> 
> 
> My understanding is that HTTPS secures all query string
> arguments as well as any data sent in the HTTP command
> and response.
> 
> Can you explain the operation of this "snatching" scheme further?

The snatcher program is a windows (of course) deamon running outside a standard browser
that looks inside window objects.  It can even hook itself into the window messaging to get
all messages directly first.  Now, if the entire security token is given as an URL the snatcher
will see it in clear text (as displayed in the browser URL window) and could give it to somebody else.
Without hacking the browser.
Cookies on the other hand are not displayed in the browser window and therefore are slightly
better protected.

Anders




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


Powered by eList eXpress LLC