code veilig maken

**marco verlinden** · 08-05-2012, 00:34

Ik wil mijn code extra veilig maken.
nu was ik aan het denken zou dit veilig zijn?

PHP Code:


$naam = ctype_alnum(mysql_real_escape_string(htmlentities($_GET['naam']))); $naam = str_replace("-", " ", $naam);

**Ellis Vogely** · 08-05-2012, 01:04

alleen mysql_real_escape_string(); is genoeg, dan kan er via sql injections niets meer gebeuren

**marco verlinden** · 08-05-2012, 01:40

bedankt

**Arek van Schaijk** · 10-05-2012, 03:09

Lol.. mysql_real_escape_string() voorkomt inderdaad SQL injections. Maar dit zegt nog niks over veiligheid. Sterker nog, het is zo lek als een mandje ;-)

Omdat men gewoon html kan toevoegen aan hun naam (<html>naam</html>) ben je vatbaar voor XSS en het gevolg daarvan is uiteraard bijvoorbeeld Session Hijacking.

Goed blijven valideren dus! je was goed op weg. Niet luisteren naar Ellis.

**Ruben P.** · 10-05-2012, 14:19

Controleer dus eerst netjes via een if-statement of de naam correct is. Je kan dit met ctype doen en erna kun je ook nog eventueel een max aantal chars aangeven.

**John Timmer** · 10-05-2012, 14:28

Origineel gepost door Arek van Schayk

Lol.. mysql_real_escape_string() voorkomt inderdaad SQL injections. Maar dit zegt nog niks over veiligheid. Sterker nog, het is zo lek als een mandje ;-)

Omdat men gewoon html kan toevoegen aan hun naam (<html>naam</html>) ben je vatbaar voor XSS en het gevolg daarvan is uiteraard bijvoorbeeld Session Hijacking.

Goed blijven valideren dus! je was goed op weg. Niet luisteren naar Ellis.

Hoezo?

Als je er ctype_alnum() omheen zet kan die naam toch alleen 'true' of 'false' worden... ;)

**Arek van Schaijk** · 11-05-2012, 01:01

Origineel gepost door John Timmer

Hoezo?

Als je er ctype_alnum() omheen zet kan die naam toch alleen 'true' of 'false' worden... ;)

Ik reageer op:

Origineel gepost door Ellis Vogely

alleen mysql_real_escape_string(); is genoeg, dan kan er via sql injections niets meer gebeuren

"alleen mysql_real_escape_string(); is genoeg"

Dat is dus niet genoeg.

**Martijn L.** · 11-05-2012, 01:07

Een betere oplossing dan mysql_real_escape vind ik overigens query statements. Het komt erop neer dat je de query los verzend van de data. In de query voer je dan gewoon een vraagteken in, en later stuur je de data los naar de database.

http://www.php.net/manual/en/class.mysqli-stmt.php

Als je jezelf die methode aanleert (ik vind het naast veiliger ook overzichtelijker) loop je ook niet het risico dat er een variabele doorglipt.

**Mittchel Van Vliet** · 11-05-2012, 01:14

Prepared statements zijn erg veilig en de programmatuur ziet er ook een stuk 'schoner' uit.
http://php.net/manual/en/pdo.prepared-statements.php

**John Timmer** · 11-05-2012, 01:38

Origineel gepost door Arek van Schayk

Ik reageer op:

"alleen mysql_real_escape_string(); is genoeg"

Dat is dus niet genoeg.

Om het alleen in de db te stoppen is dat zeker genoeg. Zolang je niet weet wat gedaan gaat worden bij het presenteren, kun je er verder niks over zeggen.

Maar mijn opmerking was uiteraard om aan te geven dat TS die regel niet eens ingeklopt heeft om te testen anders had ie vast zelf wel ook wel gezien dat het resultaat alles behalve goed zou zijn geweest :)

Edit: 'mooi' of 'handig' is een ander verhaal.

**Arek van Schaijk** · 11-05-2012, 02:36

Origineel gepost door John Timmer

Om het alleen in de db te stoppen is dat zeker genoeg. Zolang je niet weet wat gedaan gaat worden bij het presenteren, kun je er verder niks over zeggen.

Daar zit dus exact je denkfout! Data "presenteren" is een andere tak van sport als data "valideren". Je weet immers exact waar je data aan moet voldoen alvorens je het wegschrijft in de database. Lijkt me sterk dat jij deze validatie doet tijdens het lezen van de data.

SQL Injections en XSS staan op 1 en 2 in de OWASP top 10 webapplicatie kwetsbaarheden. Zorg dan tenminste dat programmeurs die zich melden met dit soort vragen goed ingelicht worden.

Kortom: Goed valideren voordat je data wegschrijft naar je database!!

**John Timmer** · 11-05-2012, 09:24

Origineel gepost door Arek van Schayk

Daar zit dus exact je denkfout! Data "presenteren" is een andere tak van sport als data "valideren". Je weet immers exact waar je data aan moet voldoen alvorens je het wegschrijft in de database. Lijkt me sterk dat jij deze validatie doet tijdens het lezen van de data.

SQL Injections en XSS staan op 1 en 2 in de OWASP top 10 webapplicatie kwetsbaarheden. Zorg dan tenminste dat programmeurs die zich melden met dit soort vragen goed ingelicht worden.

Kortom: Goed valideren voordat je data wegschrijft naar je database!!

Dude, chill... de grootste denkfout die je kunt maken is om zelf dingen aan te nemen die niet gezegd zijn of gespecificeerd. Ik geloof best wel dat je een beetje van programmeren weet en graag op je XSS fiets rondscheurd, maar waar wordt dat gevraagd?
Sterker nog... TS zijn code is 100% veilig (en hoogstwaarschijnlijk ook 100% fout trouwens) want zijn var kan op basis van zijn enkele regel slechts 2 waarden aannemen. En of je die in de db stopt of op je scherm gooit, maakt geen fluit uit. Je kunt niet eens met zekerheid zeggen dat TS die 'naam' überhaupt in de database wilt stoppen of tonen op dat moment.

TS probeert 3 dingen te doen met zijn variabele die gezamelijk een hoop overlappen, in de verkeerde context gebuikt worden, tegenstrijdig zijn en niet het gewenste effect effect zullen hebben... maar het is niet onveilig... het is gewoon fout...

In plaats van te proberen iedereen af te zeiken zou je als programmeur gewoon aan ts moeten vragen wat ie wil bereiken en hem op basis daarvan advies geven. En misschien kun je hem nog uitleggen wát ie fout doet.
Er zijn genoeg systemen (denk aan een willekeurig CMS) waarbij het toevoegen van html de normaalste zaak van de wereld is.

**Martijn L.** · 11-05-2012, 12:59

Origineel gepost door Arek van Schayk

Daar zit dus exact je denkfout! Data "presenteren" is een andere tak van sport als data "valideren". Je weet immers exact waar je data aan moet voldoen alvorens je het wegschrijft in de database. Lijkt me sterk dat jij deze validatie doet tijdens het lezen van de data.

SQL Injections en XSS staan op 1 en 2 in de OWASP top 10 webapplicatie kwetsbaarheden. Zorg dan tenminste dat programmeurs die zich melden met dit soort vragen goed ingelicht worden.

Kortom: Goed valideren voordat je data wegschrijft naar je database!!

Nee, dat weet je niet altijd. Je kunt het bijvoorbeeld weten bij een gebruikersnaam of iets dergelijks, maar bij tekst invoer? Nee.

Als je de string gaat filteren voor je hem in de database stopt raak je informatie kwijt. Besluit je later bijvoorbeeld dezelfde string terug te laten komen in een veilige output (textarea bijvoorbeeld) en hebt mogelijke XSS eruit gesloopt heb je het bericht kreupel gemaakt.

Het gaat hier om data. Aan data moet je niet klooien. Je moet het weergeven van data veilig maken. Dit moet je sowieso, want bij het parsen van je site moet je er vanuit gaan dat alle data, ook die uit je eigen script komt, onveilig is.

Het beste kun je alles in de database opslaan zoals je het binnen krijgt (tot een bepaalde hoogte) en zorgen dat de output in orde is. Niet dingen veilig wegschrijven in de database en klakkeloos printen naderhand. Er kan onderweg van de database naar de render engine nog vanalles mis gaan met de data.

**Joshua de Gier** · 11-05-2012, 13:05

Waar zit de 'ik vind dit leuk' knop voor John Timmer :-) Sinds wanneer heerst er een te hoog testosteron gehalte onder programmeurs? haha.

**John Timmer** · 11-05-2012, 13:42

Origineel gepost door Joshua de Gier

Waar zit de 'ik vind dit leuk' knop voor John Timmer :-) Sinds wanneer heerst er een te hoog testosteron gehalte onder programmeurs? haha.

Ach, zo is het ook niet bedoeld hoor.
Hij heeft gelijk dat je input uiteraard moet controleren (maar wel volgens de specs. want shit-in = shit-out tenslotte) maar je moet gewoon voorzichtig zijn met aannames want iedereen maakt fouten. De één vanwege gebrek aan kennis, de ander omdat ie teveel aanneemt.

code veilig maken