RE: (conclusion) GET and POST Methods Accepted

["Evans, Arian" <Arian.Evans () fishnetsecurity com>]

So now that we got under the hood and saw what at least one
commercial vendor is doing, I have some speculative answers:

We're seeing a lot of this in ASP and ASP.NET apps and what
happens is that you have three methods, Request.QueryString,
Request.Form, and Request.ServerVariableName to use.

Request.ServerVariableName has access to *everything*.

People get lazy and parse everything via Request.ServerVariableName
instead of Request.Form which allows you to turn POSTs into GETs.

I'm guessing there is something similar in Javaland, but too
lazy to Google.

There is a whole 'nother issue here that we see in a number
of web apps. It's very simple and I'm sure most of you have
seen it but I can't find it written up anywhere as a dangerous
practice, so once we get software fixed we'll do a writeup on it.

Per your notes on transparent framework session token remapping
below, another aspect of that issue is that many financial
applications now have their session tokens for stuff like
International Wires stored in web logs due to GET, so you've
just put authorization status for every authenticated user
for very sensitive applications in the hands of every place
your web logs go (backup tapes, people with read access,
log collectors, etc.), which usually web logs are classified
as low sensitivity level information if classified at all.

Which now returns to your trivial session replay point.

-ae 

> -----Original Message-----
> From: Andrew van der Stock [mailto:vanderaj () greebo net] 
> Sent: Friday, October 14, 2005 11:51 AM
> To: Amit Klein (AKsecurity)
> Cc: webappsec () securityfocus com
> Subject: Re: (clarification) GET and POST Methods Accepted
>
>
> The primary reason for discouraging the use of GET is the "Qantas  
> Club" (=kiosk / untrusted PC) information disclosure scenario, where  
> the user has to rush off to catch a plane, but has [ no time /  
> forgets / cant ] sanitize their session.
>
> Many frameworks (PHP and many J2EE implementations included) use  
> "transparent" relocation of the cookie to GET, and coupled with GET  
> state and poor authorization, replay is possible with poor 
> quality apps.
>
> If it's something like "transfer.php? 
> acct=74387483&to=4384378&amt=4343" it becomes trivial for beginners  
> to tamper with fields as well as for a slightly more advanced  
> attacker (e.g. my Mum) to see the history of the application.  
> Browsers do not obscure HTTPS sessions in their history, so even  
> though SSL should prevent MITM sniffing, it doesn't protect against  
> end PC inspection.
>
> I can remember doing code reviews back a number of years (as 
> early as  
> 2000) where I tested for information leakage in the browser history  
> and if I could replay it. Back then, it was trivial. 
> Certainly, there  
> is no harm is testing for it these days. I caught out a ServletExec  
> based app this last April with this same tactic that yielded 
> me Admin  
> credentials over the application. I'm under NDA about another  
> scenario which is biting us hard right now in exactly the same  
> fashion but I can't spill the beans without a lot of alcohol induced  
> bribery.
>
> thanks,
> Andrew