Tijden veranderen
mysql inject
dus ik ben bezig met een registratie formuliertje te maken,
mijn vorige, was niet bestend tegen mysql inject,
nu is mijn vraag: is dit goed genoeg?
$gebruikersnaam = mysql_real_escape_string($_POST['gebruikersnaam']);
$email = mysql_real_escape_string($_POST['email']);
$email2 = mysql_real_escape_string($_POST['email2']);
$referral = mysql_real_escape_string($_POST['referral']);
Je maakt nu overbodige variabelen aan.
Je kan beter de $_POST variabelen meteen in je query zetten.
Scheelt een berg debuggen als je er een verkeerd tikt. :P
Dus:
Code (php)
1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
<?php
$result = "INSERT INTO blaat(gebruikersnaan,
email
)
VALUES('".mysql_real_escape_string($_POST['gebruikersnaam'])."',
'".mysql_real_escape_string($_POST['email']).'")
";
?>
$result = "INSERT INTO blaat(gebruikersnaan,
)
VALUES('".mysql_real_escape_string($_POST['gebruikersnaam'])."',
'".mysql_real_escape_string($_POST['email']).'")
";
?>
enz..
Ik zou de tip (persoonlijk) van Bart opvolgen, maar zoals je het nu hebt is het voor zo ver ik weet redelijk veilig tegen mysql injecties.
De tip van Bart is voor minder type werk etc. maar 't hoeft niet (voor als je dat prettiger vind).
toch bedankt :)
Zolang je zelf maar snapt wat je aan 't doen bent.
Stefan iemand op 29/07/2011 19:01:37:
maar ik ben php aan het leren, en ik vind dat dit het overzichtelijker maakt
toch bedankt :)
toch bedankt :)
Dat vind ik dus juist niet. Jij maakt nieuwe $vars aan waarvan niet duidelijk is of deze veilige inhoud hebben of niet. Bij $_POST-vars weet je dat die niet veilig zijn. Dat geeft mijns inziens duidelijkheid. Gebruik gewoon de mysql_real_escape_string() direct in de query om de $_POST-vars te beveiligen. Je ziet dan precies wat je aan het doen bent. Lijkt mij het meest overzichtelijk.
Stefan iemand op 29/07/2011 19:01:37:
maar ik ben php aan het leren, en ik vind dat dit het overzichtelijker maakt
toch bedankt :)
toch bedankt :)
uiteraard staat het vrij om te het op die manier te doen.
Maar als je applicatie wat groter word, dan word het al een stuk lastiger.
Stefan iemand op 29/07/2011 19:01:37:
maar ik ben php aan het leren, en ik vind dat dit het overzichtelijker maakt
toch bedankt :)
toch bedankt :)
Lijkt me juist dat je dan alle tips die je krijgt ter harte neemt en je dingen gelijk goed aanleert. ;)
- SanThe - op 29/07/2011 19:49:19:
@The Force: Kan je daar wat meer over vertellen? Voorbeeldje misschien?
Er zijn allerlei manieren om XSS aanvallen te plegen. XSS staat voor Cross Site Scripting (de X omdat het onderscheid te kunnen maken tussen Cascading Style Sheets en deze vorm van aanvallen). Wat er in feite gebeurd is dat de aanvaller code op de website kan uitvoeren. Daardoor kan hij gegevens als de session ID stelen (omdat de code uitgevoerd wordt op het domein van de website die aangevallen wordt).
Stel je hebt een gastenboek en een gebruiker vult het volgende in:
Code (php)
1
2
3
2
3
<script type="text/javascript">
alert("XSS");
</script>
alert("XSS");
</script>
Je doet daar vervolgens mysql_real_escape_string overheen zodat je dat netjes in de database kan opslaan. Maar als je vervolgens alle gastenboekberichten op de website weergeeft dan wordt deze code gewoon uitgevoerd. Er zijn honderden manieren om een XSS aanval te plegen (zie http://ha.ckers.org/xss.html voor een overzicht).
Met XSS kan je sessies van mensen stelen (door de cookie met het sessie id via javascript op te vragen. Als die sessie id in zijn cookie plaatst dan is hij plots ingelogd. Je hebt (omdat je met javascript de DOM kan bewerken) oneindig veel mogelijkheden om de website zo aan te passen als je wilt. Je zou een inlogform kunnen toevoegen aan de website, enzovoorts. Dat overkwam ook de IB groep: http://www.automatiseringgids.nl/it-in-bedrijf/beheer/2011/23/opnieuw-lek-in-site-studiefinanciering.aspx .
Leesvoer: hier is een XSS cheat sheet: https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
Wat kan je er tegen doen? Je kan alle tags strippen (met strip_tags) of tekens vervangen door HTML entities (htmlentities). Je ontneemt alleen de gebruiker de mogelijkheid om via HTML een plaatje in hun gastenboekbericht te zetten. Je kan bij strip_tags wel aangeven dat 'img' wel toegestaan is, maar dat maakt je website weer gevoelig voor een aanval als deze:
Code (php)
1
<img src="javascript:alert('onveilig!');">
Gebruik van strip_tags is dus enkel veilig als je de gebruiker normale tekst wilt laten schrijven of een beperkt aantal HTML tags wil toestaan. Tags als '<b>', '<i>' en '<u>' zijn uiteraard niet gevoelig voor XSS. htmlentities voorkomt het gebruik van alle HTML (maar zet deze om in veilige tekens inplaats van dat het deze weghaalt). Een andere optie is BB code maar die kan (indien niet goed gefilterd) ook met XSS aangevallen worden:
Code (php)
1
[img]http://badwebsite.com/xss.js[/img]
Je kan tot slot een XSS filter gebruiken om XSS tegen te gaan en tegelijkertijd de gebruiker in staat te stellen alle HTML te gebruiken zolang deze niet als verdacht aangemerkt wordt.
Edit: strip_tags schijnt niet alle vormen van XSS tegen te gaan. Zie http://htmlpurifier.org/comparison#striptags
Gewijzigd op 29/07/2011 23:49:13 door The Force
See You.
vb:
Code (php)
Maar goed, dat gaat misschien voor de TS nog even te ver.
Wat leesvoer, om inspiratie op te doen voor invoer validatie:
http://id2.php.net/manual/en/book.filter.php
Als je in een script veel queries uitvoert of als je zeer lange queries nodig hebt, is het vaak al lastig genoeg om dat overzichtelijk in de code weg te schrijven. Het meerdere malen extra toevoegen van mysql_real_escape_string() functies in de queries komt overzichtelijkheid dan absoluut niet ten goede. Bovendien zou je de functie wel eens overbodig vaak nodig kunnen hebben als je dezelfde variabele in meerdere queries gebruikt.
Mijn redenatie is dan ook altijd dat $_POST, $_GET, $_COOKIE en (sommige) $_SERVER variabelen per definitie niet veilig zijn voor gebruik in een query. Variabelen die ik in mijn script zelf een naam gegeven heb, zijn dan per definitie wel. Op die manier weet ik zeker dat variabelen die ik gebruik in een query geen mogelijkheid tot sql injectie opleveren. En op deze manier weet ik ook zeker dat mijn queries overzichtelijk(er) blijven en ik mysql_real_escape_string() nooit dubbel gebruik...
Om antwoord te geven op de vraag van de TS: houd het volgende in gedachte:
- Voor invoer in de database is het gebruik van mysql_real_escape_string() over variabelen voldoende. Andere functies heb je niet nodig.
- Bij het genereren van output moet je nadenken over het formaat waar het in komt te staan, afhankelijk daarvan zul je functies als htmlentities(), nl2br(), etc. willen gebruiken.
Tenslotte, wil je hier helemaal niet meer over na hoeven te denken, kijk dan eens naar het gebruik van prepared statements bij het gebruik van PDO...