$_REGISTER soms wel soms niet

[Verwijderd]

Hoi, ik ben op school bezig met een project. Nou heb ik altijd forms gepost met method post en normaal gesproken ving ik die op met $_POST[$variable']; . Nou is het echter dat mij aangeraden werd om $_POST en/of $_GET met $_REQUEST op te vangen. Nou ik een scriptje gemaakt met ene form en netjes de informatie gepost en op de volgende pagina met $_REQUEST opgevangen. Werkt helemaal mooi op mijn computer thuis als ik hem van me webserver opvraag, bij me vrienden werkt het. maar op het (beveiligde) school netwerk stuurt ie wel de $_GET mee als ikd ie opvang met $_REQUEST maar niet de $_POST als ik die op dezelfde pagina ook met $_REQUEST opvang. Dit is toch best wel raar gezien het feit dat PHP serverside is. KAn het aan $_REQUEST liggen ? of iemand anderre suggesties ?

[Voutloos]

Veel belangrijker: Weet je het verschil tussen GET en POST?

[Verwijderd]

Gewoon $_GET en $_POST gebruiken. Klaar.

[Verwijderd]

dank voor de snelle reaktie. en voorzover ik weet is het verschil tussen $_GET dat het zichtbaar is in de adressbalk wat hij send en bij $_POST niet. En inderdaad ik zou het kunnen verandrren maar vraag me ook echt af wat het verschil dan is waarom hij het niet doet aangezien me leraar het me juist aanraad

[JayVee]

Hier een artikel dat uitlegt wanneer je POST en GET moet gebruiken. Sterk verkort: gebruik GET, tenzij er data gewijzigd wordt.

[Cousin Boneless]

Ik vermoed dat er een proxy server je (POST) dataverkeer met de buitenwereld zit te vernaggelen.
Een snelle analyse kan bestaan uit het aanmaken van een simpel script:

PHP:

<?php
phpinfo();
?>

Noem dit bijvoorbeeld phpinfo.php
Verander je action attribuut in het form zodat het naar 'phpinfo.php' verzendt. En als je het verzendt zie je alle globale variabelen vermeld staan onder 'PHP Variables'. Staan je POST variabelen er niet tussen dan zou ik een bezoekje brengen aan het systeembeheer.

[ Voor 10% gewijzigd door Cousin Boneless op 18-08-2008 23:03 ]

[Patriot]

In de titel heb je het over $_REGISTER, je hebt die fout niet toevallig ook in je script gemaakt?

[Verwijderd]

Dank voor je reaktie Cousin Boneless,

dit lijkt mij inderdaad de meest rrealistisch veroorzaker van het probleem. Vind wel jammer dat een proxy server dit gewoon kan vernagellen. Is er eventueel een optie in php.ini voor waardoor hij deze script wel doorzet. Ken me namelijk nu al inbeelden als ik in de toekomst groterre projecten moet maken, dit zeer irritant is.

[Cartman!]

Raar dat iemand je aanraad om $_REQUEST te gebruiken, zet dan gewoon meteen register_globals aan. $_GET en $_POST zijn juist beter dan $_REQUEST omdat je dan min of meer weet waar de data vandaan komt (form of url).

[Verwijderd]

Hoi, het is inderdaad minder overzichtelijk. Ik vraag mij alleen af of er een mogelijkheid is server-side zoals bv in de php.ini of httpd.conf file, met een anderre of extra instellingen te werken waardoor bijvoorbeeld bedrijfs proxy servers me POST data niet tegen houden. Dit lijkt me toch wel een redelijke mogelijkheid die aanwezig moet zijn.... anders kunnen een hoop bedrijfen niet goed gebruik maken van PHP sites. Of is er een anderre manier van data verzenden waar bv grote bedrijfs applicaties op php gebaseerd gebruik van maken ?

[Verwijderd]

Het doel van die hele proxy is om juist dat soort dingen niet te laten werken. Het is dus geen server side instelling bij jou. Het is een instelling op de proxy server en daar heb je geen beheer over.

[LuCarD]

Waarschijnlijker heeft er iemand lopen kloten met de php.ini.

En heeft de variables order lopen aanpassen.
http://nl.php.net/ini.core

[Verwijderd]

Hey dank voor je reaktie heb even gekeken maar helaas zie ik dat variables_order op EGPCS staat zoals ook aangegeven op de php site zag wel op internet diverse bypass proxy php scripts.. is dit wat of iemand een beterre oplossing ?

[Zyppora]

Als het inderdaad aan de proxy ligt, kun je dit dan niet aangeven bij je leerkracht? Lukt het lokaal wel? En zoals al eerder gezegd: je zult eerst het verschil tussen GET en POST (en REQUEST) moeten begrijpen voordat je een gefundeerde keuze kunt maken. Wees daarom ook kritisch naar de persoon die jouw REQUEST heeft aangeraden. Vraag bijvoorbeeld waarom hij of zij dat aanraadt.

[Verwijderd]

Oke dankje voor je reaktie, inmiddels zijn we er achter gekomen dat het door de proxy server komt. Gewoon nu puur uit nieuwschierigheid, zijn er manieren deze te omzeilen... dmv van een Proxy bypass script bijv ? werkt dit ook in de meeste gevallen ?

[Janoz]

Vanaf de server heb je hier 0,0 invloed op. De boel is immers al vernachelt nog voordat het uberhaupt bij je eigen server aankomt. Iets wat daarvoor weggehaalt is kun je immers er niet meer zomaar bij verzinnen...

[Voutloos]

En dergelijke proxy (en sommige virusscanners zijn soms ook wat overijverig) vernaggelt gewoon de bruikbaarheid van complete sites, dus neem contact op met de beheerder, want dit is niet jouw probleem/schuld.

[Patriot]

Cartman! schreef op dinsdag 19 augustus 2008 @ 08:52:
Raar dat iemand je aanraad om $_REQUEST te gebruiken, zet dan gewoon meteen register_globals aan. $_GET en $_POST zijn juist beter dan $_REQUEST omdat je dan min of meer weet waar de data vandaan komt (form of url).

Er is natuurlijk een wezenlijk verschil, bij register globals kunnen gewone variabelen worden veranderd, dat is niet het geval bij het gebruik van $_REQUEST. Of een variabele nu van de POST-variabele of van de GET-variabele komt is niet interessant, beiden zijn onveilig en moeten als zodanig worden behandeld.

Daarbij ben ik het wel met je eens dat het nergens op slaat om aan te raden _REQUEST te gebruiken.

_{edit: POST-request en GET-request veranderd in respectievelijke POST-variabele en GET-variabele, zie Patriot in "$_REGISTER soms wel soms niet"}

[ Voor 12% gewijzigd door Patriot op 19-08-2008 15:41 ]

[Voutloos]

Het is niet op 1 op 1 eenzelfde security probleem. Maar als je het verschil tussen GET en POST begrijpt (idempotentie), weet je ook waarom het een onveilig idee is om het op 1 hoop te gooien.

[ Voor 4% gewijzigd door Voutloos op 19-08-2008 11:47 ]

[Patriot]

Voutloos schreef op dinsdag 19 augustus 2008 @ 11:47:
Het is niet op 1 op 1 eenzelfde security probleem. Maar als je het verschil tussen GET en POST begrijpt (idempotentie), weet je ook waarom het een onveilig idee is om het op 1 hoop te gooien.

Het is niet onveilig om niet-idempotente acties uit te voeren bij een GET-request, maar het is misbruik van het HTTP-protocol.

EDIT: Wel onveilig dus. Als blijkt uit de reactie hieronder.

[ Voor 7% gewijzigd door Patriot op 19-08-2008 16:02 ]

[Janoz]

Patriot schreef op dinsdag 19 augustus 2008 @ 11:35:
[...]


Er is natuurlijk een wezenlijk verschil, bij register globals kunnen gewone variabelen worden veranderd, dat is niet het geval bij het gebruik van $_REQUEST. Of een variabele nu van een POST request of van een GET request komt is niet interessant, beiden zijn onveilig en moeten als zodanig worden behandeld.

Daarbij ben ik het wel met je eens dat het nergens op slaat om aan te raden _REQUEST te gebruiken.

Of iets vanaf POST of GET komt is wel degelijk interessant! Er is een wezelijk verschil tussen beiden. Omdat dit verschil zich niet direct in de techniek uit is het iets dat veel (web)ontwikkelaars gewoonweg niet weten.

In het kort komt het er op neer dat een GET 'herhaalbaar' moet zijn zonder dat het request zelf invloed heeft op de state van het resultaat. Denk hierbij aan het opvragen van een nieuwsitem (met ?id=x) of een forumthread.

Een POST moet gebruikt worden op het moment dat het request de state veranderd. Het posten van een nieuwe reactie bij dat nieuwsbericht of het wijzigen van het bericht zelf. Het request kan dus niet zomaar twee keer uitgevoerd worden.


Er is wel degelijk een security risico wanneer POST en GET variabelen op 1 hoop gegooid worden. Een beheerder van een website die geen onderscheid hiertussen maakt kan ik acties uit laten voeren door hem simpel naar een pagina te lokken. Een plaatje in een reactie zetten met als url site.nl/admin.php?actie=promoveerTotAdmin&user=janoz en er een admin naar laten kijken is genoeg....


-edit-
Ah, alweer twee reacties er tussen. Ik hoop dat ik in de laatste alinea laat zien waarom niet idempotente acties uit te voeren bij een GET-request wel onveilig kan zijn.

Schiet me net te binnen. Problemen omtrent de google webaccelerator waren een rechtstreeks gevolg van websites die zich niet aan deze conventie hielden.

-edit2-
Er was inderdaad een negatie vergeten

[ Voor 10% gewijzigd door Janoz op 20-08-2008 13:39 ]

[Verwijderd]

Iedereen heel erg bedankt voor al het advies, en zal me er inderdaad bij neer moeten leggen dat ik niet echt wat aan dit probleem ken doen. Vond het ook leerzaam over $_GET en $_POST toch te horen hoe programmeurs die oppikken.

[Patriot]

Janoz schreef op dinsdag 19 augustus 2008 @ 11:51:
[...]

Of iets vanaf POST of GET komt is wel degelijk interessant! Er is een wezelijk verschil tussen beiden. Omdat dit verschil zich niet direct in de techniek uit is het iets dat veel (web)ontwikkelaars gewoonweg niet weten.

In het kort komt het er op neer dat een GET 'herhaalbaar' moet zijn zonder dat het request zelf invloed heeft op de state van het resultaat. Denk hierbij aan het opvragen van een nieuwsitem (met ?id=x) of een forumthread.

Een POST moet gebruikt worden op het moment dat het request de state veranderd. Het posten van een nieuwe reactie bij dat nieuwsbericht of het wijzigen van het bericht zelf. Het request kan dus niet zomaar twee keer uitgevoerd worden.


Er is wel degelijk een security risico wanneer POST en GET variabelen op 1 hoop gegooid worden. Een beheerder van een website die geen onderscheid hiertussen maakt kan ik acties uit laten voeren door hem simpel naar een pagina te lokken. Een plaatje in een reactie zetten met als url site.nl/admin.php?actie=promoveerTotAdmin&user=janoz en er een admin naar laten kijken is genoeg....


-edit-
Ah, alweer twee reacties er tussen. Ik hoop dat ik in de laatste alinea laat zien waarom idempotente acties uit te voeren bij een GET-request wel onveilig kan zijn.

Schiet me net te binnen. Problemen omtrent de google webaccelerator waren een rechtstreeks gevolg van websites die zich niet aan deze conventie hielden.

Ok, ik zie nu dat ik het verkeerd neer heb gezet. Ik had het over niet interessant uit welke request, maar ik bedoelde uit welke variabele het kwam (_POST of _GET). Ik wilde dus niet zeggen dat niet-idempotente acties uitvoeren bij een GET-request veilig was, dat is het inderdaad niet. Ik heb het verkeerd neergezet en ik snap dat daaruit verwarring is ontstaan, solly

Mijn post daarna is natuurlijk sowieso fout!

[Voutloos]

De verwarring is (iig bij jou) compleet omdat het punt is dat juist GET voor idempotente acties is.

Maar aangezien er dus een verschil is, moet je dus dat verschil in je code handhaven. Zo zie je in je code direct met voor actie je bezig bent en of dat qua HTTP gebruik klopt.

[Patriot]

Voutloos schreef op dinsdag 19 augustus 2008 @ 15:48:
De verwarring is (iig bij jou) compleet omdat het punt is dat juist GET voor idempotente acties is.

Maar aangezien er dus een verschil is, moet je dus dat verschil in je code handhaven. Zo zie je in je code direct met voor actie je bezig bent en of dat qua HTTP gebruik klopt.

Ok, ik heb het inderdaad omgedraait, net als Janoz overigens. Bovendien is het de manier waarop ik het gebruik, de manier waarop ik de wiki interpreteer. Vandaar die verwarring

[Voutloos]

De tekst op die Nederlandse pagina slaat gewoon echt als een tang op een varken.