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_at_znep.com]
> Sent: 27 July 2003 06:32 PM
> To: webappsec_at_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.
Received on Jul 28 2003
Intro
