Odd Formatierung in SQL Injection Exploits?

Question

Ich habe versucht, mehr über SQL-Injection-Angriffe zu lernen. Ich verstehe das Prinzip, aber wenn ich mir einige dieser Angriffe ansehe, weiß ich nicht, wie sie das machen, was sie tun.

Es scheint oft zu ungleichmäßigen Anführungszeichen zu kommen, und viele Verschleierung über HEX-Zeichen.

Ich bekomme nicht die HEX-Zeichen ..., sicherlich werden sie vom Browser zurück in ASCII übersetzt, was ist der Sinn?

Allerdings bin ich vor allem durch die ungeraden Zitate verwirrt. Ich habe momentan Schwierigkeiten, ein Beispiel zu finden, aber normalerweise scheint das Zitat irgendwann vor dem Ende der Aussage zu enden, wenn ich gedacht hätte, es wäre am Ende?

Vielleicht ein Beispiel ist die gemeinsame Verwendung von ‚1 oder 1 = 1

Was ist eine solche Aussage zu tun?

Answer 1

ich die HEX-Zeichen nicht ... erhalten, sicher sie werden zurück an ASCII vom Browser

Nope übersetzt.

Allerdings bin ich vor allem durch die ungerade Quote verwirrt. Ich habe Probleme finden Sie ein Beispiel, aber es scheint in der Regel, dass die Quotierung wird Ende irgendwann vor dem Ende der die Aussage, wenn ich hätte dachte, es wäre am Ende?

Stellen Sie sich vor, Sie bauen Inline-SQL, anstatt die Parametersubstitution zu verwenden, wie Sie sollten. Wir verwenden eine erfundene Sprache, die PHP ohne besonderen Grund ähnelt.

$sql = "delete from foo where bar = '" + $param + "'"; 

So, jetzt vorstellen, dass $param vom Browser als solche gesetzt wird ...

$param = "' or 1=1 --" 

(Wir vorgeben, wie -- ist hier die SQL-Kommentarsequenz. Wenn es Möglichkeiten, ist nicht, dass es um das auch)

Also, jetzt, was ist Ihr SQL nach der Zeichenfolge Ersetzung erfolgt ist?

delete from foo where bar = '' or 1=1 --' 

Das löscht jeden Datensatz in foo.

Dies war absichtlich einfach, aber es sollte Ihnen eine gute Idee geben, wofür die ungeraden Zitate sind.

Answer 2

Nehmen wir an, wir haben ein Formular, wo wir ein Formular mit einem Namensfeld senden. Name wurde in einer Variablen $ Name verwendet.Sie führen dann diese Abfrage:

INSERT INTO Students VALUES ('Robert'); DROP TABLE STUDENTS; --') 

Das - ist ein Kommentarzeichen:

INSERT INTO Students VALUES ('$Name') 

Es wird in übersetzt werden. Danach wird alles ignoriert. Das 'wird verwendet, um String-Literale zu begrenzen.

Die Verwendung von Hex-Zeichen in einem Angriff hat einige Gründe. Eine davon ist die Verschleierung, eine andere um naive Sicherheitsmaßnahmen zu umgehen.

Answer 3

Wie für die ungleiche Notierung; SQL-Injection tritt auf, wenn der Codierer nicht Benutzereingabe für gefährliche Zeichen wie einfache Anführungszeichen sanieren - betrachten folgende Anweisung

SELECT * FROM admin WHERE username='$_GET["user"]' and password='$_GET["pass"]' 

, wenn ich weiß, dass gültige Benutzer ‚admin‘ und legen Sie die 'or 1=1 ich folgendes erhalten wird

SELECT * FROM admin WHERE username='admin' and password='something' or 1=1 

Diese die Abfrage alle Tage wahr bei der Rückkehr zur Folge haben wird, weil die linke Seite des Ausdrucks immer wahr sein wird, unabhängig vom Wert des Passworts.

Dies ist das einfachste Beispiel für SQL-Injection und ofter Sie werden feststellen, dass der Angreifer mit Kommentaren nicht den Rest der Abfrage heraus verwenden müssen, um das Angebot an alle, oder vielleicht Kommentar Trennzeichen wie -- oder /* , wenn nach dem Injektionspunkt mehr Parameter übergeben werden. Die HEX-Codierung kann verschiedene Ursachen haben, die Filterung zu vermeiden. Es ist einfacher, hexadezimale Werte zu verwenden, weil Sie sich nicht darum kümmern müssen, alle Ihre Werte in einer Abfrage zu zitieren. Dies ist zum Beispiel nützlich, wenn Sie concat zusammen notate zwei Felder zusammen, wie so verwenden möchten:

inject.php?id=1 and 1=0 union select 1,2,concat(username,0x3a3a,password) from admin 

Welche 3. Reihe bieten würde, ist sichtbar eine Rückkehr für isntance admin::admin. Wenn ich nicht Hex-Codierung verwenden würde, würde ich dies tun:

inject.php?id=1 and 1=0 union select 1,2,concat(username,'::',password) from admin 

Dieses Problem könnte mit vorgenannten addslashes Funktion, sondern auch mit schlecht regex sanitization Funktionen geschrieben oder wenn Sie sehr komplizierte Frage haben.

SQL-Injektion ist ein sehr breites Thema, und was ich behandelt habe, ist kaum eine Einführung durch.

Answer 4

Es gibt Fälle, in denen Zitatmarken mit SQL-Injektion verboten sind. In diesem Fall muss ein Angreifer eine Codierungsmethode verwenden, beispielsweise eine Hex-Codierung für seine Strings. Zum Beispiel '/etc/passwd' kann als 0x2f6574632f706173737764 geschrieben werden, die keine Anführungszeichen erfordert. Hier ist ein Beispiel für eine anfällige Abfrage, bei der Anführungszeichen verboten sind. :

mysql_query("select name from users where id=".addslashes($_GET[id]));

Wenn Sie eine MySQL-Funktion wie load_file() verwenden möchten, dann müssen Sie Hex-Codierung verwenden.

PoC: /vuln.php?id=1 union select load_file(0x2f6574632f706173737764)

In diesem Fall/etc/passwd gelesen wird und die zweite Reihe sein.Hier

ist eine Variation der Hex-Codierungsfunktion, die ich in meiner MySQL SQL-Injection-Angriffe verwenden:

function charEncode($string){ 
    $char="char("; 
    $size=strlen($string); 
    for($x=0;$x<$size;$x++){ 
     $char.=ord($string[$x]).","; 
    } 
    $char[strlen($char)-1]=")%00"; 
    return $char; 
} 

Ich benutze diese genaue Methode für exploiting HLStats 1.35. Ich habe auch diese Funktion in meinem php nuke exploit verwendet, um XSS-Filter zu umgehen, um <?php?> mit into outfile auf die Festplatte zu schreiben. Es ist wichtig zu beachten, dass into outfile ein Abfrageoperator ist, der die Ausgabe an eine Funktion oder eine hexadezimale Zeichenfolge nicht akzeptiert. Es wird nur eine Zeichenfolge in Anführungszeichen als Pfad akzeptiert. Daher kann die angreifbare Abfrage über into outfile nicht von einem Angreifer verwendet werden. Wobei als load_file() ein Funktionsaufruf und eine Hex-Codierung verwendet werden kann.