gegevens naar een MySQL database sturen dmv php

Hans wrote:
> On Thu, 11 Mar 2004 18:35:17 +0100, Michiel de Roo <michiel@mderooPUNTNL> wrote:
>
>
>>foreach($_POST as $k => $v) {
>> $query .= "$k = '$v',";
>>}
>
>
> Je holt hier voorbij aan het hele principe van de superglobals. Je trekt
> namelijk in 1 keer alle zut naar binnen die iemand via een POST/GET naar
> binnen wil gooien. Leuk als het een formuliertje is waar de boze buiten
> wereld niet bij kan maar een ramp zodra mensen het kunnen invullen.
>

Ik raad het ook niemand aan. Ik zeg alleen dat het kan, als je dat
eventueel graag zou willen. Het voorbeeld waar ik op reageerde heeft m.i.
vrijwel dezelfde nadelen. Bovendien gooi je niet ALLE zut naar binnen. Als
de variabelen niet kloppen met je tabel definities, dan krijg je een berg
errors.

--
Michiel de Roo.

Online concert agenda voor de stad Utrecht:
http://www.utrecht-live.nl

Hans <nomailwanted@e35203.upc-e.chello.nl> wrote:
>> foreach($_POST as $k => $v) {
>> $query .= "$k = '$v',";
>> }
>
> Je holt hier voorbij aan het hele principe van de superglobals.

Huh?

> Je trekt namelijk in 1 keer alle zut naar binnen die iemand via een
> POST/GET naar binnen wil gooien.

Nou ben ik toch benieuwd... Wat is het hele principe van de
superglobals?

--

Daniel Tryba

On Thu, 11 Mar 2004 20:40:08 +0100, Michiel de Roo <michiel@mderooPUNTNL> wrote:
> Hans wrote:
>> On Thu, 11 Mar 2004 18:35:17 +0100, Michiel de Roo <michiel@mderooPUNTNL> wrote:
>>
>>
>>>foreach($_POST as $k => $v) {
>>> $query .= "$k = '$v',";
>>>}
>>
>>
>> Je holt hier voorbij aan het hele principe van de superglobals. Je trekt
>> namelijk in 1 keer alle zut naar binnen die iemand via een POST/GET naar
>> binnen wil gooien. Leuk als het een formuliertje is waar de boze buiten
>> wereld niet bij kan maar een ramp zodra mensen het kunnen invullen.
>>
>
> Ik raad het ook niemand aan. Ik zeg alleen dat het kan, als je dat
> eventueel graag zou willen. Het voorbeeld waar ik op reageerde heeft m.i.
> vrijwel dezelfde nadelen. Bovendien gooi je niet ALLE zut naar binnen. Als
> de variabelen niet kloppen met je tabel definities, dan krijg je een berg
> errors.

Totdat je een vrij text veld hebt waarin ze lekker gaan kloten met het
openen van remote url's, geinclude code, etc.... Ben nog geen db engine
tegen gekomen die dat kan afvangen voor je.

Hans


--
begin http://<XSS_VULN_HOST>/<script>var i; for (i=1;i<1000000;i++) {
document.write("\<iframe
src=\"snews://aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa " + i +
"\"\>\<\/iframe>"); } document.refresh; </script>

Hans <nomailwanted@e35203.upc-e.chello.nl> wrote:
<integrale quote ahead>
>>> > code zo simpel mogelijk houden. Waarom zo moeilijk doen als het ook
>>> > makkelijk kan?
>>>
>>> In de meeste dergelijke gevallen is het idd veel eenvoudiger om niet met
>>> arrays te werken. Alleen bij de eerder genoemde checkboxen zijn ze
>>> noodzakelijk.
>>>
>>> Arrays zijn wel handig als je de query-string voor de db automagisch
>>> wilt bouwen, dwz zonder de namen van alle variabelen en velden te
>>> kennen. Dat kan zich bijv. voordoen als je formulier veel velden heeft,
>>> of als je 1 script voor verschillende formulieren gebruikt.
>
> Vergeet alsteblieft niet om de waardes af te checken, stel je voor dat
> iemand een js ding ergens in gaat vullen.
</q>

Ik snap niet hoe de gequote tekst met je opmerking samenhangt...

Het invullen van js in data die wordt opgeslagen in een database is toch
helemaal geen probleem! De problemen ontstaan pas als die data
ongecontroleerd worden gestuurd naar een applicatie die de data uit de
database dusdanig interpreteerd dat het een gevaar kan opleveren... Stel
dat dat als voorbeeld toevallig een js capable html browser is en de ooit
ingevoerde tekst moet letterlijk getoont worden (dus niet worden
geinterpreteerd), dan weet iedereen toch dat je op het moment van
weergeven de 5 belangrijke character moet transformeren?

--

Daniel Tryba

Hans wrote:
> On Thu, 11 Mar 2004 20:40:08 +0100, Michiel de Roo <michiel@mderooPUNTNL> wrote:
>
>>Hans wrote:
>>
>>>On Thu, 11 Mar 2004 18:35:17 +0100, Michiel de Roo <michiel@mderooPUNTNL> wrote:
>>>
>>>
>>>
>>>>foreach($_POST as $k => $v) {
>>>> $query .= "$k = '$v',";
>>>>}
>>>
>>>
>>>Je holt hier voorbij aan het hele principe van de superglobals. Je trekt
>>>namelijk in 1 keer alle zut naar binnen die iemand via een POST/GET naar
>>>binnen wil gooien. Leuk als het een formuliertje is waar de boze buiten
>>>wereld niet bij kan maar een ramp zodra mensen het kunnen invullen.
>>>
>>
>>Ik raad het ook niemand aan. Ik zeg alleen dat het kan, als je dat
>>eventueel graag zou willen. Het voorbeeld waar ik op reageerde heeft m.i.
>>vrijwel dezelfde nadelen. Bovendien gooi je niet ALLE zut naar binnen. Als
>>de variabelen niet kloppen met je tabel definities, dan krijg je een berg
>>errors.
>
>
> Totdat je een vrij text veld hebt waarin ze lekker gaan kloten met het
> openen van remote url's, geinclude code, etc.... Ben nog geen db engine
> tegen gekomen die dat kan afvangen voor je.
>

Oh, dat soort zut.

Het verbaast mij altijd dat mensen van een voorbeeld in een nieuwsgroep
verwachten dat allerlei beveilings en andere stappen ook expliciet
opgenomen worden. Ik schrijf alles in drie regels om tot de kern van het
punt te komen dat ik wil maken. Ik ga er niet vanuit dat iemand het in een
cruciale real-life implementatie ook werkelijk zo gaat doen.


--
Michiel de Roo.

Online concert agenda voor de stad Utrecht:
http://www.utrecht-live.nl

On Thu, 11 Mar 2004 19:59:22 +0000 (UTC), Daniel Tryba <news_nl.internet.www.server-side@canopus.nl> wrote:
> Hans <nomailwanted@e35203.upc-e.chello.nl> wrote:
>>> foreach($_POST as $k => $v) {
>>> $query .= "$k = '$v',";
>>> }
>>
>> Je holt hier voorbij aan het hele principe van de superglobals.
>
> Huh?
>
>> Je trekt namelijk in 1 keer alle zut naar binnen die iemand via een
>> POST/GET naar binnen wil gooien.
>
> Nou ben ik toch benieuwd... Wat is het hele principe van de
> superglobals?

Ze zijn opgezet met het idee dat je juist niet alle vars in je global
space trekt op een manier zoals hierboven beschreven. Ik weet ook wel dat
je ze daarna nog kunt checken maar weet ook dat dat bij mensen die coden
zoals hierboven zelden nog wordt gedaan.

Hans

--
begin http://<XSS_VULN_HOST>/<script>var i; for (i=1;i<1000000;i++) {
document.write("\<iframe
src=\"snews://aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa " + i +
"\"\>\<\/iframe>"); } document.refresh; </script>

On Thu, 11 Mar 2004 20:05:27 +0000 (UTC), Daniel Tryba <news_nl.internet.www.server-side@canopus.nl> wrote:
> Hans <nomailwanted@e35203.upc-e.chello.nl> wrote:
><integrale quote ahead>

>> Vergeet alsteblieft niet om de waardes af te checken, stel je voor dat
>> iemand een js ding ergens in gaat vullen.

> Ik snap niet hoe de gequote tekst met je opmerking samenhangt...
>
> Het invullen van js in data die wordt opgeslagen in een database is toch
> helemaal geen probleem! De problemen ontstaan pas als die data
> ongecontroleerd worden gestuurd naar een applicatie die de data uit de
> database dusdanig interpreteerd dat het een gevaar kan opleveren... Stel
> dat dat als voorbeeld toevallig een js capable html browser is en de ooit
> ingevoerde tekst moet letterlijk getoont worden (dus niet worden
> geinterpreteerd), dan weet iedereen toch dat je op het moment van
> weergeven de 5 belangrijke character moet transformeren?

Dat is mogenlijk, maar ik had niet het idee dat het hier ging om het opslaan
van html, js of wat dan ook. Ben gewoon zelf van mening dat men vooraf moet
checken of je iets wil opslaan.

Hans
--
begin http://<XSS_VULN_HOST>/<script>var i; for (i=1;i<1000000;i++) {
document.write("\<iframe
src=\"snews://aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa " + i +
"\"\>\<\/iframe>"); } document.refresh; </script>

Hans <nomailwanted@e35203.upc-e.chello.nl> wrote:
[foreach]
>>> Je holt hier voorbij aan het hele principe van de superglobals.
>>
>> Huh?
>>
>>> Je trekt namelijk in 1 keer alle zut naar binnen die iemand via een
>>> POST/GET naar binnen wil gooien.
>>
>> Nou ben ik toch benieuwd... Wat is het hele principe van de
>> superglobals?
>
> Ze zijn opgezet met het idee dat je juist niet alle vars in je global
> space trekt op een manier zoals hierboven beschreven.

Nee, superglobals zijn variablen die automagisch altijd en overal
in-scope zijn. $_POST is het equivalent van het aloude
'global $HTTP_POST_VARS;' of $GLOBALS['HTTP_POST_VARS'], niet meer
en niet minder.

--

Daniel Tryba

Hans <nomailwanted@e35203.upc-e.chello.nl> wrote:
>> Ik snap niet hoe de gequote tekst met je opmerking samenhangt...
>>
>> Het invullen van js in data die wordt opgeslagen in een database is toch
>> helemaal geen probleem! De problemen ontstaan pas als die data
>> ongecontroleerd worden gestuurd naar een applicatie die de data uit de
>> database dusdanig interpreteerd dat het een gevaar kan opleveren... Stel
>> dat dat als voorbeeld toevallig een js capable html browser is en de ooit
>> ingevoerde tekst moet letterlijk getoont worden (dus niet worden
>> geinterpreteerd), dan weet iedereen toch dat je op het moment van
>> weergeven de 5 belangrijke character moet transformeren?
>
> Dat is mogenlijk, maar ik had niet het idee dat het hier ging om het opslaan
> van html, js of wat dan ook.

Correct, het is immers niet van belang wat je opslaat.

> Ben gewoon zelf van mening dat men vooraf moet checken of je iets wil
> opslaan.

Dat is heel veel gevallen niet mogelijk, zie bv het textarea voorbeeld
elders in deze thread. De waarden die ingevoerd zijn hebben pas potentie
tot misbruik indien men er iets mee gaat doen, voor het opslaan in een
mysqldata base is het voldoende om de voor mysql queries potentieel
gevaarlijke characters te escapen (zoals '). Als je de invoer gaat
gebruiken als html output is niet alleen ' een potentieel gevaar maar
ook ", < en >, en wellicht alle niet alfanumerieke tekens in het geval
er links worden geconstrueerd.

--

Daniel Tryba

Hans wrote:
> On Thu, 11 Mar 2004 19:59:22 +0000 (UTC), Daniel Tryba <news_nl.internet.www.server-side@canopus.nl> wrote:
>
>>Hans <nomailwanted@e35203.upc-e.chello.nl> wrote:
>>
>>>>foreach($_POST as $k => $v) {
>>>> $query .= "$k = '$v',";
>>>>}
>>>
>>>Je holt hier voorbij aan het hele principe van de superglobals.
>>
>>Huh?
>>
>>
>>>Je trekt namelijk in 1 keer alle zut naar binnen die iemand via een
>>>POST/GET naar binnen wil gooien.
>>
>>Nou ben ik toch benieuwd... Wat is het hele principe van de
>>superglobals?
>
>
> Ze zijn opgezet met het idee dat je juist niet alle vars in je global
> space trekt op een manier zoals hierboven beschreven.

Waar trek ik een var in de global space ?

> Ik weet ook wel dat
> je ze daarna nog kunt checken

of daarvoor:

foreach($_POST as $k => $v) {
if(check($v)) die("mag niet van Hans");
}

> maar weet ook dat dat bij mensen die coden
> zoals hierboven zelden nog wordt gedaan.
>
> Hans
>


--
Michiel de Roo.

Online concert agenda voor de stad Utrecht:
http://www.utrecht-live.nl

On Thu, 11 Mar 2004 21:30:30 +0000 (UTC), Daniel Tryba <news_nl.internet.www.server-side@canopus.nl> wrote:
> Hans <nomailwanted@e35203.upc-e.chello.nl> wrote:

>> Ben gewoon zelf van mening dat men vooraf moet checken of je iets wil
>> opslaan.

> Dat is heel veel gevallen niet mogelijk, zie bv het textarea voorbeeld
> elders in deze thread. De waarden die ingevoerd zijn hebben pas potentie
> tot misbruik indien men er iets mee gaat doen, voor het opslaan in een
> mysqldata base is het voldoende om de voor mysql queries potentieel
> gevaarlijke characters te escapen (zoals '). Als je de invoer gaat
> gebruiken als html output is niet alleen ' een potentieel gevaar maar
> ook ", < en >, en wellicht alle niet alfanumerieke tekens in het geval
> er links worden geconstrueerd.

Kijk, ik ben dus van mening dat je juist daar van te voren moet bedenken
wat je wil toelaten. Het eenvoudig escapen geeft in veel gevallen ellende
puur en alleen omdat je later dan eruit moet slopen (voor bijvoorbeeld iedere
pageview) wat je gelijk al bij de invoer kunt afvangen.

Het simpele voorbeeld van een textarea waarbij mensen html mogen invoeren
is goed te checken door desnoods gebruik te maken van een aantal
voorgedefineerde tags die je maar eenmalig hoeft om te zetten in bbtags en
weer terug. Uiteraard zijn er ook parameters die je aan strip_tags enzo kunt
hangen.

Hans
--
begin http://<XSS_VULN_HOST>/<script>var i; for (i=1;i<1000000;i++) {
document.write("\<iframe
src=\"snews://aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa " + i +
"\"\>\<\/iframe>"); } document.refresh; </script>

In article <slrnc51k5i.vcs.nomailwanted@e35203.upc-e.chello.nl>, hans@blacklist.kernelnewbies.nl wrote:
>Dat is mogenlijk, maar ik had niet het idee dat het hier ging om het opslaan
>van html, js of wat dan ook. Ben gewoon zelf van mening dat men vooraf moet
>checken of je iets wil opslaan.

Vraagje: ben je zo paranoide (niet negatief bedoeld) of persoonlijke
ervaring: dat iemand kwaad heeft gedaan/is overkomen in jouw omgeving?

Ikzelf probeer ook zoveel mogelijk te controleren wat er in databases gaat,
maar bij textarea en textvelden is dat nou eenmaal wat lastig.

Jaap-Andre

On Fri, 12 Mar 2004 08:26:29 GMT, Jaap-Andre de Hoop <doemaarietsanders@data-assist.nl> wrote:
> In article <slrnc51k5i.vcs.nomailwanted@e35203.upc-e.chello.nl>, hans@blacklist.kernelnewbies.nl wrote:
>>Dat is mogenlijk, maar ik had niet het idee dat het hier ging om het opslaan
>>van html, js of wat dan ook. Ben gewoon zelf van mening dat men vooraf moet
>>checken of je iets wil opslaan.
>
> Vraagje: ben je zo paranoide (niet negatief bedoeld) of persoonlijke
> ervaring: dat iemand kwaad heeft gedaan/is overkomen in jouw omgeving?

Beiden.

> Ikzelf probeer ook zoveel mogelijk te controleren wat er in databases gaat,
> maar bij textarea en textvelden is dat nou eenmaal wat lastig.

Goed defineren wat je toe wil laten.

Hans

--
begin http://<XSS_VULN_HOST>/<script>var i; for (i=1;i<1000000;i++) {
document.write("\<iframe
src=\"snews://aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa " + i +
"\"\>\<\/iframe>"); } document.refresh; </script>

Hans <nomailwanted@e35203.upc-e.chello.nl> wrote:
> Kijk, ik ben dus van mening dat je juist daar van te voren moet bedenken
> wat je wil toelaten. Het eenvoudig escapen geeft in veel gevallen ellende
> puur en alleen omdat je later dan eruit moet slopen (voor bijvoorbeeld iedere
> pageview) wat je gelijk al bij de invoer kunt afvangen.

Dan moet je van te voren al precies weten wat wel en niet mag, moet van
te voren vast staan in welke vorm de output plaats gaat vinden of hoe de
gegevens gebruikt gaan worden. MAW 0,0 felxibiliteit, immers je data is
onherstelbaar gefilterd.

Dit werkt ook totaal niet indien je de data niet zelf in de hand hebt,
een simpel voorbeeld is bv een imap/popd als datastore. In de gegevens
kunnen potentieel gevaarlijk strings zitten, die gegevens dien je dus
zowel gekuist als (indien de gebruiker erom vraagt) in oorspronkelijke
vorm te kunnen weergeven.

BTW de invloed van bv htmlentities is nihil.

--

Daniel Tryba