[PHP] Gebruik $_REQUEST security risk?

[sjaakie]

Ik had zojuist even een discussie met een collega en ik ben van mening dat het gebruik van $_REQUEST een security risk is, alleen al om het simpele feit dat je niet weet waar je input vandaan komt. Dus gewoon netjes $_GET, $_POST en $_COOKIE gebruiken.

Maar wat vinden jullie? Is $_REQUEST een security risk of niet?

[YakuzA]

$_GET, $_POST en $_COOKIE zijn net zo goed gevaarlijk en een security risk als je er niet goed mee omgaat

[ Voor 6% gewijzigd door YakuzA op 14-12-2007 11:34 ]

[justmental]

Wellicht is het zelfs andersom, als je alleen post/get/cookie wilt gebruiken vanwege de mogelijkheid tot het manipuleren van variabelen via een andere weg dan heb je in je systeem een security risico.

[DanielG]

Ik denk dat het gebruik van $_REQUEST net zoveel risico oplevert als het gebruik van $_GET, $_POST en $_COOKIE, want dat komt ook van de client (en is dus niet te vertrouwen).

Je moet al je input sanitizen, zowel $_REQUEST als $_GET, $_POST en $_COOKIE.

Ik snap jou argument van "alleen al om het simpele feit dat je niet weet waar je input vandaan komt" niet echt omdat het voor zowel $_REQUEST als $_GET, $_POST en $_COOKIE geld.

[Kettrick]

Je moet sowieso je input checken, of het dan uit een GET of POST komt maakt weinig uit imho.
Ik gebruik request behoorlijk vaak iig, en GET/POST alleen als ik specifiek iets uit de betreffende request wil hebben.

[cspare]

sjaakie schreef op vrijdag 14 december 2007 @ 11:31:
Ik had zojuist even een discussie met een collega

Ik ben wel benieuwd naar de argumenten van je collega, gezien hij je niet heeft kunnen overtuigen?
Het meest logische argument (het komt allemaal van de client) lijkt me voldoende om iemand te overtuigen dat het niet direct een grotere security risk heeft.

[Erkens]

DanielG schreef op vrijdag 14 december 2007 @ 11:37:
Ik snap jou argument van "alleen al om het simpele feit dat je niet weet waar je input vandaan komt" niet echt omdat het voor zowel $_REQUEST als $_GET, $_POST en $_COOKIE geld.

Natuurlijk niet, zodra je weet dat een password via bijvoorbeeld GET of COOKIE verstuurd is ipv via POST bij het inloggen dan vertrouw ik het al niet en deny ik de request aangezien ik weet dat die met POST moet komen. Net zoals ik een session id alleen via COOKIE accepteer en niet via GET of POST.

[DanielG]

Erkens schreef op vrijdag 14 december 2007 @ 11:46:
[...]

Ik doelde meer op het feit dat het altijd van de client komt, niet dat het via de verkeerde methode verstuurd wordt.

[cspare]

Erkens schreef op vrijdag 14 december 2007 @ 11:46:
[...]

Natuurlijk niet, zodra je weet dat een password via bijvoorbeeld GET of COOKIE verstuurd is ipv via POST bij het inloggen dan vertrouw ik het al niet en deny ik de request aangezien ik weet dat die met POST moet komen. Net zoals ik een session id alleen via COOKIE accepteer en niet via GET of POST.

Maar dat voegt dus (bijna) niks toe aan de security van je applicatie. Als je echt te maken hebt met mensen die input willen manipuleren doen ze dat vast niet per ongeluk in een post terwijl de applicatie die informatie normaal via een cookie doorstuurd.

[BikkelZ]

Het kan natuurlijk wel tot gevolg hebben dat je af en toe een andere waarde aantreft dan je verwacht, maar qua security heeft dat verder geen gevolgen. Als je inderdaad je inkomende data met gezonde scepsis behandelt.

[sjaakie]

Erkens schreef op vrijdag 14 december 2007 @ 11:46:
[...]

Natuurlijk niet, zodra je weet dat een password via bijvoorbeeld GET of COOKIE verstuurd is ipv via POST bij het inloggen dan vertrouw ik het al niet en deny ik de request aangezien ik weet dat die met POST moet komen. Net zoals ik een session id alleen via COOKIE accepteer en niet via GET of POST.

Amen!

Uiteraard doe je een sanitize op alles wat je van de client krijgt. Maar ik ben het met Erkens eens dat je altijd wil weten waar je input vandaan komt om het risico van een securiry leak zo klein mogelijk te maken.

[ Voor 20% gewijzigd door sjaakie op 14-12-2007 11:56 ]

[Kettrick]

Erkens schreef op vrijdag 14 december 2007 @ 11:46:
[...]

Natuurlijk niet, zodra je weet dat een password via bijvoorbeeld GET of COOKIE verstuurd is ipv via POST bij het inloggen dan vertrouw ik het al niet en deny ik de request aangezien ik weet dat die met POST moet komen. Net zoals ik een session id alleen via COOKIE accepteer en niet via GET of POST.

Lijkt mij meer een gevalletje obscurity ipv security

[Erkens]

cspare schreef op vrijdag 14 december 2007 @ 11:50:
Maar dat voegt dus (bijna) niks toe aan de security van je applicatie. Als je echt te maken hebt met mensen die input willen manipuleren doen ze dat vast niet per ongeluk in een post terwijl de applicatie die informatie normaal via een cookie doorstuurd.

Ik ben blij dat je het woordje 'bijna' erbij hebt gezet, maar het gebeurd wel vaker hoor dat er een password of session id via GET verstuurd wordt (want dat is lekker makkelijk) dus ja in dat opzicht voegt het gewoon iets aan security toe. Je weet waar het vandaan kwam ook al komt alles bij de client vandaan. Daarnaast is het gewoon handig om te weten in je applicatie waar een bepaalde variabele gedefinieerd wordt (bij een normale werking, dus zonder eventuele manipulatie).

[Erkens]

RoeLz schreef op vrijdag 14 december 2007 @ 11:53:
[...]


Lijkt mij meer een gevalletje obscurity ipv security

Dat kan je zo noemen, maar als dat je enige "security" is dan kan je beter een ander vak zoeken

[Janoz]

cspare schreef op vrijdag 14 december 2007 @ 11:50:
[...]


Maar dat voegt dus (bijna) niks toe aan de security van je applicatie. Als je echt te maken hebt met mensen die input willen manipuleren doen ze dat vast niet per ongeluk in een post terwijl de applicatie die informatie normaal via een cookie doorstuurd.

Toch wel. Bedenk bijvoorbeeld eens aan bepaalde bewerkingen die je alleen als administrator uit mag voeren. Wanneer je deze actie alleen maar via post of cookie binnenkrijgt moet de computer van de admin daadwerkelijk 'aangepast' worden om de admin iets te laten doen wat hij niet wil.

Zou je een get request ook accepteren dan hoef je de admin alleen maar naar een url te laten gaan (door een linkje in de mail/msn of een plaatje op een pagina) om hem een actie uit te laten voeren.

Verder is er daadwerkelijk verschil tussen POST en GET request volgens het http protocol. Helaas houd niet iedereen zich hieraan waardoor de webaccelerator bijvoorbeel niet goed werkte.

[cspare]

Erkens schreef op vrijdag 14 december 2007 @ 11:54:
[...]

Ik ben blij dat je het woordje 'bijna' erbij hebt gezet, maar het gebeurd wel vaker hoor dat er een password of session id via GET verstuurd wordt (want dat is lekker makkelijk) dus ja in dat opzicht voegt het gewoon iets aan security toe. Je weet waar het vandaan kwam ook al komt alles bij de client vandaan. Daarnaast is het gewoon handig om te weten in je applicatie waar een bepaalde variabele gedefinieerd wordt (bij een normale werking, dus zonder eventuele manipulatie).

Ik ben het met je eens dat het een gooed practice is om get, session en post los van elkaar te gebruiken. Maar het gaat hier puur om security. Stel je hebt een huis met 3 identieke voordeuren naast elkaar die allen niet op slot staan, dan maakt het mij niet uit door welke de inbrekers zijn binnen gekomen hoor.

Edit: @Janoz You got me there, ja zo had ik er nog niet over gedacht.

[ Voor 3% gewijzigd door cspare op 14-12-2007 11:59 ]

[PrisonerOfPain]

Erkens schreef op vrijdag 14 december 2007 @ 11:46:
[...]

Natuurlijk niet, zodra je weet dat een password via bijvoorbeeld GET of COOKIE verstuurd is ipv via POST bij het inloggen dan vertrouw ik het al niet en deny ik de request aangezien ik weet dat die met POST moet komen. Net zoals ik een session id alleen via COOKIE accepteer en niet via GET of POST.

Aan de andere kant zijn je controllers wel ineens een stuk flexibeler als je al je input via een uniforme interface beschikbaar maakt en word het ondersteunen van andere soorten requests (zoals JSON requests of REST) ook een stuk makkelijker en transparenter. In de meeste gevallen maakt het namelijk niet uit hoe je data binnenkomt (en word dat ook nog eens door je view bepaald). Kortom, de koppeling tussen controller en view word kleiner bij het gebruik van $_REQUEST (of een request object wat hetzelfde probeert de encapselen).

[Erkens]

cspare schreef op vrijdag 14 december 2007 @ 11:57:
Stel je hebt een huis met 3 identieke voordeuren naast elkaar die allen niet op slot staan, dan maakt het mij niet uit door welke de inbrekers zijn binnen gekomen hoor.

Dat behoort gewoon bij je normale checks die je toch al moet doen met al je input. Hier gaat het puur om dat je weet op welke manier die input gekomen is.

PrisonerOfPain schreef op vrijdag 14 december 2007 @ 11:58:
Aan de andere kant zijn je controllers wel ineens een stuk flexibeler als je al je input via een uniforme interface beschikbaar maakt en word het ondersteunen van andere soorten requests (zoals JSON requests of REST) ook een stuk makkelijker en transparenter. In de meeste gevallen maakt het namelijk niet uit hoe je data binnenkomt (en word dat ook nog eens door je view bepaald). Kortom, de koppeling tussen controller en view word kleiner bij het gebruik van $_REQUEST (of een request object wat hetzelfde probeert de encapselen).

Zodra je al zit met JSON of XML response vanaf de client dan heb je sowieso al niet te maken met cookies of get, dus waarom $_REQUEST gebruiken?

[_js_]

Als je ze maar niet door elkaar gebruikt, voor de rest is het niet een security risk. Stel je controleert naam en wachtwoord adhv van $_POST, en later kijk je of iemand wel toegang heeft door in $_REQUEST naar z'n naam te kijken, dan kan iemand in $_POST een geldige login hebben, maar met weinig rechten, en in een cookie een naam zetten die meer rechten heeft.

[Verwijderd]

_js_ schreef op vrijdag 14 december 2007 @ 15:28:
Als je ze maar niet door elkaar gebruikt, voor de rest is het niet een security risk. Stel je controleert naam en wachtwoord adhv van $_POST, en later kijk je of iemand wel toegang heeft door in $_REQUEST naar z'n naam te kijken, dan kan iemand in $_POST een geldige login hebben, maar met weinig rechten, en in een cookie een naam zetten die meer rechten heeft.

Persoonlijk denk ik dat je dit soort gegevens toch wel via je session object bijhoudt, alleen tijdens de login stuur je zulke gegevens over de lijn.

Ik denk dat het best allemaal meevalt met security risks, het is altijd zaak dat je input goed controleert, of het nou van $_GET, $_POST, $_COOKIE of $_REQUEST komt. Het zou me bijvoorbeeld niet uitmaken of er nou gebruik gemaakt wordt van $_GET of $_REQUEST voor navigatie variabelen, je moet toch wel controleren op injections en/of rechten.

Je zou ervoor kunnen kiezen om $_REQUEST niet te gebruiken, puur om het wat `lastiger` te maken om eventuele injections or whatever te doen.

[Voutloos]

Tja, of je leest de reactie van Janoz, want hij noemt dus wel een serieuze security risk. En met de opmerking dat hele volkstammen het verschil tussen GET en POST (idempotentie) niet weten kan ik het ook alleen maar roerend eens zijn.

9 vd 10x komt een bepaalde parameter alleen maar via 1 bepaalde vorm van input binnen en als je dan $_REQUEST gebruikt ben je imo gewoon lui/laks.

[DanielG]

Het enige wat ik kan bedenken waardoor het gebruik van $_POST t.o.v $_REQUEST veiliger is, is om je tegen CSRF (XSRF) door middel van de img tag (dus geen javascript) te beveiligen.

[Jochemmol]

Allereerst is user input checken altijd 'verplicht'.

addslashes kan niet altijd bv als iemand <script></script> in een $_GET zet. Omdat hij ziet dat dat een forum field is. of bv <img scr=”javascript:alert(‘test’);”>

Dus zowiezo meer doen dan alleen addslashes, maar ook htmlspecialchars() enz.

Stel een site heeft een cookie 'naam'. Vervolgens heb jij een site waarbij jij een POST doet met de variabele naam. Jij doet een $_REQUEST. Welke pakt hij nou???

Simpel de Cookie. Dit komt door de ranking van de GET, POST, REQUEST.

Als iemand nu zelf een cookie 'naam' maakt dan is het gevaarlijker.

Dus in mijn ogen gebruik netjes $_GET, $_POST ipv $_REQUEST.

[ Voor 9% gewijzigd door Jochemmol op 14-12-2007 16:29 ]

[MueR]

Ik kan het alleen maar eens zijn met hierboven. Door $_REQUEST te gebruiken ga je drie arrays met named keys mergen. Je kan dan niet met zekerheid zeggen welke variabelen je nu werkelijk gaat krijgen.

Persoonlijk haal ik alledrie de arrays altijd binnen via een class die ik geschreven heb. Deze dumpt netjes alles in private vars, sanitized en wel. Ben ik een stuk minder tijd kwijt door op allerlei paginas de post en get te moeten parsen.

[Patriot]

Jochemmol schreef op vrijdag 14 december 2007 @ 16:22:
Allereerst is user input checken altijd 'verplicht'.

addslashes kan niet altijd bv als iemand <script></script> in een $_GET zet. Omdat hij ziet dat dat een forum field is. of bv <img scr=”javascript:alert(‘test’);”>

Dus zowiezo meer doen dan alleen addslashes, maar ook htmlspecialchars() enz.

Laatstgenoemde hoeft pas bij het laten zien van de gegevens. Over het algemeen wordt er nogal overdreven gereageerd op het de hele issue. Er zijn een aantal manieren om data te zuiveren, en de beste manier is addslashes() en als je van MySQL gebruik maakt mysql_real_escape_string().

Er wordt nog wel eens overdreven door dingen als htmlspecialchars() en htmlentities() of zelfs het destructieve strip_tags() te gebruiken. Die zijn pas nodig als de gegevens in de output terecht komen, daar voor kun je het beter gewoon intact houden.

[Zerotorescue]

sjaakie schreef op vrijdag 14 december 2007 @ 11:31:
Ik had zojuist even een discussie met een collega en ik ben van mening dat het gebruik van $_REQUEST een security risk is, alleen al om het simpele feit dat je niet weet waar je input vandaan komt. Dus gewoon netjes $_GET, $_POST en $_COOKIE gebruiken.

Maar wat vinden jullie? Is $_REQUEST een security risk of niet?

Ik vind dat $_REQUEST wel een security risk is omdat alles wat via _GET wordt verstuurd kan worden gactivieerd dmv een plaatje, voorbeeldje:

http://domein.nl/admin.php?delete=UserName

Zet dit in een [ img][/img] tag en je zult zien dat dit script ook echt wordt uitgevoerd. Dit werkt hetzelfde op een loguit pagina, zou je http://gathering.tweakers.net/forum/logout in een image-tag zetten dan wordt iedereen (meestal) uitgelogt.

[ Voor 0% gewijzigd door Zerotorescue op 14-12-2007 18:28 . Reden: Typo's ]

[PrisonerOfPain]

Erkens schreef op vrijdag 14 december 2007 @ 14:11:
Zodra je al zit met JSON of XML response vanaf de client dan heb je sowieso al niet te maken met cookies of get, dus waarom $_REQUEST gebruiken?

$_REQUEST is de meest eenvoudige (en eenduidige) plaats om deze data in je applicatie te introduceren. In dit geval gebruik je $_REQUEST dan ook als abstractie voor het parsen en uitlezen van data zo hoeft de applicatie later amper aangepast te worden om toch meerdere request types te ondersteunen. (Persoonlijk laad ik de data in een vpRequest class, maar het verschil is nihil).

[Erkens]

PrisonerOfPain schreef op zaterdag 15 december 2007 @ 10:17:
$_REQUEST is de meest eenvoudige (en eenduidige) plaats om deze data in je applicatie te introduceren. In dit geval gebruik je $_REQUEST dan ook als abstractie voor het parsen en uitlezen van data zo hoeft de applicatie later amper aangepast te worden om toch meerdere request types te ondersteunen. (Persoonlijk laad ik de data in een vpRequest class, maar het verschil is nihil).

Je kan op die manier alleen nooit meerdere types gelijktijdig ondersteunen als je dat (al) zou willen. Dus een GET 'name' en een POST 'name' en eventueel ook nog een COOKIE 'name'

Verder, als je toch al een "request" klasse gebruikt, dan is het een kleine moeite om deze al deze verschillende types te ondersteunen waardoor je alsnog kan zien waar je variabele vandaan komt.

[PrisonerOfPain]

Erkens schreef op zaterdag 15 december 2007 @ 10:38:
[...]

Je kan op die manier alleen nooit meerdere types gelijktijdig ondersteunen als je dat (al) zou willen. Dus een GET 'name' en een POST 'name' en eventueel ook nog een COOKIE 'name'

Dat weet je nu ook al niet met $_REQUEST, hoewel je wel in kunt stellen wat de prioriteiten zijn van get, post en cookies door middel van de gpc_order setting. (Default is in die volgorde).

Verder, als je toch al een "request" klasse gebruikt, dan is het een kleine moeite om deze al deze verschillende types te ondersteunen waardoor je alsnog kan zien waar je variabele vandaan komt.

Enkel hoef je over het algemeen niet te weten waar je request variabele vandaan komt (zolang je maar weet dat 't een request variabele is) in de meeste gevallen wil je het toch hetzelfde afhandelen. (Hoewel dat bij REST nog wel eens tegen zou kunnen vallen natuurlijk maar dan moet je toch al een nieuw mechanisme bedenken; er is immers geen $_PUT en $_DELETE oid). Daarbij; je weet toch al zo min mogelijk van je data af, het is immers allemaal een string, en dat is ook bewust gedaan.
Verder kan mijn request object wel herkennen wat de oorspong is van een variabele; alleen raad ik het gebruik daarvan (natuurlijk) af, om de controllers flexibel te houden, zo is het ondersteunen van een ander request type letterlijk binnen 5 minuten gedaan.

[Erkens]

PrisonerOfPain schreef op zaterdag 15 december 2007 @ 14:00:
Dat weet je nu ook al niet met $_REQUEST, hoewel je wel in kunt stellen wat de prioriteiten zijn van get, post en cookies door middel van de gpc_order setting. (Default is in die volgorde).

Daarom moet je dus ook $_REQUEST niet gebruiken. Want zoals ik al zei, als je toch een eigen klasse gebruikt dan kan je dat stukje ook zelf doen, maar dan met behoud van de locatie waar ze vandaan kwamen.

Verder kan mijn request object wel herkennen wat de oorspong is van een variabele; alleen raad ik het gebruik daarvan (natuurlijk) af, om de controllers flexibel te houden, zo is het ondersteunen van een ander request type letterlijk binnen 5 minuten gedaan.

Waarom zou je dat willen? Via GET doe je requests om gegevens op te vragen, en met POST handel je requests af die dingen aanpassen. Zodra je dingen gaat aanpassen via GET ben je gewoon verkeerd bezig. Er is geen enkele reden om een mogelijkheid te hebben om plotseling alles met GET of POST te doen.

[Janoz]

Leesvoer voor een groot gedeelte van de mensen hier:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

Graag 9.1.1 en 9.1.2 doornemen ...

[sjaakie]

Mm het blijkt dus dat meningen nog enigszins verdeeld zijn. Maar toch hoor ik meer goede argumenten om gewoon netjes GPC te gebruiken ipv request.

Ik kan me niet helemaal aan het idee ontrekken dat $_REQUEST ook een beetje een luie manier van proggen is... ik denk dat dat komt omdat ik denk dat elke programmeur een controlefreak moet worden om een echte professional te worden. En als je een controlefreak bent, dan wil je ook controle hebben over waar je input vandaan komt... maar goed, das mijn mening...

[PrisonerOfPain]

sjaakie schreef op zondag 16 december 2007 @ 21:44:
ik denk dat dat komt omdat ik denk dat elke programmeur een controlefreak moet worden om een echte professional te worden.

Wat mij betreft wil je dat niet, over het algemeen wil je alles zo abstract mogelijk specificeren en dus zo veel mogelijk specifieke dingen aan de implementatie overlaten. Bij het ontwerp van een systeem wil je dus absoluut geen controle freak zijn ten goede van de flexibiliteit van je software.

Erkens schreef op zaterdag 15 december 2007 @ 18:04:
Waarom zou je dat willen? Via GET doe je requests om gegevens op te vragen, en met POST handel je requests af die dingen aanpassen. Zodra je dingen gaat aanpassen via GET ben je gewoon verkeerd bezig. Er is geen enkele reden om een mogelijkheid te hebben om plotseling alles met GET of POST te doen.

Controleren op het request type is mijns inziens een aparte zaak die vrijwel los staat van hoe de data naar de server verstuurd word. Waar de data vandaan komt is eigenlijk nooit relevant, wat voor soort request het is en hoe je het dus af moet handelen is veel interessanter om te weten.

[Alex)]

Ik gebruik het wisselend. Wanneer ik forms afhandel, bijvoorbeeld een registratieform, dan gebruik ik $_POST. Ik wil niet dat een of andere geinponem op een forum leuk een volledig uitgewerkte url spamt en zo een actie uitvoert die niet zou mogen worden uitgevoerd.

Als ik een list.php heb die gegevens uit de database plukt, dan wil ik dat kunnen pagineren met gewone hyperlinks. Maak ik echter een form, dan wil ik dat ook via POST kunnen ondersteunen.

De invoer die ik ontvang controleer ik toch wel op geldigheid, bij iets triviaals als data listen maakt het me niet uit of ik het paginanummer via GET, POST of COOKIE binnenkrijg (al is COOKIE wel lastig voor de eindgebruiker om aan te passen ), dus doe ik het met $_REQUEST.

[CyBeR]

Alles wat user input is, is untrusted. Een collega van mij heeft wat gemaakt voor php om input checking 'default' te maken: http://www.marcworrell.com/article-101-en.html. Een soort wrapper om een paar superglobals heen, zegmaar.

[FragFrog]

PrisonerOfPain schreef op zondag 16 december 2007 @ 22:09:
Wat mij betreft wil je dat niet, over het algemeen wil je alles zo abstract mogelijk specificeren en dus zo veel mogelijk specifieke dingen aan de implementatie overlaten. Bij het ontwerp van een systeem wil je dus absoluut geen controle freak zijn ten goede van de flexibiliteit van je software.

Hangt een beetje van je optiek af: als je een goed abstract systeem hebt hoort dat systeem als geheel welliswaar zoveel mogelijk manieren van input goed af te kunnen handelen, maar de interface hoort er wel voor te zorgen dat alles wat eenmaal het systeem in is gekomen goed en veilig is. Security at the door zogezegd, eventueel met raw toegang tot de onbeveiligde data indien dat echt nodig is. Classe variabelen bijvoorbeeld zal ik bijna altijd private maken met een specifieke methode om ze te getten en setten waar nodig, zodat ik altijd zeker weet dat wat er in die variabele staat veilig is voor members om te gebruiken.

Zo heb ik een tijdje terug een databasebulk class geschreven die 2 parameters wenst: tabelnaam en een array. Die array mag werkelijkwaar alles zijn, zelfs een string mocht je dat leuk vinden . De klasse gaat daarna aan de hand van de tabelnaam kijken wat voor kolommen er zijn, wat het type van elke kolom is, wat de lengte van elke kolom is en of'ie leeg mag zijn en vervolgens kijken of de members van de array onder die voorwaarden geinsert / geupdate kan worden. Voor de gebruiker toe betekend dit dat hij geen enkele check meer hoeft te doen (afgezien van logica checks natuurlijk ), voor mij betekend dit dat voor ik een daadwerkelijke insert doe ik zeker weet dat alle variabelen precies het goede type en formaat zijn (en natuurlijk geescaped ).

[Voutloos]

PrisonerOfPain schreef op zondag 16 december 2007 @ 22:09:
Controleren op het request type is mijns inziens een aparte zaak die vrijwel los staat van hoe de data naar de server verstuurd word. Waar de data vandaan komt is eigenlijk nooit relevant, wat voor soort request het is en hoe je het dus af moet handelen is veel interessanter om te weten.

Of het GET of POST is, is toch echt de belangrijkste eigenschap voor wat voor soort request het is.
Als je niet voor goed gebruik van het HTTP protocol bent, laat dan maar het hele security verhaal zitten, want dan hoef ik jouw web app al niet meer.

Het kan best dat je niet overal deze superglobals wil gebruiken, maar in de beginfase van je script moet gewoon iets zitten wat input correct afhandelt en om de communicatie correct te laten verlopen moet je het verschil tussen GET en POST weten.

Het leuke is dat als je het verschil kent (ik noemde al het woord idempotent en Janoz heeft inmiddels linkjes gegeven naar een stukje over idempotentie), dat je automatisch een heel hoop security issues vanzelf vermijd. Een user verwijderen? Goh, dat verandert iets, dus POST. En voila, geen probleem als een aanvaller een keer een link produceert in de hoop dat een ingelogde admin er iets mee doet.

[BikkelZ]

Voutloos schreef op maandag 17 december 2007 @ 08:15:
[...]
Of het GET of POST is, is toch echt de belangrijkste eigenschap voor wat voor soort request het is.
Als je niet voor goed gebruik van het HTTP protocol bent, laat dan maar het hele security verhaal zitten, want dan hoef ik jouw web app al niet meer.

Het kan best dat je niet overal deze superglobals wil gebruiken, maar in de beginfase van je script moet gewoon iets zitten wat input correct afhandelt en om de communicatie correct te laten verlopen moet je het verschil tussen GET en POST weten.

Het leuke is dat als je het verschil kent (ik noemde al het woord idempotent en Jazon heeft inmiddels linkjes gegeven naar een stukje over idempotentie), dat je automatisch een heel hoop security issues vanzelf vermijd. Een user verwijderen? Goh, dat verandert iets, dus POST. En voila, geen probleem als een aanvaller een keer een link produceert in de hoop dat een ingelogde admin er iets mee doet.

Hmmm nou laat ik het zo zeggen dat ik tussen $_GET en $_POST als ik ze ontvang eigenlijk een even strenge controle hang, maar dat ik alleen voor lezen $_GET gebruik. In het licht van waar deze discussie naar toe ging zit er dan inderdaad geen verschil tussen.

[PrisonerOfPain]

Voutloos schreef op maandag 17 december 2007 @ 08:15:
[...]
Of het GET of POST is, is toch echt de belangrijkste eigenschap voor wat voor soort request het is.

PHP:

return $_SERVER['REQUEST_METHOD'] == 'POST';

En dan verder je gegevens uit $_REQUEST trekken omdat het echt niet uitmaakt of je data uit de URL, een cookie of een formulier komt.

Als je niet voor goed gebruik van het HTTP protocol bent, laat dan maar het hele security verhaal zitten, want dan hoef ik jouw web app al niet meer.
[...]
Goh, dat verandert iets, dus POST. En voila, geen probleem als een aanvaller een keer een link produceert in de hoop dat een ingelogde admin er iets mee doet.

Vergis je niet, er zijn meer request methods als enkel POST; in een REST applicatie wil je bijvoorbeeld vaak DELETE, PUT en HEAD ook afhandelen.

[ Voor 8% gewijzigd door PrisonerOfPain op 17-12-2007 08:32 ]

[Voutloos]

Dat weet ik, maar GET en POST worden het meest door elkaar gebruikt. En veel mensen hebben de andere methodes nooit nodig, dus die spreken minder tot de verbeelding.

Overigens is jouw reply wel ironisch, want met $_REQUEST scheer je zelf alle methods over 1 kam.

[ Voor 23% gewijzigd door Voutloos op 17-12-2007 08:36 ]

[Janoz]

PrisonerOfPain, zou je alsjeblieft even die link door willen lezen? Ja, er zijn meerdere request methoden, maar die zijn keurig onderverdeeld. HEAD valt bijvoorbeeld onder de groep idempotente waar GET ook bij zit, terwijl DELETE en PUT weer vallen onder de groep waar POST ook bij zit. Het breekt dus op geen enkele manier af aan het verhaal van Voutloos.

[curry684]

MueR schreef op vrijdag 14 december 2007 @ 16:41:
Ik kan het alleen maar eens zijn met hierboven. Door $_REQUEST te gebruiken ga je drie arrays met named keys mergen. Je kan dan niet met zekerheid zeggen welke variabelen je nu werkelijk gaat krijgen.

Dat weet je wel, want in je PHP.ini staat de volgende definitie:

code:

variables_order =   "EGPCS"
                ; This directive describes the order in which PHP registers
                ; GET, POST, Cookie, Environment and Built-in variables (G, P,
                ; C, E & S respectively, often referred to as EGPCS or GPC).
                ; Registration is done from left to right, newer values override
                ; older values.

Op basis daarvan weet je dus dat cookies boven post gaan (tenzij expliciet anders geconfigureerd).

Dat detail daargelaten is Janoz' voorbeeld natuurlijk de gouden reden om gewoon netjes correcte parameterisering op basis van volledige herkomst te doen, en een perfecte illustratie van waarom luiheid nooit een reden mag zijn om brak te coden.