Beste leden,

Als ik bv een $_GET['x'] heb en die selecteer bv dit:
mysql_query("SELECT * FROM `[clans]` WHERE `name`='". $_GET['x'] ."'");

Welke data zouden ze hiermee los kunnen krijgen?
En wie weet hoe dat dan moet doen om data te verkrijgen/errors.

Zoals jij het hier beschrijft is het mogelijk om de hele inhoud van de tabel clans uit te lezen.

SELECT * FROM '[clans]' WHERE name = 'variabelex OR 'test' = 'test'

Als je het vetgedrukte toevoegd dan zal het altijd true opleveren en wordt de hele inhoud getoond. Je zult altijd goed de $_GET variabelen moeten controleren op ongeldige tekens.

Volgens mij kan de _GET zo bewerkt worden dat je tabel gedropt wordt.

$x = mysql_real_escape_string($_GET['x']);
mysql_query("SELECT * FROM `[clans]` WHERE `name`='". $x ."'");

nu kunnen ze geen sql injection meer doen

Het is de bedoeling dat het wel mogenlijk is via een url dat ik dit kan testen.

Iemand interesse in het zoeken van sql injections in mijn script, per werkende injection betaal ik een bedrag. Bedrag ter overeenkomst.

Je bespaard je meer geld als je overal waar je een $_GET[] waarde in een mysql_query gebruikt hier alleen: mysql_real_escape_string() omheen te zetten, dan is hij al beveiligd tegen injecties.

wat staat het script?

En als ik dat bij elke query doe? Heeft dat nadelige gevolgen? Ik heb een mysql class dus dat zou ik er zo omheen kunnen bouwen en dan zou ik veilig moeten zijn?

In het voorbeeld zal er waarschijnlijk niet veel fout kunnen, aangezien je de waarde tussen ' en ' hebt staan. Op de meeste servers staat magic_quotes on, dus worden ' en " "geescaped". In dat geval kun je dus NIET 1' OR 1=1 /* toevoegen, aangezien je dan WHERE `name` = '`\'OR 1=1/*' krijgt.

*Laat Maar*

htmlspecialchars slashes en intval anyone ??

Deze tutorial is misschien handig voor enkele onder ons:

http://www.phphulp.nl/php/tutorials/3/244/

Origineel gepost door J. Peters

In het voorbeeld zal er waarschijnlijk niet veel fout kunnen, aangezien je de waarde tussen ' en ' hebt staan. Op de meeste servers staat magic_quotes on, dus worden ' en " "geescaped". In dat geval kun je dus NIET 1' OR 1=1 /* toevoegen, aangezien je dan WHERE `name` = '`\'OR 1=1/*' krijgt.

Al zou ik daar toch maar gewoon het standaard erin bouwen een addslashje of een mysql_real_escape_string, aangezien vanaf php 6 namelijk de magic_quotes standaard uit zullen staan.

Ik zou op deze code zo tientallen verschillende SQL injections kunnen toepassen. Van het droppen van een tabel, tot het totaal veranderen van allerlei data, tot het veranderen van je MySQL password, en in veel gevallen tot het droppen en maken van databases, het aanpassen van toegangsdata, etc.

Voor mij zou het geen probleem zijn om ze allemaal te exploiteren, mits je magic_quotes uit hebt staan, want dat lost veel problemen op. Dat neemt niet weg dat je nooit zomaar raw input in je SQL moet stoppen, want dat open gegarandeerd veel lekken, waaronder XSS (zie onder).

Verder zijn de magic_quotes of addslashes() zeker niet genoeg. Er zijn genoeg exploits te verzinnen om dit te omzeilen. Dit heeft te maken met encoding van karakters (bijvoorbeeld een " in UTF-8 word toch door veel MySQL's opgepikt als een end-of-query karakter). Gebruik dus voor SQL escaping altijd de functie die bij de database server past. Dus in het geval van MySQL is dat mysql_real_escape_string. Let op de real want deze zorgt ervoor dat de escaping wordt gebaseerd op de configuratie van MySQL.

Wanneer je alleen magic_quotes/addslashes/mysql_real_escape_string gebruikt om je SQL te beveiligen is dit nog steeds zeker niet voldoende. Door middel van UPDATE's en INSERT's kan een kwaadwillende gebruiker allerlei data toevoegen aan de database. Wanneer je deze data zonder htmlentities() output (wat gegarandeerd wel eens gebeurt) heb je daar weer een gigantisch XSS (Cross Site Scripting) lek. Als er XSS lekken in je normale pagina's (zichtbaar voor de bezoeker) zitten, kan de aanvaller dus javascript, java, ActiveX uitvoeren op jouw website. Als het lek ook in de admin interface zit wordt het nog veel erger, de javascript van de aanvaller kan dan bijvoorbeeld het wachtwoord veranderen van de ingelogde gebruiker en het naar een webserver van de aanvaller sturen.

Origineel gepost door ramon fincken

htmlspecialchars slashes en intval anyone ??

htmlspecialchars: Theoretisch wel, aangezien ook quotes (") door deze functie worden geescaped, maar wel naar html codes. Hierdoor krijg je dus allerlei HTML escape codes in je DB, en als je dat weer escaped tijdens een output krijg je dubbele escaping waardoor mensen bijvoorbeeld " zien als ze je pagina bezoeken.

intval: Deze is zeker heel erg waterdicht, maar je krijgt er natuurlijk altijd een integer uit.

* amen :)

intvals zijn erg mooi en je kan er ook nog fijne urls mee maken :
site.nl/c49/fietsen/
mod rewrite c[getal] => site.nl/categorie.php?cat_id=$1
$1 = 49 in dit geval :)