Penetration Testing mailing list archives
RE: Implication of forced http GET request (Web App PT)
From: "Hagen, Eric" <hagene () DenverNewspaperAgency com>
Date: Mon, 2 Oct 2006 14:40:19 -0600
Rick, Obviously, the best practice is to specify which type of request you expect as a programmer. Most modern web scripting languages I've worked with support this on at least a basic level. Now, in launguages, this is often ignored (or the developer is ignorant of the security issues). For example, in PHP, it is common to use the "$_REQUEST" superglobal which is an abstraction of the combined input of both GET and POST (and other things such as $_COOKIE and sometimes $_FILE) when it is better practice to use specifically the $_GET and $_POST superglobals. In addtion the old default of "register_globals = ON" in PHP parses both GET and POST inputs into normal global variables, without specifying and assigns them to a variable. Again, best practice is to specify the expected input method as described in this page using $_GET or $_POST (other other): http://us2.php.net/register_globals Assuming you have some reason that you cannot edit the variables within the code, a function could be added to the beginning of each script to process the inputs. Since superglobals in PHP are not read-only, you could check the input method and erase (or better yet, trap and perform some logging) those variables that come in from unusal directions and then set the corresponding superglobal blank. This way, having the functionality without having to change the bulk of the code. To do what you asked on an even more basic level, you could simply wipe out the $_GET superglobal at the beginning of each script, rendering it essentially disabled. Again, this is all PHP, but the basics are the same for other scripting languages I have worked with. Comparable code is simple enough in ASP and ColdFusion as well. What APIs are we referring to that cannot control their inputs? Eric -----Original Message----- From: listbounce () securityfocus com [mailto:listbounce () securityfocus com]On Behalf Of Marvin Simkin Sent: Monday, October 02, 2006 11:40 AM To: Rick Zhong Cc: pen-test () securityfocus com Subject: RE: Implication of forced http GET request (Web App PT) Look through the configuration options of your webserver software, there may be a way to reject GETs to certain URLs before the language API ever gets ahold of them. Failing that, some languages pass a whole bunch of global variables (or something similar) which the programmer can query to see if the method was GET or POST and deal with it accordingly. For example, if you're programming in ASP, something like this: (not tested) if UCase(Request.ServerVariables("HTTP_METHOD"))="POST" Then ... Remember to whitelist the "good" method (POST) and not just blacklist the "bad" one (GET). Marvin -----Original Message----- From: listbounce () securityfocus com on behalf of Rick Zhong Sent: Sun 2006-10-01 17:54 To: Marvin Simkin Cc: pen-test () securityfocus com Subject: Re: Implication of forced http GET request (Web App PT) Thanks Marvin. I am also wondering whether there is any practical way to control this from the developers' perspective, i.e. make sure only POST or GET requests are allowed? I did a bit search on google, and it seems that this is quite dependent on the language. And some APIs by default accept parameters from both POST and GET which means it will be quite hard for developers to control this since they need to change the APIs. On 9/29/06, Marvin Simkin <Marvin.Simkin () asu edu> wrote:
Rick, GETs are a little easier to work with than POSTs, whether your hat is white or black. So for example suppose Alice has item ID=100 up for auction at vulnerable.com, and Mallory sends Alice an email message expressing interest in Alice's merchandise. Unknown to Alice, Mallory also has an item ID=200 up for auction. Mallory's HTML formatted email includes an IMG SRC=vulnerable.com/bid?item=200&price=999999 (contrived, simplified example). The folks at vulnerable.com thought bids would only ever be POSTed and therefore harder to fake. (Or didn't think about it at all.) But with a little more work Mallory might find a way to trigger a fake POST too. So GET just makes the job easier. Other possible information leakage avenues to explore: * GETs are also typically logged by the webserver while POSTs are not. So could someone be tricked into logging their sensitive info where someone else could view it? * GET parameters can be passed by a referring URL to another site, depending on your browser choices. Marvin -----Original Message----- From: listbounce () securityfocus com on behalf of Rick Zhong Sent: Tue 2006-09-26 11:14 To: pen-test () securityfocus com Subject: Implication of forced http GET request (Web App PT) hi, guys Just curious to know what are the possible security implications of permitting forced GET request in a web application? I am pt on this web application where all the form submission POST request can be replaced with GET request with all the parameter values appended to the url. I remember someone mentioned this in a "session fixation" whitepaper. Is there any other related risks with this implementation? regards, Rick ------------------------------------------------------------------------ This List Sponsored by: Cenzic Need to secure your web apps? Cenzic Hailstorm finds vulnerabilities fast. Click the link to buy it, try it or download Hailstorm for FREE. http://www.cenzic.com/products_services/download_hailstorm.php?camp=701600000008bOW ------------------------------------------------------------------------
------------------------------------------------------------------------ This List Sponsored by: Cenzic Need to secure your web apps? Cenzic Hailstorm finds vulnerabilities fast. Click the link to buy it, try it or download Hailstorm for FREE. http://www.cenzic.com/products_services/download_hailstorm.php?camp=701600000008bOW ------------------------------------------------------------------------ ------------------------------------------------------------------------ This List Sponsored by: Cenzic Need to secure your web apps? Cenzic Hailstorm finds vulnerabilities fast. Click the link to buy it, try it or download Hailstorm for FREE. http://www.cenzic.com/products_services/download_hailstorm.php?camp=701600000008bOW ------------------------------------------------------------------------ ------------------------------------------------------------------------ This List Sponsored by: Cenzic Need to secure your web apps? Cenzic Hailstorm finds vulnerabilities fast. Click the link to buy it, try it or download Hailstorm for FREE. http://www.cenzic.com/products_services/download_hailstorm.php?camp=701600000008bOW ------------------------------------------------------------------------
Current thread:
- Re: Implication of forced http GET request (Web App PT) Rick Zhong (Oct 01)
- RE: Implication of forced http GET request (Web App PT) Marvin Simkin (Oct 02)
- <Possible follow-ups>
- RE: Implication of forced http GET request (Web App PT) Hagen, Eric (Oct 02)