On Wed, January 16, 2008 12:54 am, Stefan Priebsch wrote: > 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. > > You can easily have sombeody inadvertedly send a malicious GET request > just by embedding an image link into a page.
Or they could just use wget and DOS me. Allowing POST or GET for an (idempotent) operation and using $_REQUEST still seems like it's not gonna hurt anything... I consider GET/POST/COOKIE equally dangerous/suspicious/spoofable/etc, so whatever security methods I am employing for GPC data should be sufficient for any GPC data, regardless of source. And, yeah, if somebody wants to cram a value into a COOKIE instead of using a link, the service would respond to it. What increased risk is there from responding to a forged cookie instead of a forged GET or POST data request? What am I missing? How is a forged COOKIE any more/less dangerous than a forged GET/POST? PS This harkens back to pre-CSS days when one Designer client wanted buttons and one Designer client wanted links. I didn't really care what their UI looked like, so used $_REQUEST, and told them both to have at it. These days, I'd probably just use GET and tell them to use CSS to make their links look like buttons... -- 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
