$_GET beveiligen

[lauwsa]

Heeej,

Ik beveilig altijd mijn $_GET's zo:

code:

    if(is_numeric($_GET["id"])) {
        $id = $_GET["id"];
    } else {
        $id = "0";
    }
        
    if(is_numeric($_GET["g"])) {
        $g = $_GET["g"];
    } else {
        $g = "0";
    }

Zo weet ik zeker dat het een nummer is en dat ik hem veilig overal kan gebruiken, alleen mijn vraag is, kunnen ze niet uit de is_numeric() breken?
Ik denk van niet,
Ik kan wel vinden dat als je een gegevens van een user op je site wilt outputten dat je html_special_chars moet gebruiken, in een database mysql_real_escape_string als addslashes niet standaard aan staat. etc etc

[Sebazzz]

Waarom gebruik je niet gewoon mysql_real_escape_string? Naar numeriek omvormen is meer symptoombestrijding. Overigens kan je hem ook casten naar een integer:

PHP:

$id = (int) $_GET["id"];

[CyBeR]

lauwsa schreef op donderdag 21 oktober 2010 @ 17:56:
Heeej,

Zo weet ik zeker dat het een nummer is en dat ik hem veilig overal kan gebruiken, alleen mijn vraag is, kunnen ze niet uit de is_numeric() breken?

Daarvoor moet je even kijken wat is_numeric() precies doet in de source van php. Vermoedelijk is 't een vrij simpel loopje waar weinig mee te klooien valt.

[lauwsa]

owja dat kan hier ook, bedankt. Ik gebruik geen mysql_real_escape_string omdat het een getal moet zijn wat ik nodig heb, en casten had ik nog niet aan gedacht, bedankt

[Icelus]

Sebazzz schreef op donderdag 21 oktober 2010 @ 17:58:
Waarom gebruik je niet gewoon mysql_real_escape_string? Naar numeriek omvormen is meer symptoombestrijding. Overigens kan je hem ook casten naar een integer:

PHP:

$id = (int) $_GET["id"];

Gaat helaas mis bij iets als:

PHP:

$id = (int) "2a"; // $id = 2

[Sebazzz]

Icelus schreef op donderdag 21 oktober 2010 @ 18:02:
[...]
Gaat helaas mis bij iets als:

PHP:

$id = (int) "2a"; // $id = 2

Dat lijkt mij prima gedrag.

[lauwsa]

Als er niks uit komt is het toch gewoon niks, dus null. Dat maakt dan toch niks uit.
De get moet een getal zijn anders maak ik het zelf 0.

Maar ik ga het nu even uitproberen.
Het word dan 0, bedankt!
Dat is best wel een grote verkoring.

[ Voor 15% gewijzigd door lauwsa op 21-10-2010 18:12 ]

[.oisyn]

Sebazzz schreef op donderdag 21 oktober 2010 @ 18:08:
[...]

Dat lijkt mij prima gedrag.

Mij niet. "2a" is niet hetzelfde als "2". "a2" wordt toch ook geen 2?

[ Voor 6% gewijzigd door .oisyn op 21-10-2010 18:18 ]

[Cartman!]

Hoe veilig denk je dat het is? Vang je het nog af als iemand "1e4" doorgeeft? of "0xFF"? Die valideren gewoon op is_numeric maar ik gok erop dat dit niet is wat jij wilt. Pak dan eerder ctype_digit(), die checkt of een string (!) bestaat uit enkel getallen.

[lauwsa]

Maar kan het dan veel kwaad als je 0xFF door geeft,
want hij kijkt oa als het in de db voor komt, maar dat breekt toch niet echt ergens uit.

Maar bedankt , dit is wel handig voor andere keren.

[Sebazzz]

.oisyn schreef op donderdag 21 oktober 2010 @ 18:17:
[...]

Mij niet. "2a" is niet hetzelfde als "2". "a2" wordt toch ook geen 2?

Als het gewoon gedocumenteerd is, dan is het prima gedrag. Zo werkt het gewoon in PHP.

[Osiris]

Cartman! schreef op donderdag 21 oktober 2010 @ 18:49:
Hoe veilig denk je dat het is? Vang je het nog af als iemand "1e4" doorgeeft? of "0xFF"? Die valideren gewoon op is_numeric maar ik gok erop dat dit niet is wat jij wilt.

Waarom niet? Het is gewoon een andere manier van noteren.. (En derhalve "gewoon" een getal.) Het ligt er maar net aan wát ie er mee gaat doen hè en of de volgende stappen het ook als getal accepteren.

Dat 1e4 een nogal groot getal is wat mísschien buiten de gebruikte range valt is een compleet ander verhaal en afhankelijk van volgende restricties die de TS wellicht ingebouwd heeft.

MySQL pakt iig gewoon 0x0a als hexadecimale vorm van decimaal 10 in een query, dussuh.. En ook 1e4 als 10 000.

[ Voor 7% gewijzigd door Osiris op 21-10-2010 20:12 ]

[ray538]

Als aanvulling op de besproken "1e4" en "0xFF": ook kommagetallen worden doorgelaten door is_numeric() (het is immers een numeriek getal). Het vormt in principe geen veiligheidsrisico (in de zin van SQL injection) om is_numeric te gebruiken, maar ik ben van mening dat je moet controleren op dat wat je verwacht. In veel gevallen gaat het om ID's in een database. Je verwacht dus een geheel numeriek getal en controleert dus ook of dat aanwezig is (en niet of een gebruiker een of andere andere notatie heeft gebruikt) met ctype_digit().

[YopY]

Maar nu even terug. Het topic gaat over 'beveiligen' van de invoer van cijfers. Kan er dan ingebroken worden als je id=2e of id=0xff of id=1,337 doet? Of is het meer het voorkomen van fouten aan de gebruikerskant?

[ReenL]

http://nl3.php.net/is_numeric

'42' is numeric
'1337' is numeric
'1e4' is numeric
'not numeric' is NOT numeric
'Array' is NOT numeric
'9.1' is numeric

Ofwel wiskundige notaties mogen ook. Zoals al eerder gezegt in dit topic. Zoals ray538 zegt doet ctype_digit wat je wil.

Let wel op ctype_digit werkt alleen op strings, dus:

PHP:

ctype_digit(0); // Dit doet niet wat je verwacht
ctype_digit("0"); // Dit doet wel wat je verwacht, en _GET is altijd een string of een array.

Ik zie altijd graag of een array uit de url komt daarom pas ik de waarde in de _GET meestal gewoon aan:

PHP:

if ( !ctype_digit($_GET['a']) ) {
    $_GET['a'] = 0;
}

Maar dat is een kwestie van smaak.

(..) Het topic gaat over 'beveiligen' van de invoer van cijfers.(...)

SQL errors en ik heb me ooit laten vertellen dat MySQL het moeilijk kan hebben met extreem grote getallen, maar pin me daar niet aan vast.

Daarnaast is het naar mijn mening een (beveligings-)lek op het moment dat de gebruiker iets anders kan invoeren dan je verwacht. Je laat het gat in je muur ook niet zitten omdat het nog steeds niet koud is.

[ Voor 23% gewijzigd door ReenL op 21-10-2010 20:38 . Reden: Laatste quote toegevoegd ]

[FragFrog]

YopY schreef op donderdag 21 oktober 2010 @ 20:24:
Maar nu even terug. Het topic gaat over 'beveiligen' van de invoer van cijfers. Kan er dan ingebroken worden als je id=2e of id=0xff of id=1,337 doet? Of is het meer het voorkomen van fouten aan de gebruikerskant?

Als je database errors uitspuugt in plaats van netjes naar een errorlog schrijft? Ja, dat geeft een hacker informatie die hij niet had moeten hebben. PHP mag bepaalde strings dan zien als getal, dat betekent nog niet dat het ook goed gaat wanneer je ze gebruikt in een query die een int verwacht.

Casten naar een int is in mijn opinie de beste oplossing. Als een gebruiker dan bewust foutieve informatie erin stopt krijgt hij exact dezelfde info als wanneer hij het ID aanpast, en dat laatste kun je toch niet voorkomen. Het zal nooit exceptions opleveren of op een andere manier je code stukmaken. Bovendien is het korter en simpeler (dus minder foutgevoelig) dan een check op numeriek + else conditie. Stel dat je die "else $value = 0" een keer vergeet ga je vervolgens nog veel vagere errors krijgen, maar kom je daar niet achter tot je daadwerkelijk eens foutieve info gaat invoeren - en laten we eerlijk zijn, als je daar geen testers voor hebt wil er nog wel eens eentje doorheen slippen

[ Voor 19% gewijzigd door FragFrog op 21-10-2010 20:33 ]

[frickY]

Sebazzz schreef op donderdag 21 oktober 2010 @ 18:08:
Dat lijkt mij prima gedrag.

Foute input is gewoon fout, ook als je er toch iets van zou kunnen maken.
Of voeg je ook 7 voorloop nullen toe als iemand 123 als telefoonnummer invoert?

Als iemand een ID moet geven dan moet je ook een ID eisen. Dan moet je niet de input zodanig gaan converteren tot je er een ID uit kunt herleiden.

@ReenL
Schrijven naar één van de superglobals is, met uitzondering van $_SESSION, ook geen goed idee.
Houd user-input en variabelen die je gevalideerd hebt gescheiden, zodat je altijd weet welke je kunt vertrouwen en welke niet.

[ Voor 42% gewijzigd door frickY op 21-10-2010 20:33 ]

[Gamebuster]

PHP:

$a = (int)$_GET['a'];

Lijkt mij voldoende.

Wat de input ook was, er komt altijd een geldig numeriek getal uit. Bij vreemde input kunnen er misschien wat vreemde resultaten vormen, maar dit zal nooit een beveiligingsprobleem zijn voor je queries.

mysql_real_escape_string is dan ook niet nodig, aangezien $a geen "string" is.

Toch, misschien eens kijken naar PDO met Prepared Statement?

[ Voor 72% gewijzigd door Gamebuster op 21-10-2010 20:35 ]

[ReenL]

@frickY
Zoals ik al zei een kwestie van smaak. In mijn code kan je in een oogopslag zien welke variablen van de gebruiker komen en dus niet te vertrouwen zijn. Bij jou code moet je vertrouwen dat alle globals goed zijn omgezet naar non-globals.

@Gamebuster
Als je gewoon cast naar een int en iemand maakt een typo: 12`345 dan krijgt hij geen foutmelding maar dan gaat hij naar entry 12.

[Gamebuster]

ReenL schreef op donderdag 21 oktober 2010 @ 20:38:
@frickY
Zoals ik al zei een kwestie van smaak. In mijn code kan je in een oogopslag zien welke variablen van de gebruiker komen en dus niet te vertrouwen zijn. Bij jou code moet je vertrouwen dat alle globals goed zijn omgezet naar non-globals.

@Gamebuster
Als je gewoon cast naar een int en iemand maakt een typo: 12`345 dan krijgt hij geen foutmelding maar dan gaat hij naar entry 12.

Dan moet diegene geen typo maken / clientside controleren in Javascript / html SELECT-element gebruiken.

Text-input moet je naar mijn mening als tekst behandelen. Iemand een getal laten typen en als getal behandelen moet je vermijden naar mijn mening.

[ Voor 12% gewijzigd door Gamebuster op 21-10-2010 20:42 ]

[Pendaco]

Waarom niet gebruik maken van de filter vars, dan kun je iig nog een range opgeven?

PHP:

$id = filter_var($_GET['id'], FILTER_VALIDATE_INT);

[EdwinG]

Pendaco schreef op donderdag 21 oktober 2010 @ 20:55:
Waarom niet gebruik maken van de filter vars, dan kun je iig nog een range opgeven?

filter_var() is, helaas, niet perfect. Misschien dat het voor getallen goed werkt, maar vertrouw niet op de functie voor alle types die er, volgens de handleiding, mee te valideren zijn. Crisp heeft daar een mooie Blogpost over geschreven. (Deze post is uit juni 2009, ik weet niet wat er ondertussen aan filter_var() is veranderd)

[Patriot]

frickY schreef op donderdag 21 oktober 2010 @ 20:31:
[...]

Foute input is gewoon fout, ook als je er toch iets van zou kunnen maken.
Of voeg je ook 7 voorloop nullen toe als iemand 123 als telefoonnummer invoert?

Als iemand een ID moet geven dan moet je ook een ID eisen. Dan moet je niet de input zodanig gaan converteren tot je er een ID uit kunt herleiden.

Ik zie niet wat er mis is met het proberen fouten van de gebruiker te corrigeren. Het toevoegen van 7 voorlopnullen is onzin, maar een telefoonnummer dat in een internationaal format moest worden ingevuld maar is ingevuld in een nationaal format kun je in mijn ogen best proberen te corrigeren. Je moet de gebruiker weliswaar de kans geven zijn fout te corrigeren, maar de gebruiker daar een handje mee helpen is niet verkeerd.

[RaZ]

Zo'n veld kan je inderdaad corrigeren. Maar de TS heeft het over dat ie het met elk veld eigenlijk doet.

Over het algemeen gooi je invoervelden in post, en niet get. De get heb je altijd zelf in de hand, zeker als het gaat om ID's. Als je dan eist dat iets nummeriek is, moet je nooit een string accepteren, en daar een nummeriek van maken.

Nu zeg je gewoon: "2a" == "2", en draai maar door. Nee, de input klopt niet, dus fout afhandelen..

[RobIII]

RaZ schreef op donderdag 21 oktober 2010 @ 23:11:
Over het algemeen gooi je invoervelden in post, en niet get.

Vertel dat google even, die snappen 't schijnbaar nog niet Met andere woorden: je snijdt de bocht hier zo krap dat je de hoekwoning kortwiekt

http://www.cs.tut.fi/~jkorpela/forms/methods.html

RaZ schreef op donderdag 21 oktober 2010 @ 23:11:
De get heb je altijd zelf in de hand, zeker als het gaat om ID's.

Care to explain? Hoe heb je een GET meer (of minder) "in de hand" dan een POST

[ Voor 48% gewijzigd door RobIII op 21-10-2010 23:19 ]

[Verwijderd]

RobIII schreef op donderdag 21 oktober 2010 @ 23:14:
[...]

Vertel dat google even, die snappen 't schijnbaar nog niet

Denk je niet dat GET opzettelijk gebruikt wordt zodat je meteen de juiste link kunt doorsturen voor bepaalde zoekresultaten?

[RobIII]

Verwijderd schreef op donderdag 21 oktober 2010 @ 23:18:
[...]


Denk je niet dat GET opzettelijk gebruikt wordt zodat je meteen de juiste link kunt doorsturen voor bepaalde zoekresultaten?

Idempotence is het sleutelwoord

[RaZ]

Uhm... Nee... Google doet dat ook niet.. Met Id's als bijvoorbeeld een pagina nummer.

Kijk op welke pagina hij staat, terwijl ik aangeef dat het nummer "3e" is. Dan krijg je gewoon pagina 1, en niet pagina 3. Google accepteerd dus die string niet als nummeric

Hij negeerd hier gewoon de string, veld is niet nummeriek, dus pagina 1.

Klik

[ Voor 8% gewijzigd door RaZ op 21-10-2010 23:25 ]

[Verwijderd]

tweakers doet het andersom:

http://gathering.tweakers.net/forum/list_messages/1430931/1P gaat gewoon naar pagina 2 van dit topic

[RobIII]

RaZ schreef op donderdag 21 oktober 2010 @ 23:24:
Uhm... Nee... Google doet dat ook niet.. Met Id's als bijvoorbeeld een pagina nummer.

En de query zelf dan? Dat is namelijk een invoerveld en wordt gewoon in de GET gemikt! Oeh! Gevaarlijk! Ik reageerde op (en quotte dus ook):

RaZ schreef op donderdag 21 oktober 2010 @ 23:11:
Over het algemeen gooi je invoervelden in post, en niet get.

Maar lees mijn linkje ook even; dan snap je wat ik bedoel. Dat google een ongeldig paginanummer niet vreet is terecht; daar heb ik het ook helemaal niet over. Of je get/post gebruikt heeft geen kont te maken met of de gegevens uit invoervelden komen (en wat met input type="hidden"? waar vallen die volgens jou onder?) maar met het feit of je enkel gegevens opvraagt of ook (potentieel) gegevens wijzigt. Idempotence.

[ Voor 35% gewijzigd door RobIII op 21-10-2010 23:35 ]

[fleppuhstein]

ReenL schreef op donderdag 21 oktober 2010 @ 20:38:
@Gamebuster
Als je gewoon cast naar een int en iemand maakt een typo: 12`345 dan krijgt hij geen foutmelding maar dan gaat hij naar entry 12.

Licht eraan wat je er zelf mee doet, Onderstaand misschien een ideetje ?

PHP:

<?php
if(!((int) $_GET['g'] == $_GET['g'])) 
  throw new Exception('error');

?>

[RaZ]

Ik snap je prima hoor.

Het gaat mij er om dat "2a" gewoon niet nummeriek is, als je dan dat wel eist, is de input dus invalid.

Zou het zelfde zijn als wachtwoorden case insensitive te maken voor het gemak van de gebruiker, wie weet staat caps-lock wel aan.

[.oisyn]

Sebazzz schreef op donderdag 21 oktober 2010 @ 20:06:
[...]

Als het gewoon gedocumenteerd is, dan is het prima gedrag. Zo werkt het gewoon in PHP.

Ja, ga de gebruiker van de webapp opzadelen met hoe PHP z'n gedrag documenteert

[Korben]

.oisyn schreef op vrijdag 22 oktober 2010 @ 03:00:
[...]

Ja, ga de gebruiker van de webapp opzadelen met hoe PHP z'n gedrag documenteert

Ik ruik een nieuwe semi-standaard-header: X-Bullshit-Quirks-For. Resulteert in een pop-up in je browser 'pas op, deze website is geschreven in taal X, dus hou rekening met de volgende rare gedragingen: ...'.

OT, het is natuurlijk bullshit om te accepteren dat je nummers in elk arbitrait formaat mag schrijven. Niet in de laatste plaats omdat het zorgt voor problemen met caching en SEO. Overigens is is_numeric() waarschijnlijk niet voldoende, wat als ik bijvoorbeeld een request doe naar 'page.php?id=9437983489938498798379488947'? Dat pikt je database waarschijnlijk niet.

[alex3305]

ReenL schreef op donderdag 21 oktober 2010 @ 20:28:
[...]

Ik zie altijd graag of een array uit de url komt daarom pas ik de waarde in de _GET meestal gewoon aan:

PHP:

if ( !ctype_digit($_GET['a']) ) {
    $_GET['a'] = 0;
}

Maar dat is een kwestie van smaak.

[...]

Ik zou hier een variant op maken:

PHP:

if (is_numeric($_GET['a'])) {
    if (ctype_digit($_GET['a'])) {
        $value = $_GET['a']; return;
    }
}
$value = 0; return;

Waarbij je natuurlijk ook de $value kunt returnen . Op deze manier controleer je namelijk eerst of het getal uberhaupt wel numeriek is, en wanneer dit het geval is, kijk je het een integer is.

[ReenL]

@fleppuhstein:
Dus hetzelfde als wat je met ctype_digit bereikt. het voorbeeld impliceerde ook dat je daarna de variable $a kon gebruiken.

@Korben:
Als het dan toch over veiligheid gaat, X-Bullshit-Quirks-For spoofen naar een andere taal, zodat een hacker de verkeerde zero-day uit de kast haalt

[Hydra]

Om even terug te komen op de vraag van de TS: way back toen ik nog met PHP werkte had ik gewoon een UserInput class met een hoop methoden zoals getAsInt32($key) die ovor mij het casten en valideren van spullen uit de $_GET array afhandelden. Is je code een stuk leesbaarder dan met al die if-blokken.

[Icelus]

Houd er rekening mee dat ctype_digit alleen positieve getallen accepteert en geen spaties e.d.
Mogelijke oplossing:

PHP:

$id = ctype_digit( $_GET['id'] ) ? (int) $_GET['id'] : 0;

[Gamebuster]

Icelus schreef op vrijdag 22 oktober 2010 @ 10:33:
Houd er rekening mee dat ctype_digit alleen positieve getallen accepteert en geen spaties e.d.
Mogelijke oplossing:

PHP:

$id = ctype_digit( $_GET['id'] ) ? (int) $_GET['id'] : 0;

Misschien een trim erbij, als je toch bezig bent?

[.oisyn]

ReenL schreef op donderdag 21 oktober 2010 @ 20:38:
@Gamebuster
Als je gewoon cast naar een int en iemand maakt een typo: 12`345 dan krijgt hij geen foutmelding maar dan gaat hij naar entry 12.

Vooral leuk als je geld overmaakt naar een andere bankrekening (goed, die stop je dan meestal weer niet in een int, maar ook daarvoor zou je kunnen zeggen: we parsen tot we een ongeldig teken tegenkomen, en dan accepteren we de input tot dan toe).

Gefeliciteerd trouwens

[ Voor 12% gewijzigd door .oisyn op 22-10-2010 11:47 ]

[lauwsa]

het is dus eigenlijk het besten om te kijken als het een nummer is en dan kijken als het in de range licht die jij wilt. Dus het handigste lijkt mij om zelf een functie hier voor te schijven die dat doet. En daar bvb is_numeric etc te gebruiken. Licht er aan wat jij zelf wilt.

En natuurlijk niet door gaan als er een "fout" op treed, dan de user het zelf laten verbeter natuurlijk.
Bedankt iedereen!

[NMe]

lauwsa schreef op vrijdag 22 oktober 2010 @ 18:01:
het is dus eigenlijk het besten om te kijken als het een nummer is en dan kijken als het in de range licht die jij wilt. Dus het handigste lijkt mij om zelf een functie hier voor te schijven die dat doet. En daar bvb is_numeric etc te gebruiken. Licht er aan wat jij zelf wilt.

Waarom een functie schrijven als er al een functie in het framework zit die doet wat je wil? En waarom haal je wéér is_numeric aan terwijl in de eerste paar posts van dit topic al gezegd is waarom die niet goed is om te kijken of een getal een int is, inclusief het alternatief dat sindsdien meerdere keren is aangehaald in dit topic?

[ReenL]

lauwsa schreef op vrijdag 22 oktober 2010 @ 18:01:En daar bvb is_numeric

Ctype_digit dus...

@.oisyn
Thanks

[lauwsa]

oops, die bedoelde ik ook

Ik bedoelde met rang als je een getal tussen de 1000 en 1 nodig hebt dat je kijkt als hij daar in licht, dus dat hij niet een getal zoals 9999999999999999999 pakt omdat mysql dit waarschijnlijk niet zo leuk zal vinden

[NMe]

lauwsa schreef op vrijdag 22 oktober 2010 @ 18:54:
oops, die bedoelde ik ook

Ik bedoelde met rang als je een getal tussen de 1000 en 1 nodig hebt dat je kijkt als hij daar in licht, dus dat hij niet een getal zoals 9999999999999999999 pakt omdat mysql dit waarschijnlijk niet zo leuk zal vinden

BIGINT[(M)] [UNSIGNED] [ZEROFILL]

A large integer. The signed range is -9223372036854775808 to 9223372036854775807. The unsigned range is 0 to 18446744073709551615.

Een unsigned bigint zou die waarde nog kunnen bevatten dus MySQL gaat er vast niet van schrikken als je dat intikt. Als je het in een normaal int-veld wil invoeren zonder verdere checks loop je wel kans dat MySQL de waarde als max int gaat opslaan, dus de maximale waarde die in een 32-bits intveld kan staan.

Voor die range-check op integers kun je trouwens best filter_var gebruiken zodat je dus niet je eigen functie nodig hebt. Then again, kijken of het in int is met ctype_digit en vervolgens kijken of die int in een bepaalde range zit kost je 3 checks die allemaal op één regel passen, dus dat lijkt me geen probleem.

[theguyofdoom]

Het idee is meestal dat POST data aanpast, en GET data ophaalt. Google volgt dus gewoon dit model.

Beide zijn eenvoudig aan te passen, alleen bij get gaat het makkelijker. Heb je nooit een zoekactie in de url veranderd, omdat de zoekfunctie niet op de resultatenpagina staat?