WebApp Sec mailing list archives

RE: GET and POST Methods Accepted


From: "Derick Anderson" <danderson () vikus com>
Date: Thu, 13 Oct 2005 09:00:10 -0400

 

-----Original Message-----
From: Amit Klein (AKsecurity) [mailto:aksecurity () hotpop com] 
Sent: Thursday, October 13, 2005 4:58 AM
To: webappsec () securityfocus com; Welsh, Ed
Subject: Re: GET and POST Methods Accepted

On 12 Oct 2005 at 15:04, Welsh, Ed wrote:

If the site will accept the GET method for
form data and is vulnerable to XSS, the attack surface greatly 
increases over a site that is vulnerable to XSS but only 
accepts the 
POST method.  POST is still attackable, but it becomes more 
complicated than simply emailing a link.


An attacker can email a link to his/her own website/page, and 
this specially crafted page can contain a form (with 
method=POST and action being the vulnerable URL) followed by 
a piece of Javascript that submits this form. So XSS on POST 
method URLs isn't much more complicated than XSS on GET URLs.

-Amit


GET vs. POST can have an impact when it comes to a poor security
architecture. I found a security hole on an internal web site once that
could only be exploited by an authenticated user and only via GET, as
far as I know in my limited knowledge.

The site was a Java servlet-based time card service. After
authenticating, I noticed they were using GET because of the URL string
and saw that a guessable employee ID number and department code were
part of string. After looking at the source code and finding the
corresponding hidden fields in the requesting page, I was able to put
together a valid GET request which the site would accept.

The next time I authenticated I noticed the URL query string was gone,
but I could still use the GET request and get a successful return. I
reported this to the site managers and during testing they found that by
using a supervisor's ID and department code in the GET query, they could
gain administrative rights to the time card system. The hole was fixed -
how I'm not sure, but judging by the speed it probably had something to
do with not accepting GETs rather than fixing the faulty architecture.

Anyway I share this only because the original post seemed to focus on
GET vs. POST more than XSS. I restrict GET as much as possible in site
development because it can expose the inner workings of the site and
secure methodology or not, we all miss something from time to time.

Derick Anderson


Current thread: