Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | RE: GET and POST Methods Accepted |
|---|---|
| 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
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: Cenzic NASL plugins, Michael Boman |
|---|---|
| Next by Date: | Re: myspace hack, Chris Varenhorst |
| Previous by Thread: | Re: GET and POST Methods Accepted, Paul Laudanski |
| Next by Thread: | RE: GET and POST Methods Accepted, christopher baus |
| Indexes: | [Date] [Thread] [Top] [All Lists] |