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

[Achim Hoffmann <kirke11 () securenet de>]

On Wed, 20 Jul 2005, Chuck wrote:

!! Responses below....
...
!! > 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.
!!
!! I agree that CSRF is a common problem, but there are other ways to
!! solve the problem that don't require URL-rewriting.  Basically,
!! include a random value in a hidden field of each form and when the
!! form is submitted, if that value does not match what it should be, the
!! submission is ignored.  You could probably use the session ID instead
!! of a random value, that may be a little easier to implement.

There're a number of measure to mitigate the problem, some are mentioned in
the paper, but keep in mind that they all have pros and cons. I don't have
a general rule which one to prefer, I'm open to more suggestions here.
I'd also not recommend to use the session ID as an additional random value
'cause it might be stolen again for example using a XSS vulnerability.

!!
!! > - Session Fixation, although not generelly impossible with URL rewriting, is
!! >   much more often encountered with cookie-based session management.
!!
!! I think that session fixation is much easier with the session ID in
!! the URL.  For example, if I want a user to use session id 1234, I can
!! easily send them a link to https://vulnerable.tld/appl.cgi;sid=1234
!! while it is more difficult to set a cookie on the victim's browser for
!! the domain vulnerable.tld.  Maybe there is something I am missing
!! here.

Your're right that it is simple. It's simple in both cases.
It's an application problem, means improper session menagement (in particular
re-using session IDs and session objects instead of createing new one from
scratch). This is independent of the transport mechanism of the session ID.

The big difference is the simplicity to sucsessful exploit it.
While with URL rewriting an attacker needs to tweak the victim to click
a link which is one to the application itself, with cookies it could be
done anywhere on any host in any application in the same domain at any time.
And more worse, such a cookie could be set with a (nearly) infinite lifetime
'cause this (domain, path, expire) is stored in the browser only and never
send back to the server. In most cases such cookies could be set using
HTTP instead of HTTPS too, which makes it more simple again.
Well, there are cookie2, but have not yet seen applications using it.

Again, the vulnerability in the application about the session management is
the same for URL rewriting and cookies, but the posibility to exploit it is
much more difficult with URL rewriting, IMHO.

!! > 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
!!
!! I would add the three I mentioned previously:
!!
!! - Session ID may be logged in proxy, etc

Missed that, thanks. But is this a big weakness?

!! - User may send URL with Session ID to someone
!! - User may expose Session ID to others on screen / screenshots
!! (shoulder surfing)

Agreed, but these are user problems not that of the application.

...
!! In response to someone else that mentioned that another option is to
!! use a hidden form field as a session ID.  That has merits, but I am
!! not sure I like having every click in the application be a form
!! submission.

In the paper about session riding we call this an  additional secret.
If such a secret is a hidden field, or another part of the URL doesn't matter.
GET vs. POST does not make a big difference. POST just raises the bar for a
successful exploit a bit.


Open to more comments about session management.

Achim