RE: How to protect against cookie stealing?

[PortSwigger <mail () portswigger net>]

Hi Rogan,

I'd prefer a JavaScript implementation of the challenge-response mechanism, 
over ActiveX or Java -- less likely to scare users that something "odd" is 
being installed, and would presumably avoid the problem you mention of access 
by other sites in the same domain?

Re the "This site requires ..." issue, it's a fair bet that the vast majority 
of ordinary users have JavaScript enabled, and so your suggestion would 
greatly reduce the transmission of the shared secret. Depending on the site's 
paranoia, they could still support the old model if JavaScript is disabled -- 
using either a cookie or a GET/POST token to store the shared secret. This 
hybrid would avoid any "This site requires ..." problems, whilst implementing 
sessions as securely as possible for each user.

That said, I can't see this sort of model being adopted any time soon, given 
the number of sites still using predictable tokens, or happy to transmit the 
token in the clear (often in the run-up to the "secure" parts of the site)! 
And Marc's point still stands that XSS etc problems could bypass any clever 
stuff implemented on the session side of things.

Cheers

> -----Original Message-----
>
> From: Dawes, Rogan (ZA - Johannesburg) [mailto:rdawes () deloitte co za]
> Sent: 28 July 2003 10:43
> To: 'Marc Slemko'; webappsec () securityfocus com
> Subject: RE: How to protect against cookie stealing?
>
> How effective is the browser security model?
>
> I'm thinking of a control (ActiveX or Java, possibly JavaScript in a hidden
> frame that persists for the duration of the session) that holds the user's
> secret, and provides an authentication token for any request that is
> submitted to the server that requires auth. The token would be dependent on
> the parameters being passed, and would effectively be a "signature" of the
> parameters. Actual implementation is left as an exercise for the reader :-)
>
> So, a request for an account balance would sign a nonce and the account
> reference, the server would verify the signature, and return the page
> requested. A request to transfer funds would sign a nonce, the destination
> account details, the amount, etc before sending that to the server.
>
> My concern is that, even if the server operator manages to completely
> secure their own site against XSS (as you rightly indicate that the
> attacker could get your own browser to submit what is needed to exploit
> you), other sites nominally in your domain (same .domain.com) could still
> access the control, and "sign requests" in your name. I seem to recall an
> advisory about this possibility on this list a while back.
>
> Benefits of this approach:
>
> * Well, it addresses Kevin's concerns that we transmit the shared secret
> when we make a request
> * we could remove the "this site requires cookies" angle, possibly.
>
> Downsides
>
> * Well, we now have the "Site requires active content and scripting" angle
>
> :-(
>
> * mathematical complexity slows performance?
>
> Comments? Thoughts?
>
> Rogan
>
> P.S. I implemented Secure Remote Password using a similar approach (Java
> applet in a hidden frame). SRP provides a method of authenticating oneself
> without actually passing the passwords across. It also provides for the
> establishment of a shared secret without passing the secret across. This
> secret could be used to encrypt the parameters, and replace them with an
> encrypted version. If the parameters decrypt OK, they are obviously valid.
> If not, discard and alert.
>
> P.P.S Unfortunately I lost my SRP code :-( , but it was not too difficult
> for a Java novice to do, so it should be trivial to redo :-)
>
> > -----Original Message-----
>
>  From: Marc Slemko [mailto:marcs () znep com]
>
> > Sent: 27 July 2003 06:32 PM
> >
> > To: webappsec () securityfocus com
> >
> > Subject: Re: How to protect against cookie stealing?
> >
> >
> >
> >
> >
> > Why are people going off on increasingly wild and completely
> >
> > impractical and horribly insecure tangents ("hey, lets just create
> >
> > an activex control that the user installs that uses their MAC
> >
> > address for security") without once mentioning the fact that the
> >
> > net impact of cross site scripting attacks (and related cross domain
> >
> > validation type bugs in browsers) is NOT just the ability to steal
> >
> > cookies, it is the ability to completely control the user's
> >
> > interaction with the site, if a client side scripting language such
> >
> > as javascript is enabled.
> >
> >
> >
> > The authentication token is not the holy grail: I don't need a
> >
> > user's cookie or SSL certificate or cereal box decoder ring if I
> >
> > can just tell their browser to jump through a given series of
> >
> > actions on a site and then send the results off via a HTTP request
> >
> > to some other site.
> >
> >
> >
> > Don't get me wrong, ensuring your authentication scheme is
> >
> > secure against
> >
> > a variety of attacks is good. But don't forget the bigger picture.
>
> Important Notice: This email is subject to important restrictions,
>  qualifications and disclaimers ("the Disclaimer") that must be accessed
> and read by clicking here or by copying and pasting the following address
> into your Internet browser's address bar:
> http://www.Deloitte.co.za/Disc.htm. The Disclaimer is deemed to form part
> of the content of this email in terms of Section 11 of the Electronic
> Communications and Transactions Act, 25 of 2002. If you cannot access the
> Disclaimer, please obtain a copy thereof from us by sending an email to
> ClientServiceCentre () Deloitte co za.
>
> -------------------------------------------------------