Einstellung für AND bei Übergabe

B

blobbo

0
Sorry für den blöden Titel aber ich wusste nicht wie ich es besser umschreiben soll -.-

Ich hab bei Milworm ein Video gesehn wo es ausgenutzt wird, dass in einem php script eine variable direkt an mysql übergeben wird (http://www.milw0rm.com/video/?start=30 - Demonstration of Blind MySQL Injection (mysql_bftools)).
und zwar so:
test.php?var=1

und im script:

SELECT bla FROM bla WHERE id='$var';

So.. wenn man nun ' eingibt passiert nichts, da vorher ein / angehängt wird.
Doch dort ist es möglich "1 and 1=0" zu übergeben und dadurch ist es nun möglich an die Daten der Datenbank zu kommen.
So nun meine Fragen:

Was muss ich bei apache oder sonstwo einstellen damit diese Sicherheitslücke besteht. Weder bei den bekannten freewebspaceanbietern noch bei xampp funktioniert es von hause aus.
Und wie funktioniert dann eigentlich das Programm. Also wie kommt es an die Daten.

Danke schonmal =)
 
Original von blobbo
Weder bei den bekannten freewebspaceanbietern noch bei xampp funktioniert es von hause aus.
Zum Vergrößern anklicken....
Naja, ganz blöd sind Webspaceanbieter eben auch nicht. Wenn es eine Möglichkeit gibt, den Usern was abzunehmen, was sowieso die wenigsten machen (nämlich Usereingaben zu escapen), dann wird die eben auch genutzt. Im Falle von PHP heißt das ganze dann magic_quotes_gpc. Und diese Einstellung ist glücklicherweise auch per Default aktiviert.
 
mh ok danke erstmal :)

Aber ein paar Fragen hab ich nur ^^ ..

Und zwar wenn das standartmäßig aus ist warum soll das dann ein bug sein?
Also ob das jemand der halbwegs bei Verstand ist extra anschaltet!?

Und hab ich Blind Injection richtig verstanden (http://www.owasp.org/index.php/Testing_for_MySQL#Blind_SQL_Injection)?
Also ich verstehe es so.. man weiss ja, dass zB bei id=1 der Name "Peter" kommt.
Darum kann man jetzt irgendwie mit ?id=1 and blabla etwas ausführen.
Für blabla macht man nun SUBSTRING. Damit kann man von einem String nur Abschnitte nehmen, diese vergleichen und sich somit langsam an den gesuchten Wert "rantasten".
Aber was ich nun nicht verstehe ist:
Angenommen ich suche das Passwort "TEST"
Jetzt fange ich an und vergleiche mit hilfe von SUBSTRING nur das erste Zeichen.
Warum wird nun wie ich oben beschrieben habe, wenn das zeichen stimmt, "Peter" weiterhin angezeigt und wenn es nicht stimmt nicht?

Ja also soweit habe ich das verstanden.

Falls ich mich unklar ausgedrückt habe tuts mir leid ;(


[edit]
Ah und ich seh gerade magic_quotes sind ja nur der Grund für die \' aber nicht warum ich nicht etwas mit id=1 and blabla übergeben kann.
 
Original von blobbo
magic_quotes sind ja nur der Grund für die \' aber nicht warum ich nicht etwas mit id=1 and blabla übergeben kann.
Zum Vergrößern anklicken....
Richtig, magic_quotes_gpc sorgt nur dafür, dass Quotes in den übergebenen Variablen maskiert werden. Dadurch können schonmal eine ganze Menge von Lücken eliminiert werden. Haarig wird's dann, wenn du ein SQL-Statement hast, in dem du mit Integern und ohne Quotes arbeitest, z.B.

Code: 
SELECT * FROM tabelle WHERE id=$wert;
Hier kann $wert natürlich eine ganze Menge sein, weswegen man um die Sicherheit seines Codes zu gewährleisten entweder das SQL-Statement umformt zu

Code: 
SELECT * FROM tabelle WHERE id='$wert';
und dann entsprechend Quotes maskiert, oder indem man bei $wert dafür sorgt, dass da wirklich nur ein Integer drin steht:

PHP: 
$wert = intval ( $wert );
 
Ah ich bin eben aufgewacht und weiss jetzt wies funktioniert :D

Und zwar wird ja wenn ich "id=1 and 1=0" der eintrag nicht angezeigt, bei "id=1 and 1=1" zb allerdings schon.
Und so kann man ja dann mit Substring einfach alles durchprobieren und gucken ob der Eintragn also zB "Peter" angezeigt wird.
Warum ich da nicht früher drauf gekommen bin ;(

So jetzt wüsste ich nur noch gerne was ich einstellen muss um diesen "and-bug" wieder zum leben zu erwecken. Mir ist gerade eingefallen ob es nicht vielleicht an der version liegt!?
Aber irgendwie müsste man das doch wieder einstellen können!?

thx!
 
Diese Vulnerability ist seit einigen Monaten bekannt.

Aber ein guter Programmierer wird sicher nicht zulassen, das zu verarbeitende Daten unkontrolliert auf sein Script einwirken können.

Zugriff auf eine Datenbank anhand einer frei einsetzbaren Variablen - meiomei, na gute Nacht um sechse *g

Ernsthaft, jede - wirklich JEDE Eingabe, die der Benutzer machen kann, also nicht eine im Script gesetzte "Vorauswahl", muss überprüft werden. Wer es anders macht, macht es falsch. Da niemals alle möglichen Eingaben gültig sind, gibt es de fakto eine begrenzte Auswahl an Eingabemöglichkeiten. Neben der Typenprüfung kannst du auch mit Regexpression arbeiten, wenn du beispielsweise verschiedene Datentypen zuläßt.

Ich programmiere seit vielen Jahren, 20 an der Zahl und mache auch sehr viel mit Datenbanken - glaub mir, die Eingabe wie von dir geschrieben ist für mich niemals nötig gewesen.

Aber du hast recht, diese "Lücke" existiert.

Ein ähnlicher Gag ist auch das Aufkommen der sogenannten WYSIWYG-Editoren. Bei knapp der Hälfte schaffe ich es, ein Script auf dem Server zu speichern, das dem Besitzer eine Email sendet, die ihn hoffentlich sehr erschreckt.

Oder dieses Gimmick mit der Seitenübergabe index.php?page=blablubb.php - wenn du so eine Seite (oft auch für Framesets genutzt) siehst, ersetze mal blablubb durch eine URL mit http - du wirst erblassen, wie oft sich da eigene Seiten in fremde Inhalte einbetten lassen. Das ist jetzt kein Problem für den Server selbst, da du nach wie vor keinen Zugriff erhälst, aber ein großer Pharma-Konzern war doch etwas verblüfft, als seine Homepage mit dem Inhalt FUCK BUSH und einer (wie ich finde ansprechenden) Karrikatur dieses Menschen publiziert wurde. Sowas kann ein nicht unerheblicher Imageschaden sein, denn die Besucher des Links wissen nicht um die Umstände - und einmal in Verruf.....

Also, Quintessenz - wenn Du Variablen übergeben willst, mach das mit einer Session oder triff eine Vorauswahl - geht beides nicht, beschränke die Möglichkeiten auf das mindestmass, die du dem User zugestehst

Achja, eines noch - ich weiß wie man das "einstellt", aber das werde ich nicht veröffentlichen
 
^^ ok danke dir erstmal.

Warum willst du das nicht veröffentlichten? =)
So wie ich das bis jetzt verstanden habe ist es doch so, dass unter normalen Umständen bzw. mit einer aktuellen Version diese "Lücke" gar nicht existiert.
Damit verbreitest du ja auch keinen Schaden wenn du sagst wie man sie dann wieder einstellt.
Also soweit ich das jetzt verstanden habe funktioniert diese "Lücke" dann, wenn ich SELECT bla WHERE bla=$var mache anstelle von WHERE bla='$bla' (man beachte die ' ;) )
Aber ich kann mich auch irren habs noch nich getestet ;p
Und das mit site=index.php oder so kenn ich das is ganz lustig teilweise ;D
heisst doch glaub ich remote file include soweit ich weiss =)

Naja danke dir also ich glaub ich hab soweit den blind sql include verstanden aber ich freue mich natürlich weiterhin über alles =)
 
Solange man von außen keinen Zugriff auf die php.ini hat, hilft einem das Wissen darum, wie man es "einstellt" herzlich wenig. Zudem sind die wichtigsten Punkte hier eh schon genannt ;)

Entweder ist ein Skript schlampig programmiert - und dann helfen zuweilen nicht mal die PHP-Defaulteinstellungen was, die übrigens nicht immer mit Blick auf die Sicherheit gesetzt sind (z.B. register_globals oder allow_url_fopen) - oder es ist sicher, unabhängig von den PHP-Settings.
 
Jo seh ich auch so =)

Und es lag tatsächlich an den ' ' .
Wenn diese bei "SELECT bla WHERE id=$var" um $var nicht gesetzt sind ist es möglich per blind sql injection and die Daten in der Datenbank zu kommen auch wenn übergebende ' maskiert werden ;)
Aber so wirklich schlimm finde ich das irgendwie auch nicht solange man sichere Passwörter benutzt ;)
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben