[php] magic_quotes_gpc vs addslashes() vs metaquote()

[mahi]

Hoi mensen,

Ik was wat opzoekwerk aan het doen over mogelijk misbruik van speciale tekens die je binnenkrijgt via GET/POST/COOKIE in PHP-scripts. Dat HTML entities misbruikt kunnen worden is me zeer duidelijk. Daarvoor gebruik ik dan ook htmlspecialchars() om deze potentiële gevaren om te zetten naar hun ongevaarlijke HTML-varianten bij weergave.

Maar blijkbaar kunnen GET/POST/COOKIE-variabelen ook misbruikt worden binnen PHP-scripts (dus niet alleen bij de uitvoer naar een HTML pagina). Begrijpelijk, maar ik had er eerlijk gezegd nog niet bij stil gestaan (hoewel ik kritieke variabelen wel door een reguliere expressie sleur).

Nu heb je addslashes() die de potentieel gevaarlijke karakters voorziet van backslashes. Als ik de handleiding goed begrijp dan doet magic_quotes_gpc = ON hetzelfde als addslashes() zodat je dit achterwege kan laten in je scripts. Correct?

Maar er is nog metaquote() waarvan het nut me niet helemaal duidelijk is. Ik snap wel uit de handleiding wat het meer doet dan addslashes(), maar niet waarom. Is het niet voldoende dat enkel ", ', \ en NUL van een extra \ worden voorzien?

Kan iemand gewoon een eenvoudig voorbeeld geven van waar metaquote() noodzakelijk zou zijn om misbruik te vermijden, want volgens mij overzie ik iets...

En dan een tweede bijvraagje. Hoe ver moet je eigenlijk gaan met het 'beveiligen' van de data die je binnenkrijgt via GET/POST/COOKIE? Bijvoorbeeld, ik heb een variabele $go die via GET wordt doorgegeven waaraan ik een door middel van een string een functie toeken die omschrijft wat er moet gebeuren:

...url.php?go=show

In het doel PHP-script wordt deze variabele met $_GET ingelezen en door magic_quotes_gpc voorzien van de nodige backslashes bij misbruik. Die $go variabele wordt enkel in een switch/case structuur gebruikt om te bepalen wat er juist gedaan moet worden. En als er geen case is die overeenkomt dan wordt een foutmelding getoond.
Is het hier noodzakelijk om bijvoorbeeld een metaquote() toe te passen? Of substr() / strlen() om de lengte ervan na te kijken?
Zoals ik het zie is dat overbodig. Als het niet voldoet aan de mogelijkheden in de case-structuur dan geeft ie sowieso een fout. Kan er dan wel misbruik van gemaakt worden?

[mahi]

Echt niemand die me wat meer duidelijkheid kan geven?

[pjonk]

mahi schreef op 21 February 2003 @ 16:32:
Nu heb je addslashes() die de potentieel gevaarlijke karakters voorziet van backslashes. Als ik de handleiding goed begrijp dan doet magic_quotes_gpc = ON hetzelfde als addslashes() zodat je dit achterwege kan laten in je scripts. Correct?

Dat is inderdaad correct. Addslashes hoef je dus alleen maar te doen indien magic_quotes_gpc uit staat.

PHP:

if (!get_magic_quotes_gpc()) { 
   // Voeg addslashes toe op GPC variabelen
}

Persoonlijk vind ik magic_quotes_gpc een van de irritantste features van PHP. Je wil vaak niet alle gegevens die via GET/POST/COOKIE in een SQL query gebruiken dus je hebt lang niet altijd die extra escapes nodig.

Maar er is nog metaquote() waarvan het nut me niet helemaal duidelijk is. Ik snap wel uit de handleiding wat het meer doet dan addslashes(), maar niet waarom. Is het niet voldoende dat enkel ", ', \ en NUL van een extra \ worden voorzien?

metaquote is er voor om wildcard characters te escapen die in (My)SQL een speciale betekenis hebben. Als je die tekens niet escaped behandeld SQL deze als wildcards in plaats van harde waarden.

Voorbeeld:
Stel je gaat zoeken in een database veld naar 20% via een dynamische SQL query met LIKE. Je krijg dan bijvoorbeeld de query:
SELECT * FROM tabel WHERE veld LIKE "20%"

Nu wordt er niet gezocht naar de waarde 20%, maar naar een waaarde 20 met met extra tekst erachter.

de query zou eigenlijk moeten zijn:
SELECT * FROM tabel WHERE veld LIKE "20\%"

Kan iemand gewoon een eenvoudig voorbeeld geven van waar metaquote() noodzakelijk zou zijn om misbruik te vermijden, want volgens mij overzie ik iets...

Je zou door het gebruik van deze wildcards meer uit de database kunnen halen dan je zou mogen zien. Maar dat hangt ook af of je bijv. een query met de LIKE operator gebruikt.

En dan een tweede bijvraagje. Hoe ver moet je eigenlijk gaan met het 'beveiligen' van de data die je binnenkrijgt via GET/POST/COOKIE? Bijvoorbeeld, ik heb een variabele $go die via GET wordt doorgegeven waaraan ik een door middel van een string een functie toeken die omschrijft wat er moet gebeuren:

...url.php?go=show

In het doel PHP-script wordt deze variabele met $_GET ingelezen en door magic_quotes_gpc voorzien van de nodige backslashes bij misbruik. Die $go variabele wordt enkel in een switch/case structuur gebruikt om te bepalen wat er juist gedaan moet worden. En als er geen case is die overeenkomt dan wordt een foutmelding getoond.
Is het hier noodzakelijk om bijvoorbeeld een metaquote() toe te passen? Of substr() / strlen() om de lengte ervan na te kijken?
Zoals ik het zie is dat overbodig. Als het niet voldoet aan de mogelijkheden in de case-structuur dan geeft ie sowieso een fout. Kan er dan wel misbruik van gemaakt worden?

Je zegt het zelf al dit is overbodig aangezien je in een switch al je validatie doet. Het belangrijkste blijft gewoon om al je GPC variabelen eerst te valideren voordat je er iets mee gaat doen.

metaquote() heb je volgens mij alleen echt nodig bij SQL queries in het voorbeeld dat ik heb genoemd. Ik heb het in ieder geval nog nooit gebruikt.

[ Voor 4% gewijzigd door pjonk op 23-02-2003 19:16 . Reden: typo's ]

[ACM]

mahi schreef op 21 February 2003 @ 16:32:
Maar blijkbaar kunnen GET/POST/COOKIE-variabelen ook misbruikt worden binnen PHP-scripts (dus niet alleen bij de uitvoer naar een HTML pagina). Begrijpelijk, maar ik had er eerlijk gezegd nog niet bij stil gestaan (hoewel ik kritieke variabelen wel door een reguliere expressie sleur).

Daar kunnen vooral in je database erge dingen mee gedaan worden, in je php-code niet zozeer.
Tenzij je de strings rechtstreeks in functies als eval of preg/ereg_* gebruikt. Voor de regular expressions zijn er allerlei tekens met speciale betekenissen (en in dit geval hebben we het vooral over de simpelere regexp-library ereg), deze zijn oa [, ], ?, * etc. quotemeta vervangt deze "regular expression meta characters" dus door de versie met een \ ervoor, zodat dat tekstje niet onbedoeld de werking van een regular expression verstoort.

Nu heb je addslashes() die de potentieel gevaarlijke karakters voorziet van backslashes. Als ik de handleiding goed begrijp dan doet magic_quotes_gpc = ON hetzelfde als addslashes() zodat je dit achterwege kan laten in je scripts. Correct?

Het nadeel van magic_quotes_gpc is dat het het impliciet doet, ook als het niet nodig is (als je de data direct naar je scherm stuurt bijv, dan is htmlspecialchars juist voldoende).

Maar er is nog metaquote() waarvan het nut me niet helemaal duidelijk is. Ik snap wel uit de handleiding wat het meer doet dan addslashes(), maar niet waarom. Is het niet voldoende dat enkel ", ', \ en NUL van een extra \ worden voorzien?

Vaak wel, in een aantal gevallen is het zelfs te veel, voor de wat professionelere databases moet je juist alleen de ' escapen (en dan vaak in '' veranderen) en de rest niet.

Kan iemand gewoon een eenvoudig voorbeeld geven van waar metaquote() noodzakelijk zou zijn om misbruik te vermijden, want volgens mij overzie ik iets...

Zodra je met ereg functies gaat werken, waarbij de string dus een onderdeel van de regexp is (en niet als je er je regexp op los laat). Voor de preg_* functies is er een preg_quotemeta oid.

Btw, een tip voor je. Als je mysql of postgresql gebruikt, gebruik dan niet addslashes voor het invoeren van je data in de db, maar mysql_/pgsql_escape_string, deze zijn ontwikkeld door de db-developers en doen veel beter wat er noodzakelijk is aan escapes dan addslashes.

En dan een tweede bijvraagje. Hoe ver moet je eigenlijk gaan met het 'beveiligen' van de data die je binnenkrijgt via GET/POST/COOKIE? Bijvoorbeeld, ik heb een variabele $go die via GET wordt doorgegeven waaraan ik een door middel van een string een functie toeken die omschrijft wat er moet gebeuren:

...url.php?go=show

In het doel PHP-script wordt deze variabele met $_GET ingelezen en door magic_quotes_gpc voorzien van de nodige backslashes bij misbruik. Die $go variabele wordt enkel in een switch/case structuur gebruikt om te bepalen wat er juist gedaan moet worden. En als er geen case is die overeenkomt dan wordt een foutmelding getoond.
Is het hier noodzakelijk om bijvoorbeeld een metaquote() toe te passen? Of substr() / strlen() om de lengte ervan na te kijken?
Zoals ik het zie is dat overbodig. Als het niet voldoet aan de mogelijkheden in de case-structuur dan geeft ie sowieso een fout. Kan er dan wel misbruik van gemaakt worden?

De belangrijkste "eis" is dat je zo min mogelijk overlaat aan de willekeur van een gebruiker.
Dus als jij zoiets deed: url.php?go=show.php, en dat laad dan de file show.php ben je fout bezig. Maar als je via een switch/case enkel en alleen een beperkt aantal acties toelaat, dan lijkt me er niets mis mee en aangezien voor een switch-case het niet boeit hoe lang de string is en wat voor karakters ie bevat (zolang ie maar voldoet aan een van de cases, anders wordt er niks/de default actie gedaan) hoef je er daar niet druk om te maken.

Er is echter geen generiek antwoord op zo'n vraag te geven, per situatie kan dat verschillen. Als je een filebrowser achtig iets maakt zou je bijvoorbeeld kunnen controleren of er geen /, $ en . in de naam zit...

[ACM]

JonkieXL schreef op 23 February 2003 @ 19:13:
metaquote is er voor om wildcard characters te escapen die in (My)SQL een speciale betekenis hebben. Als je die tekens niet escaped behandeld SQL deze als wildcards in plaats van harde waarden.

Voorbeeld:
Stel je gaat zoeken in een database veld naar 20% via een dynamische SQL query met LIKE. Je krijg dan bijvoorbeeld de query:
SELECT * FROM tabel WHERE veld LIKE "20%"

Nu wordt er niet gezocht naar de waarde 20%, maar naar een waaarde 20 met met extra tekst erachter.

de query zou eigenlijk moeten zijn:
SELECT * FROM tabel WHERE veld LIKE "20\%"

string quotemeta ( string str)

Returns a version of str with a backslash character (\) before every character that is among these:

. \\ + * ? [ ^ ] ( $ )

* ACM ziet er geen % in terug

Maar even wat serieuzer, quotemeta is juist _niet_ primair voor de communicatie met databases bedoelt, voor zover ik het begrijp iig.

metaquote() heb je volgens mij alleen echt nodig bij SQL queries in het voorbeeld dat ik heb genoemd. Ik heb het in ieder geval nog nooit gebruikt.

Juist niet dus

edit:

Volgens mij zijn de usercomments bij quotemeta complete onzin...

[ Voor 4% gewijzigd door ACM op 23-02-2003 19:40 ]

[pjonk]

ACM schreef op 23 February 2003 @ 19:37:
* ACM ziet er geen % in terug

Hmm zie het nu ook. Slecht voorbeeld, maar het gaat hier dus wel om het escapen van wildcards.

Ik zie nu in de user comments het volgende staan:
This function escapes characters that have special meaning in regular expressions. preg_quote() http://php.net/manual/en/function.preg-quote.php has similar functionality, but is more powerful since it escapes more characters (including one user-specified character).

Maar daar zeggen ze dat je nog beter preg_quote kan gebruiken.

[ACM]

Ook alleen maar als je het nodig hebt dus he?

[mahi]

Hartelijk dank voor jullie antwoorden! Ik ben weer heel wat wijzer geworden