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
