On Wed, January 16, 2008 1:45 am, Stefan Esser wrote: > Stefan Priebsch schrieb: >> Richard Lynch schrieb: >>> If a web service really doesn't care whether it is responding to >>> GET >>> or POST or even forged COOKIES to product its output, why would it >>> not >>> just use REQUEST? >>> >>> It's not as if it's any harder to forge GET vs. POST vs. COOKIE >>> data, >>> really. >> > I am replying to Stefan's mail because I don't see the one by Richrd > (yet). > > @Richard: You don't understand the Problem with _REQUEST. It is not > about the fact that someone can forge GET, POST; COOKIE variables. > It is about the fact that COOKIEs will overwrite GET and POST data in > REQUEST. > > Therefore I could infect your browser with a cookie that says e.g. > action=logout and from that day on you cannot use the application > anymore because REQUEST[action] will be logout forever (until you > manually delete the cookie). > > And to infect you with a COOKIE is so simple... > a) I could use an XSS vuln in any application on a subdomain > b) Ever tried setting a cookie for *.co.uk or *.co.kr when you own a > single domain there? > c) Other cross domain whatever ways... > > And if you believe that this is not an issue then I can tell you that > there is a simple possibility to set f.e. a *.co.kr cookie that > results > in several PHP versions just returning white pages. > Imagine: Just a single cookie to kill all PHP pages in *.co.kr > > And by setting an illegal session ID in a cookie valid for *.co.kr in > a > variable called +PHPSESSID=*illegal* you can still DOS every PHP > application in korea using PHP sessions...
Understood. My search engine could return what the XSS-forged cookie of an attacker wants them to find, instead of what they asked for, if the attacker over-ride the search input variables with a cookie value. This could be very confusing/frustrating to a user; who would assume my site search is very broken. And if I was foolish enough to not sanitize the GPC data, regardless of source, an attacker could use an XSS cookie to trash the DB, and be very difficult to track them down, as their attack cookie resides on somebody else's box from a previous interaction with their site, or more likely some random XSS-vulnerable third-party site. So I'd never know who actually attacked the application. I am willing to accept that risk because: The number of times your average user is told to wipe out their cookies when they are having random problems means that I'll probably never have to deal with a bug report on this. They'll just assume I fixed the site, which I haven't touched in a decade. And it's only likely to ever affect an extremely tiny portion of users for this particular application, since it has a very narrow niche userbase. I daresay this number approaches zero... The actual application/data and the server is not at risk, at least afaics, from this sort of attack. Thanks for explaining exactly what the risk and attack vector were! -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/from/lynch Yeah, I get a buck. So? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
