RE: [WEB SECURITY] cookies a fundamental threat?

["Evans, Arian" <Arian.Evans () fishnetsecurity com>]

What are we, close to a decade now on this thread?

Per your examples below, there are a lot of different ways
to use tokens (contextual) and different ways to implement
tokens and /one possible way/ is a cookie, which has pros and
cons, just like all the other options, but has the HUGE con
of being automagically supplied by the browser...*not* even
upon demand, not requiring some challenge-response scenario,
but will be supplied by the browser with even the simplest
tickle to make a request. This is called CSRF, or the catchier
but possibly misleading "securenet session riding"! ;)

In simplest review, it works like this:

1. You come to my site, view my email, click on my link. etc
2. I encourage your browser to make a request to: target.site
3. Your browser supplies the session cookie automatically.

If there is a non-cookie session token, I have to harvest it
first, and then supply it with the CSRF attack. For reference,
see the Myspace script injection attack, which harvested and
then resubmitted Myspace's "secret page hash" token thingyMcBob.

Unless, of course, you are hitting the initial entry-point
of the app where you are supplied your first token. Then
the issue is the same, cookie, URL, FF, pixie dust. But
then, the danger of setting authenticated session tokens
a priori authentication is well know. (uhh...)

So what/where is the benefit? Take, for example the CSRF
examples released at BH last year to target Nokia IPSO, or
the much simpler forms that were discovered in the wild
(the same week of releasing examples of targeting localized
appliances, ironically) which targeted large online
transaction companies like eBay:

http://www.target.site/resource?item=deadtopic&bid+1000000

This logic is simple: If CooKie, Then Bid.

So what about the alternatives? Let's add some one-time
tokens that have predefined relative and absolute lifespan
values for time, and have a relative request use of '3'.
(this is to permit use of back button)

These could be implemented like so:

1) URL param:
http://www.target.site/resource?item=deadtopic&bid+1000000&secretsessionid=12345

2) URI resource:
http://www.target.site/12345/resource?item=deadtopic&bid+1000000

3) Obfuscated URI (w/out URL params, if they are not generated client-side
then you can store them in your session object):
http://www.target.site/12345

4) Obfuscated URI w/legacy URL param support:
http://www.target.site/12345?item=deadtopic&bid+1000000&secretsessionid=12345

5) Then of course you could store this in a hidden FF.

All of the above have pros and cons, from Nav to Bookmarking
to overhead to token considerations, like one-time or many-time,
relative action timeouts, absolute lifespan, etc. The end result
is to drastically reduce attack surface, in many cases reducing
the attack surface to attacking one person one time. Period.

Against specific attacks, like CSRF and certain XSS attacks.
This also *befuddles all scanners*. No exceptions.

My mates and I released a proxy at BH Amsterdam that did
all this for you automatically. 256 bit AES, stored flags for
various bits in the HTTP resp, removed and stored things like
cookies for you (which is how it worked transparently), and
could be 1) URL param, 2) URI resource, 3) replace URI (most
secure...and fun, 4) legacy URL/param support.

You could configure the rest of the token params. I think about
5 people in the room understood what we did; the questions were
so off in left field that we pulled the project until we can
figure out how to communicate/demonstrate better (which is, I
believe, entirely my fault). The underlying HTTP proxy is also
being re-written in C# 2.0 due to better network socket performance
in .NET 2.0, and in general we want to polish, and add several
attack tools which I think you will see this year.

We initially released our project to establish prior art since at
least two WAF vendors have recently filed patents on these ideas...
point is, it works, it works well, it reduces attack surface as
well in its own way as the ridiculous claims of half the WAF
vendors for stopping XSS attacks (regardless of the scores in the
"eweek" and "secureenterprise" reviews of WAF GUIs), and lest
this sound tainted with the 'leetist security snob' tone, I
should add, this can be verfied with GUI tools and point and
click skills. (more, unfortunately, will have to wait)

The degree to which our proxy interferes with your users' activities
is a sliding scale between attack surface and transparency.

If, for example, your users use an average of five back-Navs
per session, then a one-time token may be problematic, which
is easily resolved by tuning the token lifespan parameters.

I hope the proxy anecdotes help illustrate the point:

Cookies by design are a poor mechanism for secure session token
handling. I don't think there's a coherent argument that can
be made against that statement. Yeah, sure, "cookieless" sessions
and URL rewriting stuff tokens in the www logs, and potentially
other places, but it's all text, and the problem there is with
the *token*, not with the distribution mechanism.

So, then, how are cookies different? Well, even if you make the
cookie a one-time token, because the mechanism is automatic,
you lose the benefit (mostly) of a one-time token. And, you
do nothing to hinder the ease of implementation of CSRF attacks
or even locally-embedded scripts like the Myspace example.

(Though, too be true, most of the other options above might
at best slow down the creation of something like the Myspace
"worm", and only option #3 has a real chance of stopping it,
though a bit of scripted regex could render even that moot.)

So, concluding, there are many differences between the various
scenarios. If you were referring only to static tokens passed
in various ways, however, I apologize; in that case there are
a few small differences, but not worth reading this long of
a post about.

-ae





-----Original Message-----
From: Tom Stripling [mailto:tstripling () securityps com] 
Sent: Wednesday, May 03, 2006 9:34 AM
To: Achim Hoffmann; websecurity () webappsec org
Cc: webappsec () securityfocus com
Subject: RE: [WEB SECURITY] cookies a fundamental threat?

 

> -----Original Message-----
> From: Achim Hoffmann [mailto:kirke11 () securenet de] 
> !!
> !! I guess I don't understand your point here.  An 
> application using !! form-based session management would need 
> to pass the session ID back and !! forth with every 
> request/response just as if the session ID were being !! 
> stored in a cookie.  If I execute a form-based session 
> fixation attack, !! the fixated session ID will simply get 
> passed back and forth for the !! remainder of the session in 
> the same way that a cookie would.  Which !! brings us back to 
> Brian's point that session fixation is easier when the !! 
> application is using form-based session management because I 
> can execute !! the attack from anywhere.
>
> Not that bad: a form can be placed anywhere, true, but ...
> Lets explain with an example:
>   Assuming a simple login page with username, password and a 
> hidden session ID.
>   Also assuming that the application is vulnerable to session 
> fixation.
>
>   First the attacker copies the original login page, adds the 
> original URL to
>   the form's action attribute, fills in a session ID in the 
> hidden field,
>   and places this trap-page somewhere (not on the domain to 
> be attacked).
>
>   Now the victim has to be engaged to visit that trap. No 
> Problem, you can
>   send a link to be clicked, you can post the link in a forum 
> somewhere,
>   you even may misuse a search engine. And a sophiticated 
> attack even can
>   perform that the victim doesn't need tpo click but is redirected
>   immediately to the trap.
>
>   And here the difference starts.
>   The victim has to fill in username and password to activate 
> the form and
>   hence to perform the session fixation. Damn, bad situation 
> for an attacker.
>
> Silly Question: would you login in such a page with the wrong 
> URL in your address bar?
> Well, you may argue that such a page could be placed using 
> XSS or better website spoofing, but then we're back on the 
> domain to be attacked. In that case I don't see a big 
> difference to phishing, which is much more effective 'cause 
> the attacker gets the full login credentials then.
> I don't see a reason why someone would login into a foreign 
> page, but correct me if I miss a suitable working example here.

Here's the situation I was thinking of.  Tell me if you think this
constitutes a counter example.

An application has a login form and accepts a hidden field containing
the session id.  The application is vulnerable to session fixation, so
that if I enter a username and password into the form, the application
will accept the value that is stored in the hidden session id field and
use that for my session from that point on.

Up to this point, I don't think I've changed anything from your
scenario.  You were saying that the attacker would need to duplicate the
login form to execute the attack.

But what if I formulate a link with the session id parameter only (i.e.
http://exmaple.com/login.aspx?sid=12345) and send that to you in the
manner you described above?  If the application is vulnerable to session
fixation, it seems likely that it would simply take this session id,
store it in the hidden field, and present the user with the login form.
At this point, the victim is logging into the correct url and sees
nothing overly suspicious.  And the attacker has dictated the session id
that the victim will use in the same way as the cookie example.  In my
experience, this attack is extremely common in applications that use
form field session management and are vulnerable to session fixation.

Even though cookies will be sent with every request to that domain by
the browser, an application that uses another method to communicate the
session id still has to duplicate that behavior by storing the session
id on the client (in some form) on every page.

In this scenario, I don't see a real-world difference between the
ability to execute a form-based session fixation attack and cookie-based
attack except for the fact that the form-based attack can be executed
from anywhere, as we've agreed.

> On the other side have a look how an attacker does it with cookies:
>   Assumptions as above.
>
>   Attacker crafts URL with cookie injection code, delivers 
> the URL the same
>   way as above.

How does one craft a URL with cookie injection code?  Are you talking
about ASP.NET cookieless sessions and the like?  Could you provide an
example of this?

Regards,
Tom

-------------------------------------------------------------------------
Sponsored by: Watchfire

The Twelve Most Common Application-level Hack Attacks
Hackers continue to add billions to the cost of doing business online 
despite security executives' efforts to prevent malicious attacks. This 
whitepaper identifies the most common methods of attacks that we have seen, 
and outlines a guideline for developing secure web applications. 
Download this whitepaper today!

https://www.watchfire.com/securearea/whitepapers.aspx?id=701300000007t9r
--------------------------------------------------------------------------


-------------------------------------------------------------------------
Sponsored by: Watchfire

Methodologies & Tools for Web Application Security Assessment
With the rapid rise in the number and types of security threats, web
application security assessments should be considered a crucial phase in
the development of any web application. What methodology should be
followed? What tools can accelerate the assessment process?
Download this whitepaper today!

https://www.watchfire.com/securearea/whitepapers.aspx?id=701300000007t9h
--------------------------------------------------------------------------