RE: (clarification) GET and POST Methods Accepted

["Thomas Schreiber" <ts () securenet de>]

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