From: Evans, Arian [mailto:Arian.Evans@fishnetsecurity.com]
Sent: Thursday, October 13, 2005 8:24 PM
>
>
> While we are all for more discussion about the security implications
> of using GET versus POST, the questions I'm seeking to answer are
> (don't want to speak for Ed here, but I think we're on the
> same page):
>
> 1) Are other people seeing that the applications they test
> accept GETs where they are intended/expecting to accept POSTs?
Straight answer: over 90% where the FORM has a POST-action but GET is
accepted as well (out of more than 100 examined websites)
> 2) Are you seeing this more or less on specific platforms?
It looks like on .net/asp-Site it is less often found
> 3) Anyone know why none of the automated tools test this?
Probably because it is not yet recognized or rated as a problem. At the
current state of discussion it should be marked as a potential problem. My
personal opinion (and that is how we handle it in our reports): it should be
reported as a problem and should be explained, why not allowing it gives an
additional measure against potential vulnerabilities.
>
> 4) Does anyone on the list find this issue worth
> discussing/addressing
> in more detail?
Reaching some point of common understanding which results in a
state-of-the-art recommendation would be fine.
Session Riding (aka CSRF) gives one more argument against allowing GET where
a POST is defined: An image tag like this
<IMG SRC="https://b2b.company.tld/webapp/delete?item=123";>
that triggers an action on the attacked users account is often easily put
into a posting to a forum, wiki, blog, etc. and executed by any user that
views the page. If the site would only allow POST for the delete-function,
you had to find a carrier that accepts JavaScript-Tags, to launch the
attack.
Of course, the root of the problem is the Session Riding weakness itself.
But recommending against GET is a meaningful measures of the 'additional
measure' or 'second line' type.
Beste Grüße
Thomas Schreiber
____________________________________________________________
SecureNet GmbH - http://www.securenet.de
+49 89/32133-610
mailto:ts@securenet.de
