Onderwerp: replace functie / SQL injection

John Bokma <postmaster@castleamber.com> wrote:
>> Nee dat wil hij niet, zie het stukje pseudo code:
>> 'if -- iets gevonden then
>> response.write "<H1>H? sukkel, jij dacht dat slimmer was dan
>> ik?</h1>" response.end
>> end if
>
> "Hallo
>
> Om *SQL injection te voorkomen*, heb ik de volgende code geschreven.
> Deze heb ik in mijn config.asp staan; een bestand die automatisch
> wordt ingevoegd bij elke pagina. Waardes vraag ik op met
>
> id=killchars(request("id")
>
>
> Maar nu wil ik dat een variabele "true" wordt als hij ??n van de
> *woorden/letters heeft gevonden, zodat ik een tekst kan laten
> weergeven.*
>
> Hoe doe ik dat?
> "
>
> Dus de OP wil killchars een true waarde laten opleveren zodat er een
> bericht afgedrukt wordt, dus:

Je moet wel het _hele_ artikel lezen, inclusief code dus.

> if (iets stouts) then "Stoute gebruiker";

Ik lees toch echt iets anders in OP:

$str=foo($str)
if(var)
...

Immers 'een variabele "true" wordt' is iets anders dan de
geretourneerde waard.

Een OO oplossing kan natuurlijk ook.

Daniel Tryba wrote:

> Tjerk Wolterink <tjerk@wolterinkwebdesign.com> wrote:
>> Wat ik bedoel is: als je sql-injection wilt voorkomen dan moet je
>> niet domweg gaan testen of er sql termen in een bepaalde variable
>> voorkomen. nee (dat doet killchars toch, ben geen visual basic
>> expert).
>
> Zoals ik al zie het is niet geweldig, maar nog steeds beter dan niets.

Ik weet het niet: wat is beter: iets wat een vals gevoel geeft van "dit
werkt", of ik zit onveilig.

> En laat dat nu net ook in die voorbeeld functie zitten. Maarja PHP
> addslahes/stripslashes werkt bv niet op een Sybase database (tenzij je
> de instellingen aanpast).

Wat ik niet snap is waarom PHP niet gewoon met prepared statements kan
werken (ik zie dat nooit tenminste, wel stipzusenzo, en base64 encoded
e.d.). Maar goed, ik snap wel meer niet van PHP. Bij Perl (tenzij ik het
niet snap), kan ik met een prepared statement *willekeurige* data ergens in
proppen zonder mij zorgen te hoeven maken. Dat heeft de maker van de driver
al gedaan, en daar vertrouw ik op. En dan zit je ook niet met het gezeur
dat die hack wel hier werkt, maar niet daar.

--
John Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Website design: http://johnbokma.com/websitedesign/
Ervaren Perl / Java programmeur beschikbaar: http://castleamber.com/
Tevreden opdrachtgevers: http://castleamber.com/testimonials.html

Daniel Tryba wrote:

> John Bokma <postmaster@castleamber.com> wrote:
>>> Nee dat wil hij niet, zie het stukje pseudo code:
>>> 'if -- iets gevonden then
>>> response.write "<H1>H? sukkel, jij dacht dat slimmer was dan
>>> ik?</h1>" response.end
>>> end if
>>
>> "Hallo
>>
>> Om *SQL injection te voorkomen*, heb ik de volgende code geschreven.
>> Deze heb ik in mijn config.asp staan; een bestand die automatisch
>> wordt ingevoegd bij elke pagina. Waardes vraag ik op met
>>
>> id=killchars(request("id")
>>
>>
>> Maar nu wil ik dat een variabele "true" wordt als hij ??n van de
>> *woorden/letters heeft gevonden, zodat ik een tekst kan laten
>> weergeven.*
>>
>> Hoe doe ik dat?
>> "
>>
>> Dus de OP wil killchars een true waarde laten opleveren zodat er een
>> bericht afgedrukt wordt, dus:
>
> Je moet wel het _hele_ artikel lezen, inclusief code dus.

Ok, ga ik nu doen :-D

>> if (iets stouts) then "Stoute gebruiker";
>
> Ik lees toch echt iets anders in OP:
>
> $str=foo($str)
> if(var)
> ...
>
> Immers 'een variabele "true" wordt' is iets anders dan de
> geretourneerde waard.

Ok, van wat ik begrijp:

Als er in mijn string een "bad word" zit dan wil ik niet alleen het "bad
word" wordt vervangen, maar ook een variable op true gezet wordt, zodat
ik een berichtje af kan drukken.

Kortom, de killchars SQL injection prevention moet niet alleen een

s/badword/XXX/g; doen over een inputstring, nee, het moet ook nog ff "He
Sukkel" terugsturen naar de browser.

Ik lees daar niks over sex e.d. Wel dat de OP een mogelijke scriptkiddie
een oorveeg wil geven.

Niet alleen is dit extreem domme code (en met een Reader Rating van 9.2
zou ik geen lezersbijdragen durven gebruiken van SitePoint) maar het
vervuilt mogelijk ook nog eens de database bij hackpogingen.

En ik heb geen idee of replace case-insensitive is en welke DB gebruikt
wordt, maar MySQL heeft geen moeten met SeLeCT, DRoP, DeLeTE en zo
vzviw.

--
John Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Website design: http://johnbokma.com/websitedesign/
Ervaren Perl / Java programmeur beschikbaar: http://castleamber.com/
Tevreden opdrachtgevers: http://castleamber.com/testimonials.html

John Bokma wrote:
> Joep wrote:
>
>
>>>>>Oh, ik ben het met 'm eens de code is ongelooflijk dom.
>>
>>Tja, ik vond de gedachte wel slim: alle gevaarlijke elementen
>>uitbannen maar goed....
>
>
> Dat is altijd fout, want dan moet je alle gevaarlijke elementen weten.
> Beter: maak een lijst van wat mag. Staat het niet in de lijst, dan is het
> een gevaarlijk element. Jij weet wat mag. Maar jij weet wellicht niet wat
> gevaarlijk is.

Dat is natuurlijk een mooie gedachte, en zeker te prefereren indien
mogelijk. Maar wat ga je doen als je variable gedefinieerd is als 'een
stuk tekst met html opmaak' ? Alle toegestane html elementen in een lijst
zetten ? Zou nog best kunnen, maar het gevaar kan ook in je attributes
zitten, onclick bijvoorbeeld. Die ook allemaal erin zetten ? Zelfs dan ben
je er nog niet helemaal waarschijnlijk, een href kan ook javascript
bevatten, maar die wil je niet helemaal uitbannen.

Michiel de Roo wrote:

> John Bokma wrote:
>> Joep wrote:
>>
>>
>>>>>>Oh, ik ben het met 'm eens de code is ongelooflijk dom.
>>>
>>>Tja, ik vond de gedachte wel slim: alle gevaarlijke elementen
>>>uitbannen maar goed....
>>
>>
>> Dat is altijd fout, want dan moet je alle gevaarlijke elementen
>> weten. Beter: maak een lijst van wat mag. Staat het niet in de lijst,
>> dan is het een gevaarlijk element. Jij weet wat mag. Maar jij weet
>> wellicht niet wat gevaarlijk is.
>
> Dat is natuurlijk een mooie gedachte, en zeker te prefereren indien
> mogelijk. Maar wat ga je doen als je variable gedefinieerd is als 'een
> stuk tekst met html opmaak'

Als je dat direct in een stuk HTML gaat weergeven moet je daar zeer
zeker mee oppassen.

> ? Alle toegestane html elementen in een
> lijst zetten ?

Waarom niet? Hoeveel zijn dat er denk je? Sterker, je zal zelfs moeten
kijken of ze afgesloten zijn en zo, dus validatie. Je wil niet dat
iemand <h1>Whoehahaha kan ingeven, en dat de h1 lekker doorwerkt in de
rest van de pagina.

> Zou nog best kunnen, maar het gevaar kan ook in je
> attributes zitten, onclick bijvoorbeeld.

Je wilt zomaar ook JavaScript gaan toestaan? Ik vraag mij af hoeveel
mensen zo gek zijn :-D.

> Die ook allemaal erin zetten
> ?

En het probleem is? Sterker, denk je niet dat er mensen zijn die al
keurig dit voor je geschreven hebben? Ik hoop dat diverse message boards
inderdaad deze dingen controleren.

Ik gebruik er wel eens een, en die gebruiken bbcode. En dat is heel
beperkt, en ik herinner mij dat je daar gewoon een class voor kan
downloaden.

> Zelfs dan ben je er nog niet helemaal waarschijnlijk, een href kan
> ook javascript bevatten, maar die wil je niet helemaal uitbannen.

Omdat? Omdat je pop up venstertjes wilt maken? Als je dat zou willen,
wat let je om

<popup href="..."></popup> beschikbaar te maken?

--
John Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Website design: http://johnbokma.com/websitedesign/
Ervaren Perl / Java programmeur beschikbaar: http://castleamber.com/
Tevreden opdrachtgevers: http://castleamber.com/testimonials.html

John Bokma wrote:
> Michiel de Roo wrote:

>>Zou nog best kunnen, maar het gevaar kan ook in je
>>attributes zitten, onclick bijvoorbeeld.
>
> Je wilt zomaar ook JavaScript gaan toestaan? Ik vraag mij af hoeveel
> mensen zo gek zijn :-D.

Nee, dat wil je dus niet. Je wilt helemaal geen onClick e.d. toestaan.

>
>
>>Die ook allemaal erin zetten
>>?
>
>
> En het probleem is? Sterker, denk je niet dat er mensen zijn die al
> keurig dit voor je geschreven hebben? Ik hoop dat diverse message boards
> inderdaad deze dingen controleren.
>
> Ik gebruik er wel eens een, en die gebruiken bbcode. En dat is heel
> beperkt, en ik herinner mij dat je daar gewoon een class voor kan
> downloaden.

Dat is voor mij geen optie. Ik geef gebruikers bij voorkeur een grafische
editor álá htmlarea of anders gewoon een textarea. bbcode vind ik hopeloos
ouderwets. Ook gezien het grote aantal mensen dat wel een beetje html kent
vind ik het handiger om gelijk (beperkt) html toe te staan.

Overigens heeft Perl de class HTML::TagFilter, die ziet er aardig
bedrijfszeker uit.

>
>
>>Zelfs dan ben je er nog niet helemaal waarschijnlijk, een href kan
>>ook javascript bevatten, maar die wil je niet helemaal uitbannen.
>
>
> Omdat? Omdat je pop up venstertjes wilt maken? Als je dat zou willen,
> wat let je om
>
> <popup href="..."></popup> beschikbaar te maken?
>

De href wil je niet helemaal uitbannen, de javascript/vbscript erin juist
wél ;-) De meeste php scripts die ik zie gebruiken voor xss beveiliging
toch het uitsluit principe, maar je kunt je inderdaad afvragen of dat de
juiste weg is. Ik zal nog eens kijken of er wat kant en klaar is dat beter
werkt.

Een oplossing die beide implementeert kan natuurlijk ook nog. Als iemand
iets probeert te submitten met overduidelijk javascript of vbscript erin
dan kun je een nette melding geven dat dit niet mag en waarom. Voor de
rest haal je de code door het 'toegestane tag filter'.

Michiel de Roo wrote:

> John Bokma wrote:
>> Michiel de Roo wrote:
>
>>>Zou nog best kunnen, maar het gevaar kan ook in je
>>>attributes zitten, onclick bijvoorbeeld.
>>
>> Je wilt zomaar ook JavaScript gaan toestaan? Ik vraag mij af hoeveel
>> mensen zo gek zijn :-D.
>
> Nee, dat wil je dus niet. Je wilt helemaal geen onClick e.d. toestaan.

Ah, gelukkig :-D

>> Ik gebruik er wel eens een, en die gebruiken bbcode. En dat is heel
>> beperkt, en ik herinner mij dat je daar gewoon een class voor kan
>> downloaden.
>
> Dat is voor mij geen optie. Ik geef gebruikers bij voorkeur een
> grafische editor álá htmlarea of anders gewoon een textarea.

Bij mij hangt dat van de gebruikers af :-D.

> bbcode
> vind ik hopeloos ouderwets.

Voor veel mensen is het eenvoudiger te begrijpen dan HTML (echt waar).

> Ook gezien het grote aantal mensen dat wel
> een beetje html kent

Uit mijn kennissenkring zijn dat er wellicht 3.

> vind ik het handiger om gelijk (beperkt) html toe
> te staan.
>
> Overigens heeft Perl de class HTML::TagFilter, die ziet er aardig
> bedrijfszeker uit.

Niet naar gekeken, zal 'm onthouden, bedankt.

>>>Zelfs dan ben je er nog niet helemaal waarschijnlijk, een href kan
>>>ook javascript bevatten, maar die wil je niet helemaal uitbannen.
>>
>> Omdat? Omdat je pop up venstertjes wilt maken? Als je dat zou willen,
>> wat let je om
>>
>> <popup href="..."></popup> beschikbaar te maken?
>>
>
> De href wil je niet helemaal uitbannen, de javascript/vbscript erin
> juist wél ;-)

Ah, ok. Ik las dat je bepaalde JavaScript dingen wel wilde toestaan :-D.

> De meeste php scripts die ik zie gebruiken voor xss
> beveiliging toch het uitsluit principe, maar je kunt je inderdaad
> afvragen of dat de juiste weg is. Ik zal nog eens kijken of er wat
> kant en klaar is dat beter werkt.

Met een href zou ik zeggen: het moet of beginnen met http:// of een
geldige relatieve URL zijn. Wellicht dat in Perl de URI class te
gebruiken is om dit goed af te handelen. (URL er in, evt. absoluut
maken, controleren of die valide is, en het scheme http is).

> Een oplossing die beide implementeert kan natuurlijk ook nog. Als
> iemand iets probeert te submitten met overduidelijk javascript of
> vbscript erin dan kun je een nette melding geven dat dit niet mag en
> waarom. Voor de rest haal je de code door het 'toegestane tag filter'.

Klinkt stukken beter. Ik weet dat het een berg werk is, maar het
voorkomt nare verassingen van de vorm: ai, nieuwe exploit.

--
John Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Website design: http://johnbokma.com/websitedesign/
Ervaren Perl / Java programmeur beschikbaar: http://castleamber.com/
Tevreden opdrachtgevers: http://castleamber.com/testimonials.html