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 forform data and is vulnerable to XSS, the attack surface greatly increases over a site that is vulnerable to XSS but onlyaccepts thePOST method. POST is still attackable, but it becomes morecomplicated 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:
- Re: GET and POST Methods Accepted, (continued)
- Re: GET and POST Methods Accepted Stephen de Vries (Oct 13)
- Re: GET and POST Methods Accepted christopher baus (Oct 13)
- Re: GET and POST Methods Accepted Stephen de Vries (Oct 13)
- Re: GET and POST Methods Accepted Damien Watson (Oct 13)
- Re: GET and POST Methods Accepted Serg Belokamen (Oct 13)
- Re: GET and POST Methods Accepted Eoin Keary (Oct 13)
- Re: GET and POST Methods Accepted Amit Klein (AKsecurity) (Oct 13)
- Re: GET and POST Methods Accepted John GALLET (Oct 13)
- Re: GET and POST Methods Accepted Eoin Keary (Oct 13)
- Re: GET and POST Methods Accepted John GALLET (Oct 13)
- Re: GET and POST Methods Accepted Eoin Keary (Oct 13)
- Re: GET and POST Methods Accepted Paul Laudanski (Oct 18)
- RE: GET and POST Methods Accepted Derick Anderson (Oct 13)
- RE: GET and POST Methods Accepted christopher baus (Oct 13)
- RE: GET and POST Methods Accepted Joe Teff (Oct 13)
- RE: GET and POST Methods Accepted christopher baus (Oct 13)
- RE: GET and POST Methods Accepted Derick Anderson (Oct 14)