[php] 2e foreach werkt niet.

[Verwijderd]

De tweede foreach() geeft een error:
Warning: Invalid argument supplied for foreach()

Dit geeft hij niet als ik de eerste foreach() weg haal.

Heeft dit te maken met de pointer?
Ik dacht dat foreach() deze automatisch terug zet.

PHP:

<?
foreach($_POST as $key => $value)
    $_POST[$key] = trim($value);

foreach($_POST['gedoog'] AS $value)
    echo $value;
?>

<form action="<? echo $_SERVER['REQUEST_URI'];?>" method="post">
<select name="gedoog[]" multiple="multiple">
          <option value="1">1</option>
          <option value="2">2</option>
          <option value="3">3</option>
</select><br />
<input type="submit" name="Submit" value="Submit">
</form>

[Koetjeboe]

In de 1e foreach roep je trim() aan welke waarschijnlijk je array omzet naar een string.

[ Voor 5% gewijzigd door Koetjeboe op 29-10-2009 17:20 ]

[dev10]

Die foutmelding betekend meestal dat je iets anders dan een array probeert te voeren aan foreach.

[Verwijderd]

Thanks!... het probleem zit in die trim(), iemand een idee hoe ik toch kan trimmen zonder zonder hem om te zetten in een string?

[MBV]

Dat is heel simpel. In de tweede for-loop trim je alle waarden, dus i.p.v. echo $value zeg je echo trim($value).

@koetjeboe: waarom zou je dat doen? Welk probleem los je daarmee op? Ik denk dat dat nogal overkill is voor het probleem van de TS

[ Voor 121% gewijzigd door MBV op 29-10-2009 17:28 ]

[Koetjeboe]

Probeer eens zoiets:

code:

foreach($_POST as &$value)
{
    if(is_array($value))
        $value = array_trim($value);
    else
        $value = trim($value);
}

function array_trim($value)
{
    foreach($value as &$val)
    {
        if(is_array($val))
            $val = array_trim($val);
        else
            $val = trim($val);
    }
    return $value;
}

MBV schreef op donderdag 29 oktober 2009 @ 17:27:
Dat is heel simpel. In de tweede for-loop trim je alle waarden, dus i.p.v. echo $value zeg je echo trim($value).

@koetjeboe: waarom zou je dat doen? Welk probleem los je daarmee op? Ik denk dat dat nogal overkill is voor het probleem van de TS

Nou, dit beantwoord zijn 2e vraag. Of dat in dit geval de beste oplossing is, mja, op het huidige niveau is het denk ik wel een oplossing waar hij wat van kan leren (en overkill? Heh, dat valt wel mee toch). En of hij nou de input trimt of bij het op het scherm tonen de output trimt, tja...

[ Voor 50% gewijzigd door Koetjeboe op 29-10-2009 17:33 ]

[BasieP]

ow en voortaan kan tijdens het debuggen print_r (of vardump) je inderdaad een eind op weg helpen.

[ibmos2warp]

Waarom niet gewoon m.b.v. http://php.net/array_walk_recursive ?
Zo dus:

PHP:

<?php // kleurtjes
array_walk_recursive($_POST, create_function('&$a,$b', '$a = trim($a);'));

Misschien wel overkill, misschien niet. Ik denk dat het wel handig is.

[ Voor 65% gewijzigd door ibmos2warp op 29-10-2009 17:40 . Reden: code toegevoegd e.d. ]

[Verwijderd]

MBV schreef op donderdag 29 oktober 2009 @ 17:27:
Dat is heel simpel. In de tweede for-loop trim je alle waarden, dus i.p.v. echo $value zeg je echo trim($value).

@koetjeboe: waarom zou je dat doen? Welk probleem los je daarmee op? Ik denk dat dat nogal overkill is voor het probleem van de TS

Hier heb je gelijk in t.o.v. dit stukje voorbeeld code.
In mijn originele code heb ik meer input. en als ik een trim() zou doen op mijn tweede foreach dan zou ik ze niet allemaal pakken.

[NMe]

ibmos2warp schreef op donderdag 29 oktober 2009 @ 17:30:
Waarom niet gewoon m.b.v. http://php.net/array_walk_recursive ?
Zo dus:

PHP:

<?php // kleurtjes
array_walk_recursive($_POST, create_function('&$a,$b', '$a = trim($a);'));

Misschien wel overkill, misschien niet. Ik denk dat het wel handig is.

Overkill? Nee hoor, da's een stuk sluitender dan met een enkele foreach over $_POST heen gaan.

[MBV]

ibmos2warp schreef op donderdag 29 oktober 2009 @ 17:30:
Waarom niet gewoon m.b.v. http://php.net/array_walk_recursive ?
Zo dus:

PHP:

<?php // kleurtjes
array_walk_recursive($_POST, create_function('&$a,$b', '$a = trim($a);'));

Misschien wel overkill, misschien niet. Ik denk dat het wel handig is.

waarom create_function? Zeker voor een beginner is het een stuk eenvoudiger om gewoon een losse functie ergens neer te zetten.

@NME: als je een heel formulier met dit soort dingen hebt, is het wel iets makkelijker

[ Voor 8% gewijzigd door MBV op 29-10-2009 17:53 ]

[NMe]

MBV schreef op donderdag 29 oktober 2009 @ 17:53:
[...]

waarom create_function? Zeker voor een beginner is het een stuk eenvoudiger om gewoon een losse functie ergens neer te zetten.

Waarom zou een anonieme functie voor een beginner zoveel lastiger te begrijpen zijn? Als het een functie is die je toch alleen maar hier gaat aanroepen dan kun je hem net zo goed anoniem maken.

@NME: als je een heel formulier met dit soort dingen hebt, is het wel iets makkelijker

Ik zeg toch ook juist dat wat ibmos2warp zegt juist makkelijker/sluitender is?

[.oisyn]

Het jammere is alleen dat array_walk_recursive() daadwerkelijk recursief is geïmplementeerd. En aangezien je het op client input toepast, kan de client er dus voor zorgen dat je server een stack overflow ondergaat danwel heel veel resources vreet.

[MBV]

It says so on the tin... Als je een functie 'array_walk_recursive' noemt, wat verwacht je dan dat er gebeurt? Als het anders was zou iedereen het hele PHP-team voor rotte vis uitmaken omdat ze niet doen wat je verwacht Zoals zovaak met PHP

[ Voor 4% gewijzigd door MBV op 29-10-2009 18:35 ]

[NMe]

MBV schreef op donderdag 29 oktober 2009 @ 18:35:
It says so on the tin... Als je een functie 'array_walk_recursive' noemt, wat verwacht je dan dat er gebeurt? Als het anders was zou iedereen het hele PHP-team voor rotte vis uitmaken omdat ze niet doen wat je verwacht Zoals zovaak met PHP

Nou, de correcte vergelijking zou zijn dat iemand het PHP-team erop wijst dat het een domme keuze zou zijn waarna het devteam iedereen die dat beweert voor rotte vis gaat uitmaken in plaats van andersom.

[ibmos2warp]

.oisyn schreef op donderdag 29 oktober 2009 @ 18:08:
Het jammere is alleen dat array_walk_recursive() daadwerkelijk recursief is geïmplementeerd. En aangezien je het op client input toepast, kan de client er dus voor zorgen dat je server een stack overflow ondergaat danwel heel veel resources vreet.

Mjah, dus als je per se recursief zou willen gaan werken, zou je zelf een functie moeten schrijven die depth bijhoud?
Als die functie een hele grote array aangeleverd krijgt geeft op een gegeven moment een fatal error dat ie niet meer geheugen kan alloceren.

[PrisonerOfPain]

ibmos2warp schreef op donderdag 29 oktober 2009 @ 19:26:
[...]

Mjah, dus als je per se recursief zou willen gaan werken, zou je zelf een functie moeten schrijven die depth bijhoud?

Neen, het was handiger geweest van het PHP team als ze dit iteratief hadden geïmplementeerd door hun eigen stack bij te houden.

[Verwijderd]

Ik ben er inmiddels achter dat niet alleen trim() een probleem is.

Zie code:

PHP:

    # controleer op lege velden en trimt de variabelen.
    foreach ($_POST as $key => $value) {
        $_POST[$key] = trim($value);

        # geen invoer is error.
        if (!$_POST[$key]) {
            $txt_error[$key] = "class=\"txt_error\"";
            $input_error[$key] = "class=\"input_error\"";
        }
    }
    # select multiple array.
    foreach ($_POST['pro_mat_maten_list'] as $key => $value) {
        echo "key: " . $key . " value: " . $value . "<br />";
    }

Ik krijg het dus met geen mogelijkheid voor elkaar om de multiple array uit te lezen.
Deze werkt uiteraard wel als ik de foreach() van mijn multiple array boven mijn invoer controle zet.

Echter is het noodzakelijk om de huidige volgorde aan te houden.

[NMe]

Je doet nog steeds éérst een normale trim over alle elementen in de array. Daarmee flatten je je hele array en kun je de foreach op regel 12 ook niet meer doen. Dat is toch logisch? Je wil alleen trimmen als je huidige element geen array is. Als het wél een array is dan kun je ervoor kiezen dat dan maar niet te trimmen, of je moet nog een loopje/recursie gebruiken.

Verder: die hele if op regels 6-9 is onhandig. Als ik 0 invul als waarde slingert die if in werking.

[Confusion]

.oisyn schreef op donderdag 29 oktober 2009 @ 18:08:
Het jammere is alleen dat array_walk_recursive() daadwerkelijk recursief is geïmplementeerd. En aangezien je het op client input toepast, kan de client er dus voor zorgen dat je server een stack overflow ondergaat danwel heel veel resources vreet.

Alleen lijkt me dat hier niet zo belangrijk, aangezien $_POST alleen strings en arrays van strings kan bevatten.

[Voutloos]

Nope. Voer een dergelijk script input als ?variabele[][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][etc....]=a en je krijgt toch echt de mooiste foutmeldingen.

[Confusion]

Voutloos schreef op donderdag 29 oktober 2009 @ 21:53:
Nope. Voer een dergelijk script input als ?variabele[][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][etc....]=a en je krijgt toch echt de mooiste foutmeldingen.

Oh sorry, ik ging er weer eens naief vanuit dat PHP ergens niet compleet gestoord mee omging.

[NMe]

Stiekem is dat niet gestoord, dat wil je gewoon kunnen doen. Hoe wil je anders een array van arrays doorgeven? Heb ik bijvoorbeeld gehad bij het doorgeven van een arbitrair aantal contactadressen; elk adres was een array van waarden uit invoervelden, en om er daar meer van tegelijk door te kunnen geven moet daar weer een array omheen.

[MBV]

Het leukste is het om een tabel met gegevens als gebruikersinvoer te hebben. Elk invoerveld kan je dan de naam tabel[rij][kolom] geven, en die kan je dan met $_POST['tabel'][42]['prijs'] uitlezen En dan een javascriptje voor nieuwe regels.

[.oisyn]

MBV schreef op donderdag 29 oktober 2009 @ 18:35:
Als je een functie 'array_walk_recursive' noemt, wat verwacht je dan dat er gebeurt?

Dan verwacht ik dat ie over de array loopt, inclusief alle elementen die zelf weer arrays zijn. Niet dat dat op algoritmisch niveau ook per se op een recursieve manier geimplementeerd is. Sterker nog, liever zou het op zo'n manier geimplementeerd zijn dat je het niet makkelijk kunt slopen met user input. En in de regel betekent dat iteratief.

Als het anders was zou iedereen het hele PHP-team voor rotte vis uitmaken omdat ze niet doen wat je verwacht

Dat is dus onzin. De naam gaat over het observeerbare gedrag van de functie. Niet in hoe die dat klaarspeelt.

[ Voor 11% gewijzigd door .oisyn op 29-10-2009 23:24 ]

[MBV]

dan krijg je lolbroeken die er echo-statements in gaan zetten, dus de volgorde moet perfect voorspelbaar blijven. En andere lolbroeken die de array-pointer gaan verplaatsen (next() enzo). Je moet dus heel erg zeker zijn dat observeerbaar hetzelfde is als de bedoeling, en bij PHP zitten daar wel vaker kleine verschillen tussen.

[NMe]

De array_walk functies gebruiken hun eigen array pointer bij mijn weten, dus je kan verplaatsen wat je wil. Bovendien kun je dat natuurlijk prima speccen door te zeggen dat het verplaatsen van de array pointer op eigen risico is en dat de volgorde waarop door het array gelopen wordt op een bepaalde manier gedaan wordt kun je ook gewoon documenteren.

[.oisyn]

MBV schreef op vrijdag 30 oktober 2009 @ 00:15:
dan krijg je lolbroeken die er echo-statements in gaan zetten, dus de volgorde moet perfect voorspelbaar blijven.

Wat nergens op slaat, want array_walk_recursive() definieert geen volgorde. Daarnaast is het dan alsnog wel iteratief te implementeren met exact diezelfde volgorde.

[ Voor 12% gewijzigd door .oisyn op 30-10-2009 00:37 ]

[Confusion]

NMe schreef op donderdag 29 oktober 2009 @ 22:11:
Stiekem is dat niet gestoord, dat wil je gewoon kunnen doen. Hoe wil je anders een array van arrays doorgeven?

Geserialiseerd, zodat je moet deserialiseren en je je donders goed realiseert dat je de gebruikersinput hier extra moet controleren. Geen magische speciale behandeling van bepaalde karakters, waardoor de aannames die je over het onderliggende protocol kunt doen vernaggeld worden. POST variabelen zijn volgens de spec strings of hooguit een array van strings. PHP moet dat zo laten. Als ik wil dat [] een speciale betekenis heeft, dan is het aan mij om dat te parsen, niet aan PHP om, in afwijking van iedere andere taal, met een toverstokje te zwaaien.

[NMe]

Dus ik mijn mijn zaakje in Javascript gaan serializen voordat ik het aan PHP door kan geven als in inderdaad een matrix van waarden wil kunnen editen? Dan vind ik de huidige methode toch beter hoor. Lekker boeiend dat ik dan eventueel wat extra controle moet doen als ik daar doorheen wil array_walk'en.

Voor het overgrote deel van de developers zal het op deze manier doorgeven van arrays niet alleen het verwachte gedrag maar zelfs het gewenste gedrag zijn. PHP heeft veel ontwerpkeuzes niet goed overwogen en dit is er vast één van, maar dat wil niet zeggen dat het resultaat niet bijzonder praktisch is.

[.oisyn]

Confusion schreef op vrijdag 30 oktober 2009 @ 09:43:
[...]

Geserialiseerd, zodat je moet deserialiseren en je je donders goed realiseert dat je de gebruikersinput hier extra moet controleren. Geen magische speciale behandeling van bepaalde karakters, waardoor de aannames die je over het onderliggende protocol kunt doen vernaggeld worden. POST variabelen zijn volgens de spec strings of hooguit een array van strings. PHP moet dat zo laten. Als ik wil dat [] een speciale betekenis heeft, dan is het aan mij om dat te parsen, niet aan PHP om, in afwijking van iedere andere taal, met een toverstokje te zwaaien.

Je overdrijft enorm, de oplossing die je voorstelt is allesbehalve handig, en is bovendien niet eens een oplossing. De array syntax bestaat voornamelijk voor <select> elementen waarvoor je meerdere keuzes kunt aangeven. De browser stuurt dan een naam=value pair voor elke option die je geselecteerd hebt, met de narigheid dat de naam van de <select> af komt en dus voor iedere optie hetzelfde is. Door daar "aap[]" van te maken wordt dat automatisch gedeserialized (ja idd, gedeserialized, want de POST variabelen zijn óók een vorm van serialization) naar een array die "aap" heet. Dat je met dezelfde syntax een array-in-array-in-array-etc kunt definieren is op zich helemaal niet erg. Wat wel erg is is dat mensen niet nadenken en dat soort data direct door recursieve functies heenknallen, wat de deur open zet voor DoS attacks.

Jouw suggestie lost ook helemaal niets op, omdat als mensen zelf hun data moeten gaan deserializen ze dat óók recursief gaan doen. Met de narigheid dat het dan nog eens veel erger is omdat een PHP call veel meer stack space kost dan een C call in de onderliggende library.

NMe schreef op vrijdag 30 oktober 2009 @ 10:12:
PHP heeft veel ontwerpkeuzes niet goed overwogen en dit is er vast één van

Als Professional PHP Basher™ wil ik even zeggen dat ik het hier dus compleet niet mee eens ben
.edit: oh wacht ik interpreteer je reactie verkeerd . Ik dacht dat je zei dat PHP veel foute ontwerpkeuzes had, en dat dit er niet een van is. Dat ze het niet goed overwogen hebben wil ik best geloven

[ Voor 29% gewijzigd door .oisyn op 30-10-2009 11:24 ]

[MBV]

with NMe

En dan heb je het geserialiseerd, op de manier zoals dan alle PHP-sites dat doen. $Evil_user genereert met zijn eigen PHP-site een array die zo diep is dat je alsnog een error krijgt. Dan zit je op dezelfde situatie als ?value[][][][][][][][][] met een klein extra drempeltje.

Trouwens, dan krijg je een stack overflow error, of een random foutmelding die nergens op slaat. $Evil_user ziet een witte pagina (goed geconfigureerd) of een lelijke foutmelding (apt-get install apache2-mod-php5 en niks meer doen, what can possibly go wrong?). En dan?

[Confusion]

.oisyn schreef op vrijdag 30 oktober 2009 @ 10:40:
De array syntax bestaat voornamelijk voor <select> elementen waarvoor je meerdere keuzes kunt aangeven. De browser stuurt dan een naam=value pair voor elke option die je geselecteerd hebt, met de narigheid dat de naam van de <select> af komt en dus voor iedere optie hetzelfde is.

Natuurlijk is de naam voor iedere optie hetzelfde: het zijn immers meerdere values voor dezelfde selectbox. Je krijgt selectBoxName=value1,value2,value3, zoals je arrays normaal in GET of POST parameters door kunt geven. Ik zie de meerwaarde niet.

Jouw suggestie lost ook helemaal niets op, omdat als mensen zelf hun data moeten gaan deserializen ze dat óók recursief gaan doen.

Deserialisatie gaat in 1 keer: je gaat ook niet recursief serialiseren. Maar die deserialisatie moet wel expliciet uitgevoerd worden, wat een enorm STOP bord is voor: controleer of deze complexe datastructuur veilig is, voor je er recursief doorheen gaat wandelen. Dat probleem staat los van de normale inputvalidatie en is gemakkelijk over het hoofd te zien.

MBV schreef op vrijdag 30 oktober 2009 @ 10:49:
En dan heb je het geserialiseerd, op de manier zoals dan alle PHP-sites dat doen. $Evil_user genereert met zijn eigen PHP-site een array die zo diep is dat je alsnog een error krijgt. Dan zit je op dezelfde situatie als ?value[][][][][][][][][] met een klein extra drempeltje.

Kleine extra drempeltjes zijn precies de dingen die nodig zijn om Joe random programmer zich te laten realiseren dat ze extra op moeten letten.

Trouwens, dan krijg je een stack overflow error, of een random foutmelding die nergens op slaat. $Evil_user ziet een witte pagina (goed geconfigureerd) of een lelijke foutmelding (apt-get install apache2-mod-php5 en niks meer doen, what can possibly go wrong?). En dan?

Zoals .oisyn zegt: DoS.

[NMe]

Confusion schreef op vrijdag 30 oktober 2009 @ 11:01:
[...]

Natuurlijk is de naam voor iedere optie hetzelfde: het zijn immers meerdere values voor dezelfde selectbox. Je krijgt selectBoxName=value1,value2,value3, zoals je arrays normaal in GET of POST parameters door kunt geven. Ik zie de meerwaarde niet.

Dat doet een selectbox echter niet zo, die geeft als je over GET stuurt ?selectBoxName=value1&selectBoxName=value2&selectBoxName=value3 en dát is weer niet zo makkelijk uit te lezen.

[.oisyn]

Confusion schreef op vrijdag 30 oktober 2009 @ 11:01:
[...]

Natuurlijk is de naam voor iedere optie hetzelfde: het zijn immers meerdere values voor dezelfde selectbox. Je krijgt selectBoxName=value1,value2,value3

Nee, je krijgt
selectBoxName=value1
selectBoxName=value2
selectBoxName=value3
Maar dat is het punt niet.

Deserialisatie gaat in 1 keer: je gaat ook niet recursief serialiseren. Maar die deserialisatie moet wel expliciet uitgevoerd worden, wat een enorm STOP bord is voor: controleer of deze complexe datastructuur veilig is, voor je er recursief doorheen gaat wandelen.

Onzin. Het probleem zit 'm ook helemaal niet in de deserialization, die werkt prima. Het probleem zit 'm in het feit dat de gebruiker de uiteindelijke gedeserializede datastructuur, waar mogelijk diep geneste arrays in zitten, door recursieve functies heen gaat halen voordat die input überhaupt gevalideerd is. En deserializatie en validatie zijn dingen die los van elkaar staan (omdat de serializer niets weet over de semantiek van je data). Het punt is, welke vorm van serialization je ook kiest (PHP GET/POST, JSON, XML), het probleem blijft. Als je recursief over een structuur wil lopen die afkomt van user-input dan moet je een maxdepth conditie hebben.

Kleine extra drempeltjes zijn precies de dingen die nodig zijn om Joe random programmer zich te laten realiseren dat ze extra op moeten letten.

Met andere woorden, het moet voor iedereen lastiger worden gemaakt om ermee te werken, terwijl Joe Programmer alsnog niet nadenkt over z'n data en mogelijke side effects als stack overflows. Nee, erg handig . Ik hoop dat ik nooit met jouw software hoef te werken, waarmee ik meer code moet tikken omdat ik zogenaamd ergens aan herinnerd moet worden, terwijl ik capabel genoeg ben om geheel uit mezelf rekening te houden met corner cases, en de mensen die er wél aan herinnerd moeten worden er alsnog niets mee doen.

[ Voor 15% gewijzigd door .oisyn op 30-10-2009 11:17 ]

[Confusion]

.oisyn schreef op vrijdag 30 oktober 2009 @ 11:07:
Met andere woorden, het moet voor iedereen lastiger worden gemaakt om ermee te werken, terwijl Joe Programmer alsnog niet nadenkt over z'n data en mogelijke side effects als stack overflows. Nee, erg handig . Ik hoop dat ik nooit met jouw software hoef te werken, waarmee ik meer code moet tikken omdat ik zogenaamd ergens aan herinnerd moet worden,

Iets niet magisch maken is niet hetzelfde als iemand meer code laten tikken om hem ergens aan te herinneren. Ik pleit tegen magie in de meeste fundamentele http library van PHP, wat er voor zorgt dat ik niet met de echte POST parameters kan interacteren. Ik pleit niet voor enig extra obstakel. Java, C of Python HTTP libraries halen dit soort fratsen ook niet uit.

Als je zelf je parameters moet interpreteren, dan weet je hopelijk wat je aan het doen bent. Als dat automatisch gebeurt, dan trek je ook mensen die zich niet meer realiseren wat er in die stap gebeurt. Dat levert uiteindelijk weer problemen voor jou op, aangezien die software ooit bij jou terecht zou kunnen komen. Geef mij de parameter maar: niet de array die het eventueel in een uitzonderingsgeval moet voorstellen.

[MBV]

DoS mag je schrappen:

code:

http://example.com/test.php?test[x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x]=value

1446x [x], en mijn 500mhz servertje geeft geen krimp. Zodra ik hem nog een keer verdubbel geeft hij een 'URI too large' foutmelding.

[Verwijderd]

En weer even helemaal terug naar de basis waar deze topic is begonnen

Ik heb het trim probleem reeds verholpen op de volgende manier:

PHP:

    function safe($value, $key) {
        $value = trim($value);
        $value = stripslashes($value);
    }

    foreach ($_POST as $key => $value) {

         array_walk_recursive($_POST, 'safe');

        if (!$_POST[$key]) {
            $txt_error[$key] = "class=\"txt_error\"";
            $input_error[$key] = "class=\"input_error\"";
        }
    }

Dit werkt tot dat er een input tussen zit met een '
Error:
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'S', '', ' at line 4

Het heeft te maken met stripslashes() want als ik die weg haal werkt hij prima.

Waarom kan ik hier geen stripslashes() gebruiken?

[Voutloos]

Je vertrouwt nu op magic quotes, en je weet niet wat sql injection is.

Todo:
1. Leesvoer beide termen
2. Queries escapen
3. Magic quotes voor eens en altijd uitzetten en iedereen die het aan wil zetten of het verdedigt hard op zijn neus slaan.

[ Voor 23% gewijzigd door Voutloos op 30-10-2009 12:36 ]

[NMe]

Je hebt magic quotes aan staan blijkbaar, doe eens uitzetten.

Die error heeft verder te maken met SQL injection. Succes met Googlen.

[pedorus]

MBV schreef op vrijdag 30 oktober 2009 @ 12:17:
DoS mag je schrappen:

code:

http://example.com/test.php?test[x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x][x]=value

1446x [x], en mijn 500mhz servertje geeft geen krimp. Zodra ik hem nog een keer verdubbel geeft hij een 'URI too large' foutmelding.

Dit ligt aan je php-versie denk ik. Na 65x [x] gebeurd er bij mij ook niks meer ter beveiliging, en wordt de variabele genegeerd.

---

@TS: zoek anders gelijk ook even op "pdo prepared statements" en "cross site scripting".

[.oisyn]

MBV schreef op vrijdag 30 oktober 2009 @ 12:17:
DoS mag je schrappen:
1446x [x], en mijn 500mhz servertje geeft geen krimp. Zodra ik hem nog een keer verdubbel geeft hij een 'URI too large' foutmelding.

Het gaat ook niet om de deserializer van PHP, maar het feit dat je $_GET vervolgens door array_walk_recursive heenjast . Overigens kun je de x uit elke [x] ook wel weghalen, scheelt je weer bytes en dus kun je de array langer maken. Of je doet een POST, dan kan ie nog langer

.edit: GoT heeft het trouwens knap lastig met die post

[ Voor 84% gewijzigd door .oisyn op 30-10-2009 13:07 ]

[MBV]

PHP 4.4.4, etch. Note-to-self: 'k moet toch die lenny-bak eens in gebruik nemen

Ik heb dus deze code uitgevoerd:

PHP:

$i = 0;
function test_print($item, $key)
{
        global $i;
        echo "$key holds $item\n";
        $i++;
}

array_walk_recursive($_GET, 'test_print');

echo "<br/><br/> i = $i";

function array_walk_recursive($val, $methodName) {
    foreach($val as $key => $value) {
        $methodName($value, $key);
        if (is_array($value))
            array_walk_recursive($value, $methodName);
    }
}

En aan de uitvoer te zien werd het echt 1700x uitgevoerd.

[.oisyn]

Klopt niet, test_print() zou maar 1x aangeroepen moeten worden.
.edit: oh wacht jouw eigen implementatie van array_walk_recursive() is anders

Maar het punt is niet dat het crasht. Het punt is dat je script gigantisch veel resources vreet. Als je vervolgens die query distributed gaat opvragen ligt je server op z'n gat.

[ Voor 77% gewijzigd door .oisyn op 30-10-2009 13:16 ]

[NMe]

pedorus schreef op vrijdag 30 oktober 2009 @ 12:57:
[...]

@TS: zoek anders gelijk ook even op "pdo prepared statements" en "cross site scripting".

Cross site scripting heeft niks met SQL-injectie te maken en er zijn meer manieren om databases veilig te benaderen dan met PDO.

[pedorus]

NMe schreef op vrijdag 30 oktober 2009 @ 13:14:
[...]

Cross site scripting heeft niks met SQL-injectie te maken en er zijn meer manieren om databases veilig te benaderen dan met PDO.

Klopt, maar REQUEST_URI terugecho'en is niet veilig.

[MBV]

NMe schreef op vrijdag 30 oktober 2009 @ 13:14:
[...]

Cross site scripting heeft niks met SQL-injectie te maken en er zijn meer manieren om databases veilig te benaderen dan met PDO.

Prepared statements zijn een heel doeltreffende manier om je veiligheid te waarborgen, en XSS ligt in het verlengde van SQL Injection.