RE: Implication of forced http GET request (Web App PT)

From: Hagen, Eric (hagene@DenverNewspaperAgency.com)
Date: Mon Oct 02 2006 - 16:40:19 EDT

Next message: Sol Invictus: "Re: pentest documentation"
Previous message: IndianZ: "Re: pentest documentation"
Maybe in reply to: Rick Zhong: "Implication of forced http GET request (Web App PT)"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

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

Next message: Sol Invictus: "Re: pentest documentation"
Previous message: IndianZ: "Re: pentest documentation"
Maybe in reply to: Rick Zhong: "Implication of forced http GET request (Web App PT)"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:57:04 EDT