Bekijk Volledige Versie : slashes teveel.....
He hallo
Ik heb een scriptje wat een textfile in de database laadt.
In een van de velden komt tekst te staan waarvan de enters behouden moeten
blijven.
Deze staan in de tekst als "blablabla\r\n". Vervelend is alleen dat die
"\r\n" onderweg naar de database
van mijn provider veranderd worden in \\r\\n. Is dit te ondervangen?
Tia DS
DS wrote:
> Ik heb een scriptje wat een textfile in de database laadt.
> In een van de velden komt tekst te staan waarvan de enters behouden
> moeten blijven.
> Deze staan in de tekst als "blablabla\r\n". Vervelend is alleen dat
> die "\r\n" onderweg naar de database
> van mijn provider veranderd worden in \\r\\n. Is dit te ondervangen?
Ik neem maar aan dat je met php werkt?
Probeer dan eens 'stripslashes' (
http://nl2.php.net/manual/en/function.stripslashes.php )
--
Inca
Rene Pijlman
08/03/04, 20:55
DS:
>Ik heb een scriptje wat een textfile in de database laadt.
>In een van de velden komt tekst te staan waarvan de enters behouden moeten
>blijven.
>Deze staan in de tekst als "blablabla\r\n". Vervelend is alleen dat die
>"\r\n" onderweg naar de database
>van mijn provider veranderd worden in \\r\\n. Is dit te ondervangen?
Zonder informatie over script, broncode, programmeertaal, database etc. is
hier geen chocola van te maken.
Wil je deze tips even lezen om het probleem wat duidelijker te maken?
http://www.leren.nl/usenet/help/
--
René Pijlman
Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid>:
> DS:
>>Ik heb een scriptje wat een textfile in de database laadt. In een van
>>de velden komt tekst te staan waarvan de enters behouden moeten blijven.
>>Deze staan in de tekst als "blablabla\r\n". Vervelend is alleen dat die
>>"\r\n" onderweg naar de database van mijn provider veranderd worden in
>>\\r\\n. Is dit te ondervangen?
>
> Zonder informatie over script, broncode, programmeertaal, database etc.
> is hier geen chocola van te maken.
Bij gezeik met slashes krijg ik altijd meteen het gevoel dat er PHP in het
spel is :)
--
robert
Daniel Tryba
08/03/04, 21:45
robert <{n.i.w.s}@allyourbass.org.invalid> wrote:
[lalala slashes]
> > Zonder informatie over script, broncode, programmeertaal, database etc.
> > is hier geen chocola van te maken.
>
> Bij gezeik met slashes krijg ik altijd meteen het gevoel dat er PHP in het
> spel is :)
Ach, het is alleen maar omdat er een uiterst ongunstige default is
gekozen :(
Ooit komt men daar nog wel achter (zoals met het register_globals
verhaal).
--
Daniel Tryba
Daniel Tryba <news_nl.internet.www.server-side@canopus.nl>:
> robert <{n.i.w.s}@allyourbass.org.invalid> wrote: [lalala slashes]
>
>> > Zonder informatie over script, broncode, programmeertaal, database
>> > etc. is hier geen chocola van te maken.
>>
>> Bij gezeik met slashes krijg ik altijd meteen het gevoel dat er PHP in
>> het spel is :)
>
> Ach, het is alleen maar omdat er een uiterst ongunstige default is
> gekozen :(
En bij 'ongunstige default' moet ik ook meteen aan PHP denken! ;)
--
robert
Erik Hensema
08/03/04, 22:05
Daniel Tryba (news_nl.internet.www.server-side@canopus.nl) wrote:
> robert <{n.i.w.s}@allyourbass.org.invalid> wrote:
> [lalala slashes]
>> > Zonder informatie over script, broncode, programmeertaal, database etc.
>> > is hier geen chocola van te maken.
>>
>> Bij gezeik met slashes krijg ik altijd meteen het gevoel dat er PHP in het
>> spel is :)
>
> Ach, het is alleen maar omdat er een uiterst ongunstige default is
> gekozen :(
>
> Ooit komt men daar nog wel achter (zoals met het register_globals
> verhaal).
Ik zeg magic_gpc_slashes danook altijd direct uit, tenminste, als
ik controle over de server heb. Het is echt vreselijk irritant.
Typisch iets wat leuk is voor de absolute beginner, maar
onbruikbaar als je niveau een klein tandje hoger ligt.
--
Erik Hensema (erik@hensema.net) ICQ# 8280101
Quoting-HOWTO: http://www.leerquoten.nl
Michiel de Roo
08/03/04, 22:05
Erik Hensema wrote:
> Daniel Tryba (news_nl.internet.www.server-side@canopus.nl) wrote:
>
>>robert <{n.i.w.s}@allyourbass.org.invalid> wrote:
>>[lalala slashes]
>>
>>>>Zonder informatie over script, broncode, programmeertaal, database etc.
>>>>is hier geen chocola van te maken.
>>>
>>>Bij gezeik met slashes krijg ik altijd meteen het gevoel dat er PHP in het
>>>spel is :)
>>
>>Ach, het is alleen maar omdat er een uiterst ongunstige default is
>>gekozen :(
>>
>>Ooit komt men daar nog wel achter (zoals met het register_globals
>>verhaal).
>
>
> Ik zeg magic_gpc_slashes danook altijd direct uit, tenminste, als
> ik controle over de server heb. Het is echt vreselijk irritant.
> Typisch iets wat leuk is voor de absolute beginner, maar
> onbruikbaar als je niveau een klein tandje hoger ligt.
>
magic_gpc_slashes ??
magic_quotes_gpc bedoel je waarschijnlijk. Ik zie niet in wat er irritant
aan is eigenlijk. En wat het met niveau te maken heeft al helemaal niet.
--
Michiel de Roo.
Online concert agenda voor de stad Utrecht:
http://www.utrecht-live.nl
Daniel Tryba
08/03/04, 22:15
Michiel de Roo <michiel@mderoopuntnl> wrote:
> magic_gpc_slashes ??
>
> magic_quotes_gpc bedoel je waarschijnlijk. Ik zie niet in wat er irritant
> aan is eigenlijk. En wat het met niveau te maken heeft al helemaal niet.
Het verhaspelt gedeeltelijk waardes die "van buiten" komen, ongeacht
waar je deze voor wil gebruiken (als ik sybase gebruik moet het '' ipv
\' zijn, als ik het terug naar een browser wil sturen moet het '
worden indien de input een ' bevatte)
Met niveau (ik lees ervaring) wordt warschijnlijk bedoelt dat beginners
een totaal gebruik aan kennis hebben van de gevolgen van een foutief
gekozen (of totaal gebrek aan) escaping mechanisme.
--
Daniel Tryba
Erik Hensema
08/03/04, 22:45
Michiel de Roo (michiel@mderooPUNTNL) wrote:
> Erik Hensema wrote:
>> Daniel Tryba (news_nl.internet.www.server-side@canopus.nl) wrote:
>>
>>>robert <{n.i.w.s}@allyourbass.org.invalid> wrote:
>>>[lalala slashes]
>>>
>>>>>Zonder informatie over script, broncode, programmeertaal, database etc.
>>>>>is hier geen chocola van te maken.
>>>>
>>>>Bij gezeik met slashes krijg ik altijd meteen het gevoel dat er PHP in het
>>>>spel is :)
>>>
>>>Ach, het is alleen maar omdat er een uiterst ongunstige default is
>>>gekozen :(
>>>
>>>Ooit komt men daar nog wel achter (zoals met het register_globals
>>>verhaal).
>>
>>
>> Ik zeg magic_gpc_slashes danook altijd direct uit, tenminste, als
>> ik controle over de server heb. Het is echt vreselijk irritant.
>> Typisch iets wat leuk is voor de absolute beginner, maar
>> onbruikbaar als je niveau een klein tandje hoger ligt.
>>
>
> magic_gpc_slashes ??
>
> magic_quotes_gpc bedoel je waarschijnlijk. Ik zie niet in wat er irritant
> aan is eigenlijk. En wat het met niveau te maken heeft al helemaal niet.
Dat bedoel ik. M'n geheugen werkt op maandag niet.
Het is irritant omdat ze aannemen dat je alle waardes
ongecontroleerd in een sql statement zet. Dat is natuurlijk niet
waar. Alleen beginners zijn zo naief om zoiets te doen (dat is
wat het met niveau temaken heeft).
Normaal check je alle waardes op juiste invoer. Na die checks
gooi je de waarde door addslashes() en het kan richting db.
Of niet. Wie zegt dat _alle_ waardes via get, post of cookies
richting een database gaan? Dat is natuurlijk onzin.
Consequentie is dat je eigenlijk alle gpc waardes eerst door
stripslashes() moet halen voordat je er iets mee kunt. En daarmee
is magic_quotes_gpc volkomen nutteloos geworden
Dat bedoel ik. M'n geheugen werkt op maandag niet.
Het is irritant omdat ze aannemen dat je alle waardes
ongecontroleerd in een sql statement zet. Dat is natuurlijk niet
waar. Alleen beginners zijn zo naief om zoiets te doen (dat is
wat het met niveau temaken heeft).
Normaal check je alle waardes op juiste invoer. Na die checks
gooi je de waarde door addslashes() en het kan richting db.
Of niet. Wie zegt dat _alle_ waardes via get, post of cookies
richting een database gaan? Dat is natuurlijk onzin.
Consequentie is dat je eigenlijk alle gpc waardes eerst door
stripslashes() moet halen voordat je er iets mee kunt. En daarmee
is magic_quotes_gpc volkomen nutteloos geworden.
Zelf gebruik ik overigens deze functies:
function get_int($naam, $default = 0) {
return isset($_GET[$naam]) ? (int)$_GET[$naam] : (int)$default;
}
function get_bool($naam, $default = false) {
return isset($_GET[$naam]) ? $_GET[$naam] == 'yes' : (bool)$default;
}
function get_string($naam, $default = "") {
if(isset($_GET[$naam])) {
if((bool)ini_get('magic_quotes_gpc')) {
return stripslashes($_GET[$naam]);
} else {
return $_GET[$naam];
}
} else {
return $default;
}
}
(en de equivalenten voor POST)
Iets vriendelijker wrappers om $_GET en $_POST zo. Niet voor elke
situatie bruikbaar, maar ik vind ze fijn ;-)
(en nee, ze zijn geen vervanging voor het checken van de invoer)
--
Erik Hensema (erik@hensema.net) ICQ# 8280101
So, what's with this guy Gideon, anyway? And why can't he ever
remember his Bible?
Erik Hensema wrote:
> Het is irritant omdat ze aannemen dat je alle waardes
> ongecontroleerd in een sql statement zet. Dat is natuurlijk niet
> waar. Alleen beginners zijn zo naief om zoiets te doen (dat is
> wat het met niveau temaken heeft).
Ik denk niet dat dat de reden is. De reden lijkt me veel simpeler. Php is
gemaakt om van alles en nog wat snel en makkelijk te doen. Vandaar de enorme
hoeveelheid functies, die als voor- en nadeel wordt gezien. Ik denk dat
hetzelfde hier speelt, de oorzaak lijkt me eerder de wens om 'snel snel'
iets te doen, dan dat het op beginners is gericht.
> Normaal check je alle waardes op juiste invoer. Na die checks
> gooi je de waarde door addslashes() en het kan richting db.
Welke checks voer jij uit op de invoer van een text-veld? Ik kan er
eigenlijk geen verzinnen - wat zie ik over het hoofd?
> function get_string($naam, $default = "") {
> if(isset($_GET[$naam])) {
> if((bool)ini_get('magic_quotes_gpc')) {
> return stripslashes($_GET[$naam]);
> } else {
> return $_GET[$naam];
> }
> } else {
> return $default;
> }
> }
Waar check je hier nou precies? Of doe je dat na de 'stripslashes' en na de
return?
> Iets vriendelijker wrappers om $_GET en $_POST zo. Niet voor elke
> situatie bruikbaar, maar ik vind ze fijn ;-)
> (en nee, ze zijn geen vervanging voor het checken van de invoer)
In het geval van int en bool: waarom niet, welke checks missen er? En zou je
deze checks niet ook kunnen opnemen in de get-functies, zodat je daarna
klaar bent? Of heeft dat andere nadelen?
--
Inca
On Mon, 8 Mar 2004 21:44:14 +0000 (UTC), Erik Hensema <usenet@smac.hensema.net> wrote:
> Het is irritant omdat ze aannemen dat je alle waardes
> ongecontroleerd in een sql statement zet. Dat is natuurlijk niet
> waar. Alleen beginners zijn zo naief om zoiets te doen (dat is
> wat het met niveau temaken heeft).
Uhummm, pas nog iemand mysql_escape_string zien gebruiken om
het 'veilig' te maken hoor :-). Pas toen we het js alertje er weer
uittoverden was het schrikken.
> if((bool)ini_get('magic_quotes_gpc'))
Dit is een beetje dubbel op aangezien die functie beter is op te
vragen met get_magic_quotes_gpc(). Die geeft een int terug.
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 Mon, 8 Mar 2004 22:59:24 +0100,
Inca <shadow*movements@wanadoo.NOSPAM.invalid> wrote:
> Erik Hensema wrote:
>> Normaal check je alle waardes op juiste invoer. Na die checks
>> gooi je de waarde door addslashes() en het kan richting db.
>
> Welke checks voer jij uit op de invoer van een text-veld? Ik kan er
> eigenlijk geen verzinnen - wat zie ik over het hoofd?
Niet zo heel moeilijk hoor. strip_tags kan parameters aan. Als je echter
zeker wilt weten dat ze geen sub params hebben kun je ook een bbtag
implementeren, dan de tags strippen en vervolgens de bbtags weer omzetten
in html die men mag invoeren.
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>
Erik Hensema
09/03/04, 00:15
Inca (shadow*movements@wanadoo.NOSPAM.invalid) wrote:
> Erik Hensema wrote:
>> Het is irritant omdat ze aannemen dat je alle waardes
>> ongecontroleerd in een sql statement zet. Dat is natuurlijk niet
>> waar. Alleen beginners zijn zo naief om zoiets te doen (dat is
>> wat het met niveau temaken heeft).
>
> Ik denk niet dat dat de reden is. De reden lijkt me veel simpeler. Php is
> gemaakt om van alles en nog wat snel en makkelijk te doen. Vandaar de enorme
> hoeveelheid functies, die als voor- en nadeel wordt gezien. Ik denk dat
> hetzelfde hier speelt, de oorzaak lijkt me eerder de wens om 'snel snel'
> iets te doen, dan dat het op beginners is gericht.
Dat zeg ik. Voor beginners is het makkelijk, voor gevorderden is
het een last.
>> Normaal check je alle waardes op juiste invoer. Na die checks
>> gooi je de waarde door addslashes() en het kan richting db.
>
> Welke checks voer jij uit op de invoer van een text-veld? Ik kan er
> eigenlijk geen verzinnen - wat zie ik over het hoofd?
Misschien doe je geen enkele check op een text-veld. Ligt eraan
wat je verwacht wat in dat textveld staat.
>> function get_string($naam, $default = "") {
>> if(isset($_GET[$naam])) {
>> if((bool)ini_get('magic_quotes_gpc')) {
>> return stripslashes($_GET[$naam]);
>> } else {
>> return $_GET[$naam];
>> }
>> } else {
>> return $default;
>> }
>> }
>
> Waar check je hier nou precies? Of doe je dat na de 'stripslashes' en na de
> return?
Ik check niks. Het enige wat die functie doet is het teruggeven
van een stringwaarde uit _GET, zonder warnings te geven als je
error_reporting(E_ALL) aan hebt staan. Plus dat je de
mogelijkheid hebt tot het geven van een default, wat soms handig
is.
>> Iets vriendelijker wrappers om $_GET en $_POST zo. Niet voor elke
>> situatie bruikbaar, maar ik vind ze fijn ;-)
>> (en nee, ze zijn geen vervanging voor het checken van de invoer)
>
> In het geval van int en bool: waarom niet, welke checks missen er? En zou je
> deze checks niet ook kunnen opnemen in de get-functies, zodat je daarna
> klaar bent? Of heeft dat andere nadelen?
Er zijn geen generieke checks mogelijk. Misschien lees je een
leeftijd in. Dan check je of die niet negatief is. Misschien
geeft die bool een situatie aan die afhangt van andere velden. Je
weet het niet.
Je moet gewoon altijd checken of de invoer is zoals je verwacht
dat hij moet zijn. En dat hangt volledig van je applicatie af.
--
Erik Hensema (erik@hensema.net) ICQ# 8280101
Quoting-HOWTO: http://www.leerquoten.nl
Erik Hensema
09/03/04, 00:15
Hans (nomailwanted@e35203.upc-e.chello.nl) wrote:
> On Mon, 8 Mar 2004 21:44:14 +0000 (UTC), Erik Hensema <usenet@smac.hensema.net> wrote:
>
>> Het is irritant omdat ze aannemen dat je alle waardes
>> ongecontroleerd in een sql statement zet. Dat is natuurlijk niet
>> waar. Alleen beginners zijn zo naief om zoiets te doen (dat is
>> wat het met niveau temaken heeft).
>
> Uhummm, pas nog iemand mysql_escape_string zien gebruiken om
> het 'veilig' te maken hoor :-). Pas toen we het js alertje er weer
> uittoverden was het schrikken.
Hehe :-) stringwaardes die richting html gaan, die haal je
vrijwel altijd door htmlentities() natuurlijk. Maar ik ben erg
blij dat niet alle stringwaardes vanuit sql volautomatisch door
htmlentities() gaan ;-)
>> if((bool)ini_get('magic_quotes_gpc'))
>
> Dit is een beetje dubbel op aangezien die functie beter is op te
> vragen met get_magic_quotes_gpc(). Die geeft een int terug.
Tja. php blijft bloated als de pest.
--
Erik Hensema (erik@hensema.net) ICQ# 8280101
Quoting-HOWTO: http://www.leerquoten.nl
On Mon, 8 Mar 2004 23:13:33 +0000 (UTC), Erik Hensema <usenet@smac.hensema.net> wrote:
> Hans (nomailwanted@e35203.upc-e.chello.nl) wrote:
>> Uhummm, pas nog iemand mysql_escape_string zien gebruiken om
>> het 'veilig' te maken hoor :-). Pas toen we het js alertje er weer
>> uittoverden was het schrikken.
>
> Hehe :-) stringwaardes die richting html gaan, die haal je
> vrijwel altijd door htmlentities() natuurlijk. Maar ik ben erg
> blij dat niet alle stringwaardes vanuit sql volautomatisch door
> htmlentities() gaan ;-)
Die gooi je uiteraard weer door je eigen filter heen :-)
>>> if((bool)ini_get('magic_quotes_gpc'))
>>
>> Dit is een beetje dubbel op aangezien die functie beter is op te
>> vragen met get_magic_quotes_gpc(). Die geeft een int terug.
>
> Tja. php blijft bloated als de pest.
Om die int? Nog altijd beter dan een boolean en een string :-)
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>
Erik Hensema
09/03/04, 00:35
Hans (nomailwanted@e35203.upc-e.chello.nl) wrote:
> On Mon, 8 Mar 2004 23:13:33 +0000 (UTC), Erik Hensema <usenet@smac.hensema.net> wrote:
>> Hans (nomailwanted@e35203.upc-e.chello.nl) wrote:
>
>>> Uhummm, pas nog iemand mysql_escape_string zien gebruiken om
>>> het 'veilig' te maken hoor :-). Pas toen we het js alertje er weer
>>> uittoverden was het schrikken.
>>
>> Hehe :-) stringwaardes die richting html gaan, die haal je
>> vrijwel altijd door htmlentities() natuurlijk. Maar ik ben erg
>> blij dat niet alle stringwaardes vanuit sql volautomatisch door
>> htmlentities() gaan ;-)
>
> Die gooi je uiteraard weer door je eigen filter heen :-)
>
>>>> if((bool)ini_get('magic_quotes_gpc'))
>>>
>>> Dit is een beetje dubbel op aangezien die functie beter is op te
>>> vragen met get_magic_quotes_gpc(). Die geeft een int terug.
>>
>> Tja. php blijft bloated als de pest.
>
> Om die int? Nog altijd beter dan een boolean en een string :-)
Nee, omdat get_magic_quotes_gpc een volkomen overbodige functie
is gezien je hetzelfde uit ini_get kunt krijgen. Met andere
woorden: sloop get_magic_quotes_gpc uit php, en je verliest geen
enkele functionaliteit.
--
Erik Hensema (erik@hensema.net) ICQ# 8280101
Please note that my From: field is spamtrapped.
Erik Hensema wrote:
>>> Normaal check je alle waardes op juiste invoer. Na die checks
>>> gooi je de waarde door addslashes() en het kan richting db.
>>
>> Welke checks voer jij uit op de invoer van een text-veld? Ik kan er
>> eigenlijk geen verzinnen - wat zie ik over het hoofd?
>
> Misschien doe je geen enkele check op een text-veld. Ligt eraan
> wat je verwacht wat in dat textveld staat.
Wat is er dan mis met het direkt gebruiken van de magic-quotes?
Scheelt een boel gedoe, toch?
>> In het geval van int en bool: waarom niet, welke checks missen er?
>> En zou je deze checks niet ook kunnen opnemen in de get-functies,
>> zodat je daarna klaar bent? Of heeft dat andere nadelen?
>
> Er zijn geen generieke checks mogelijk. Misschien lees je een
> leeftijd in. Dan check je of die niet negatief is. Misschien
> geeft die bool een situatie aan die afhangt van andere velden. Je
> weet het niet.
Maar dat zijn op zich geen grote problemen. Je kunt een int die je op deze
manier krijgt toch direkt invoeren in SQL zonder gevaar?
(Iets als:
$id = get_int( "ID", 0 );
$sql = "select * from table where id = $id";
)
Dat kan wel een paar overbodige sql-statements opleveren maar geen exploits
of andere rariteiten, toch?
--
Inca
Erik Hensema
09/03/04, 11:15
Inca (shadow*movements@wanadoo.NOSPAM.invalid) wrote:
> Erik Hensema wrote:
>>>> Normaal check je alle waardes op juiste invoer. Na die checks
>>>> gooi je de waarde door addslashes() en het kan richting db.
>>>
>>> Welke checks voer jij uit op de invoer van een text-veld? Ik kan er
>>> eigenlijk geen verzinnen - wat zie ik over het hoofd?
>>
>> Misschien doe je geen enkele check op een text-veld. Ligt eraan
>> wat je verwacht wat in dat textveld staat.
>
> Wat is er dan mis met het direkt gebruiken van de magic-quotes?
> Scheelt een boel gedoe, toch?
In dit specifieke geval: inderdaad.
>>> In het geval van int en bool: waarom niet, welke checks missen er?
>>> En zou je deze checks niet ook kunnen opnemen in de get-functies,
>>> zodat je daarna klaar bent? Of heeft dat andere nadelen?
>>
>> Er zijn geen generieke checks mogelijk. Misschien lees je een
>> leeftijd in. Dan check je of die niet negatief is. Misschien
>> geeft die bool een situatie aan die afhangt van andere velden. Je
>> weet het niet.
>
> Maar dat zijn op zich geen grote problemen. Je kunt een int die je op deze
> manier krijgt toch direkt invoeren in SQL zonder gevaar?
> (Iets als:
> $id = get_int( "ID", 0 );
> $sql = "select * from table where id = $id";
> )
> Dat kan wel een paar overbodige sql-statements opleveren maar geen exploits
> of andere rariteiten, toch?
In dit specifieke geval: inderdaad.
Maar nu neem je wel steeds aan dat je de data in een sql database
wilt stoppen.
Ik maak op dit moment bijvoorbeeld een heel simpel nieuws CMS
voor spamvrij.nl. Die heeft een preview modus: zonder het nieuws
item op te slaan, krijg je een html pagina te zien met hoe hij er
online uit gaat zien.
Dat is allemaal data wat ik niet controleer, maar WEL door
stripslashes moet halen, want het gaat niet naar sql toe.
Een andere applicatie van mij controleert zelf wachtwoorden. In
die wachtwoorden mogen tegens als ' en \ voor komen. Die wil ik
niet vern**kt hebben door magic quotes.
--
Erik Hensema (erik@hensema.net) ICQ# 8280101
Quoting-HOWTO: http://www.leerquoten.nl
Michiel de Roo
09/03/04, 15:45
Erik Hensema wrote:
> Inca (shadow*movements@wanadoo.NOSPAM.invalid) wrote:
>
>>Erik Hensema wrote:
>>
>>>>>Normaal check je alle waardes op juiste invoer. Na die checks
>>>>>gooi je de waarde door addslashes() en het kan richting db.
>>>>
>>>>Welke checks voer jij uit op de invoer van een text-veld? Ik kan er
>>>>eigenlijk geen verzinnen - wat zie ik over het hoofd?
>>>
>>>Misschien doe je geen enkele check op een text-veld. Ligt eraan
>>>wat je verwacht wat in dat textveld staat.
>>
>>Wat is er dan mis met het direkt gebruiken van de magic-quotes?
>>Scheelt een boel gedoe, toch?
>
>
> In dit specifieke geval: inderdaad.
>
>
>>>>In het geval van int en bool: waarom niet, welke checks missen er?
>>>>En zou je deze checks niet ook kunnen opnemen in de get-functies,
>>>>zodat je daarna klaar bent? Of heeft dat andere nadelen?
>>>
>>>Er zijn geen generieke checks mogelijk. Misschien lees je een
>>>leeftijd in. Dan check je of die niet negatief is. Misschien
>>>geeft die bool een situatie aan die afhangt van andere velden. Je
>>>weet het niet.
>>
>>Maar dat zijn op zich geen grote problemen. Je kunt een int die je op deze
>>manier krijgt toch direkt invoeren in SQL zonder gevaar?
>>(Iets als:
>> $id = get_int( "ID", 0 );
>> $sql = "select * from table where id = $id";
>>)
>>Dat kan wel een paar overbodige sql-statements opleveren maar geen exploits
>>of andere rariteiten, toch?
>
>
> In dit specifieke geval: inderdaad.
>
> Maar nu neem je wel steeds aan dat je de data in een sql database
> wilt stoppen.
>
> Ik maak op dit moment bijvoorbeeld een heel simpel nieuws CMS
> voor spamvrij.nl. Die heeft een preview modus: zonder het nieuws
> item op te slaan, krijg je een html pagina te zien met hoe hij er
> online uit gaat zien.
> Dat is allemaal data wat ik niet controleer, maar WEL door
> stripslashes moet halen, want het gaat niet naar sql toe.
>
> Een andere applicatie van mij controleert zelf wachtwoorden. In
> die wachtwoorden mogen tegens als ' en \ voor komen. Die wil ik
> niet vern**kt hebben door magic quotes.
>
Er zijn idd situaties te bedenken waarbij je geen slashes wilt. Volgens
mij is de situatie alsvolgt. Als magic_qoutes_gpc aan staat, wordt
stripslashes veelvuldig gebruikt, als het uit staat wordt addslashes
veelvuldig gebruikt. Het één is niet irritanter dan het ander. Voor een
ervaren programmeur maakt het al helemaal geen verschil, want die heeft
allang een generieke oplossing bedacht. Zoals jijzelf ook al aangeeft met
je get_XXX methoden.
Het geeft wel een enigszins vals gevoel van veiligheid natuurlijk. Je moet
er geen wonderen van verwachten en denken dat het AL je
beveilingsproblemen kan oplossen. Maar magic_qoutes_gpc aan is volgens mij
wel net een stukje veiliger dan magic_qoutes_gpc uit, althans voor veel
(slecht geschreven) scripts die ik heb gezien.
--
Michiel de Roo.
Online concert agenda voor de stad Utrecht:
http://www.utrecht-live.nl
Daniel Tryba
09/03/04, 17:15
Michiel de Roo <michiel@mderoopuntnl> wrote:
> Er zijn idd situaties te bedenken waarbij je geen slashes wilt. Volgens
> mij is de situatie alsvolgt. Als magic_qoutes_gpc aan staat, wordt
> stripslashes veelvuldig gebruikt,
Voordat de voor de situatie correcte escape mechanisme wordt gebruikt.
> als het uit staat wordt addslashes veelvuldig gebruikt.
Of een andere voor deze situatie correct mechanisme.
> Het ??n is niet irritanter dan het ander.
Maar in het eerste geval zal er vaak meer dan 1 functie moeten worden
aangeroepen, terwijl in het 2de geval er slechts 1 functie wordt
aangeroepen.
> Voor een ervaren programmeur maakt het al helemaal geen verschil, want
> die heeft allang een generieke oplossing bedacht.
De generieke oplossing is het pas encoden op het moment dat het nodig
is. En wat die encoding moet zijn is afhankelijk van het
gebruik/situatie.
--
Daniel Tryba
Erik Hensema wrote:
>> Wat is er dan mis met het direkt gebruiken van de magic-quotes?
>> Scheelt een boel gedoe, toch?
>
> In dit specifieke geval: inderdaad.
Dat lijkt me genoeg reden...
>> Dat kan wel een paar overbodige sql-statements opleveren maar geen
>> exploits of andere rariteiten, toch?
>
> In dit specifieke geval: inderdaad.
>
> Maar nu neem je wel steeds aan dat je de data in een sql database
> wilt stoppen.
Bij ints en bools etc speelt het hele probleem van stripslashes etc niet. Ik
doelde meer op het checken van de input.
> Dat is allemaal data wat ik niet controleer, maar WEL door
> stripslashes moet halen, want het gaat niet naar sql toe.
Het zal gewoon een numerieke afweging geweest zijn, en daar kun je het mee
eens zijn of niet... Maar ik zie het probleem nog steeds niet.
--
Inca
Michiel de Roo wrote:
> Volgens mij is de situatie alsvolgt. Als magic_qoutes_gpc aan staat,
> wordt stripslashes veelvuldig gebruikt, als het uit staat wordt
> addslashes veelvuldig gebruikt. Het één is niet irritanter dan het
> ander.
Ah, ja precies. Dat bedoelde ik.
--
Inca