WebApp Sec: Re: (clarification) GET and POST Methods Accepted

[Andrew van der Stock <vanderaj () greebo net>]

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