Nathan & Markus,
How about posting some example code that shows an example of how secret
one time tokens can be created and used within jQuery. That would go a
long way to clarifying what you're discussing.
Rey...
Nathan Young -X (natyoung - Artizen at Cisco) wrote:
Hi.
Markus gets it right. There is a vulnerability. This vulnerability has always
been there. This vulnerability effects ajax calls among other things, so if
you want to call it new on that basis then go ahead.
I've heard this called session riding. If I know bank of america's URL for a transfer
funds service, I can code that into my page as the source of an invisible iframe. Should
you visit my page WHILE logged in to your bank of america account, the browser will
activate that page AS IF you had visited it directly. Switch iframe with ajax and you
have this "new" attack.
If you are doing ajax with XHRs this vulnerability does not apply to you (although if you have an
XSS vulnerability it opens session riding back up again). It applies not just with JSON or other
JS though, cookie and image based "ajax" are also vulnerable. Basically anything that
allows for mashups also allows for session riding, hence the saying "web 2.0 treats security
as damage and routes around it"
Session based authentication verifies that you are logged into the application.
What's called for is to verify that the action being asked for is part of a
valid user-directed activity flow. This can be done (as Markus pointed out) by
adding secret one time tokens to forms and links.
Look at how Amazon handles this. LOTS of people are logged into their amazon
accounts all the time. There are three levels of activities you could do with
your amazon account. The first can be done with the always on login and so is
easy to fake using session riding:
- add to wish list
- see your recommendations
- use the gold box
- order by one click
- view your account page (a page of choices)
The next level you have to log in using an online form and lets you do:
- change your shipping address
- change your one click settings
- view your orders
- have an order sent to anyone else than yourself
It's easy to fall out of this second login state if you wait to long or play
around with it in other ways. That's because amazon is keeping track of your
user activity flow (is there a term for this?) to prevent session riding
attacks.
Then there are things you just can't do, like reading your own credit card
number. Since people right now are often doing ajax for the first time, I
think there are common sense precautions like this that are getting missed.
Startups are also notorious for sacrificing security in favor of growth (in
fact it's sometimes explicit in their business plan). So ajax is likely to get
a bad security rep for a while.
----->Nathan
.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:.
Nathan Young
Cisco.com->Interface Development
A: ncy1717
E: [EMAIL PROTECTED]
-----Original Message-----
From: jquery-en@googlegroups.com
[mailto:[EMAIL PROTECTED] On Behalf Of Markus Peter
Sent: Tuesday, April 03, 2007 3:56 AM
To: jquery-en@googlegroups.com
Subject: [jQuery] Re: Web 2.0 is vulnerable to attack
On 03.04.2007, at 08:07, Karl Rudd wrote:
Bah, it's not a new vulnerability, it's always been there and always
been known about.
I call FUD on this.
The following is an excerpt that is the keystone of the whole thing:
"In an example attack, a victim who has already authenticated
themselves to an Ajax application, and has the login cookie in their
browser, is persuaded to visit the attacker's web site.
This web site
contains JavaScript code that makes calls to the Ajax app. Data
received from the app is sent to the attacker."
Firstly _don't visit suspect sites_.
Secondly their "example attack" is flawed. As far as I'm aware
JavaScript code on one page does not have access to the cookies of
other webpages. If it does it's a security flaw in the browser,
nothing a JavaScript library can do about it.
I would not call this only FUD - the newspaper article is bad and
FUD, especially the conclusion that the libraries are "vulnerable"
where in reality the developers using them were probably clueless,
but the original paper it refers to has a point. It maybe helps if
you read the original paper at
http://www.fortifysoftware.com/servlet/
downloads/public/JavaScript_Hijacking.pdf
You're right in so far as it's an old hat - nevertheless most people
don't think of these kind of attacks even though Google already fell
prey to it several times.
Unfortunately, many people seem to misunderstand the way, the attack
works:
Cookies are not accessed by "other webpages" by this attack.
Instead,
the attack relies on the fact, that browsers will always
automatically send cookies to the original domain. It's just plain
old cookie-based XSS applied to JSON data.
What happens is, that if you e.g. have a JSON-outputting URL on your
page like /api/ultrasecretdata which is secured by cookies and
another page simply does
<script src="http://yourdomain/api/ultrasecretdata";></script>
then the browser will load the page and execute it as JavaScript. As
the request goes to your server, your cookie will rightfully be sent
with it and the request is authenticated, so the server will output
the data.
Now, it's of course "only data" but what most people forget is, that
JSON data is executable JavaScript Code: Arrays and Objects are
constructed, and therefore, their constructors are called. If you
override the constructor before the script tag, you'll receive the
data in your own code.
Of course, you could still say, that browsers should not allow
scripts of different pages interact that way - but they do work that
way at the moment and it will likely never be changed as too many
things nowadays rely on the fact that scripts from different servers
can interact with each-other if they're loaded on the same page - so
you _have_ to fix it in your application.
There are basically two ways to fix it:
1. Include a secret into the URL. Our own application for example
always includes the Session ID of an authenticated user as a request
parameter to the API calls, because then the URL is not guessable
anymore and it's not possible to include the data on other pages
2. Include some breaker code in the output of your APIs before the
actual data like e.g. /* */ comments and then remove that
data before
evaling your JSON code.
The second fix is rather easily applied to legacy code, but it's
plain UGLY and it somehow destroys the reason for using a standard
format like JSON.
What these guys obviously mean, when they say that frameworks are
"vulnerable" is, that no frameworks support the developer with that
task (solution 2) by offering automatic support to throw away the
execution breakers. I'm actually glad about that - JSON should stay
JSON and data exchange formats should stay standardized - otherwise
we're thrown back straight into the 90ies with proprietary APIs.
Now, solution 1 is easily done with jQuery and probably all
the other
libraries mentioned - simply include your secret, most probably the
session id, as a parameter with every request to APIs which
should be
secured. My suggestion would be to actually extend the jQuery AJAX
documentation (or include a link to some tutorial in the Wiki or so)
to point out the issue, if you use JSON only secured by cookies.
That's the most sensible change to do - I do not think this issue
justifies any changes to the jQuery code itself as it's only
an issue
of most application developers not thinking about a certain type of
attack.
--
Markus Peter - [EMAIL PROTECTED]
http://www.spin-ag.de/
SPiN AG, Bischof-von-Henle-Str. 2b, 93051 Regensburg, HRB 6295
Regensburg
Aufsichtsratsvors.: Dr. Christian Kirnberger
Vorstände: Fabian Rott, Paul Schmid
--
BrightLight Development, LLC.
954-775-1111 (o)
954-600-2726 (c)
[EMAIL PROTECTED]
http://www.iambright.com
