SQL Die Injektion ist eine der häufigsten Schwachstellen in PHP-Anwendungen. Tatsächlich ist es erstaunlich, dass ein Entwickler zwei Fehler gleichzeitig machen muss, um eine SQL-Injection-Schwachstelle auszulösen. Der eine filtert nicht die Eingabedaten (Filterung der Eingabe) und der andere filtert nicht die an die Datenbank gesendeten Daten . Escape (Escape-Ausgabe). Diese beiden wichtigen Schritte sind unverzichtbar und erfordern besondere Aufmerksamkeit, um Programmfehler zu reduzieren.
Für Angreifer erfordert die Durchführung von SQL-Injection-Angriffen Nachdenken und Experimentieren, und es ist sehr wichtig, fundierte Überlegungen zur Datenbanklösung anzustellen (vorausgesetzt natürlich, dass der Angreifer Ihr Quellprogramm und Ihre Datenbanklösung nicht sehen kann). Betrachten Sie das folgende einfache Anmeldeformular :
CODE:
<form action="/login.php" method="POST"> <p>Username: <input type="text" name="username" /></p> <p>Password: <input type="password" name="password" /></p> <p><input type="submit" value="Log In" /></p> </form>
Abbildung 3-1 zeigt die Darstellung dieses Formulars im Browser.
Als Angreifer würde er zunächst über eine Abfrage spekulieren, um den Benutzernamen und das Passwort zu überprüfen. Durch einen Blick auf die Quelldateien kann er beginnen, Ihre Gewohnheiten zu erraten.
Abbildung 3-1.Anzeige des Anmeldeformulars im Browser
Namenskonvention. Normalerweise wird davon ausgegangen, dass die Feldnamen in Ihrem Formular mit den Feldnamen in der Datentabelle übereinstimmen. Natürlich ist die Sicherstellung, dass sie unterschiedlich sind, nicht unbedingt eine zuverlässige Sicherheitsmaßnahme.
Für die erste Vermutung verwenden Sie im Allgemeinen die Abfrage im folgenden Beispiel:
CODE:
<?php $password_hash = md5($_POST['password']); $sql = "SELECT count(*) FROM users WHERE username = '{$_POST['username']}' AND password = '$password_hash'"; ?>
Die Verwendung des MD5-Werts des Benutzerpassworts war ursprünglich eine gängige Praxis, aber jetzt Es ist nichts Besonderes. Es ist sicher. Aktuelle Untersuchungen zeigen, dass der MD5-Algorithmus fehlerhaft ist und die große Anzahl von MD5-Datenbanken die Schwierigkeit des MD5-Reverse-Crackings verringert. Bitte besuchen Sie //m.sbmmt.com/ Schauen Sie sich die Demo an.
Anmerkung zur Übersetzung: Dies ist der Originaltext von Wang Xiaoyun, einem Professor an der Shandong-Universität, der zeigt, dass MD5-„Kollisionen“ schnell gefunden werden können, d. h. zwei verschiedene Dateien und Zeichenfolgen, die denselben MD5-Wert erzeugen können. MD5 ist ein Information Digest-Algorithmus, kein Verschlüsselungsalgorithmus, daher kommt Reverse Cracking nicht in Frage. Diesem Ergebnis zufolge ist es jedoch im oben genannten Sonderfall gefährlich, MD5 direkt zu verwenden.
Die beste Schutzmethode besteht darin, eine selbst definierte Zeichenfolge an das Passwort anzuhängen, zum Beispiel:
CODE:
<?php $salt = 'SHIFLETT'; $password_hash = md5($salt . md5($_POST['password'] . $salt)); ?>
Natürlich kann es sein, dass Angreifer es beim ersten Mal nicht richtig hinbekommen und oft müssen sie ein wenig experimentieren. Eine bessere Möglichkeit zum Experimentieren besteht darin, einfache Anführungszeichen als Benutzernamen einzugeben, da dadurch möglicherweise wichtige Informationen preisgegeben werden. Viele Entwickler rufen die Funktion mysql_error() auf, um den Fehler zu melden, wenn während der Ausführung einer MySQL-Anweisung ein Fehler auftritt. Siehe das Beispiel unten:
CODE:
<?php mysql_query($sql) or exit(mysql_error()); ?>
Obwohl diese Methode in der Entwicklung nützlich ist, kann sie einem Angreifer wichtige Informationen preisgeben. Wenn der Angreifer einfache Anführungszeichen als Benutzernamen und mypass als Passwort verwendet, lautet die Abfrageanweisung:
CODE:
<?php $sql = "SELECT * FROM users WHERE username = ''' AND password = 'a029d0df84eb5549c641e04a9ef389e5'"; ?>
Wenn die Anweisung an MySQL gesendet wird, zeigt das System die folgende Fehlermeldung an:
You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near 'WHERE username = ''' AND password = 'a029d0df84eb55
Ohne Aufwand kennt der Angreifer bereits die beiden Feldnamen (Benutzername und Passwort) und die Reihenfolge, in der sie in der Abfrage erscheinen. Darüber hinaus weiß der Angreifer auch, dass die Daten nicht korrekt gefiltert (das Programm fordert keine illegalen Benutzernamen auf) und maskiert werden (ein Datenbankfehler tritt auf), und auch das Format der gesamten WHERE-Bedingung wird offengelegt, sodass der Angreifer dies tun kann Versuchen Sie zu manipulieren. Es gibt Datensätze, die mit der Abfrage übereinstimmen.
An diesem Punkt hat der Angreifer viele Möglichkeiten. Eine besteht darin, zu versuchen, einen speziellen Benutzernamen einzugeben, damit die Abfrage unabhängig davon, ob Benutzername und Passwort übereinstimmen, abgeglichen wird:
myuser' or 'foo' = 'foo' --
假定将mypass作为密码,整个查询就会变成:
CODE:
<?php $sql = "SELECT * FROM users WHERE username = 'myuser' or 'foo' = 'foo' -- AND password = 'a029d0df84eb5549c641e04a9ef389e5'"; ?>
由于中间插入了一个SQL注释标记,所以查询语句会在此中断。这就允许了一个攻击者在不知道任何合法用户名和密码的情况下登录。
如果知道合法的用户名,攻击者就可以该用户(如chris)身份登录:
chris' --
只要chris是合法的用户名,攻击者就可以控制该帐号。原因是查询变成了下面的样子:
CODE:
<?php $sql = "SELECT * FROM users WHERE username = 'chris' -- AND password = 'a029d0df84eb5549c641e04a9ef389e5'"; ?>
幸运的是,SQL注入是很容易避免的。正如第一章所提及的,你必须坚持过滤输入和转义输出。
虽然两个步骤都不能省略,但只要实现其中的一个就能消除大多数的SQL注入风险。如果你只是过滤输入而没有转义输出,你很可能会遇到数据库错误(合法的数据也可能影响SQL查询的正确格式),但这也不可靠,合法的数据还可能改变SQL语句的行为。另一方面,如果你转义了输出,而没有过滤输入,就能保证数据不会影响SQL语句的格式,同时也防止了多种常见SQL注入攻击的方法。
当然,还是要坚持同时使用这两个步骤。过滤输入的方式完全取决于输入数据的类型(见第一章的示例),但转义用于向数据库发送的输出数据只要使用同一个函数即可。对于MySQL用户,可以使用函数mysql_real_escape_string( ):
CODE:
<?php $clean = array(); $mysql = array(); $clean['last_name'] = "O'Reilly"; $mysql['last_name'] = mysql_real_escape_string($clean['last_name']); $sql = "INSERT INTO user (last_name) VALUES ('{$mysql['last_name']}')"; ?>
尽量使用为你的数据库设计的转义函数。如果没有,使用函数addslashes( )是最终的比较好的方法。
当所有用于建立一个SQL语句的数据被正确过滤和转义时,实际上也就避免了SQL注入的风险。
CODE:
如果你正在使用支持参数化查询语句和占位符的数据库操作类(如PEAR::DB, PDO等),你就会多得到一层保护。见下面的使用PEAR::DB的例子:
CODE:
<?php $sql = 'INSERT INTO user (last_name) VALUES (?)'; $dbh->query($sql, array($clean['last_name'])); ?>
CODE:
由于在上例中数据不能直接影响查询语句的格式,SQL注入的风险就降低了。PEAR::DB会自动根据你的数据库的要求进行转义,所以你只需要过滤输出即可。
如果你正在使用参数化查询语句,输入的内容就只会作为数据来处理。这样就没有必要进行转义了,尽管你可能认为这是必要的一步(如果你希望坚持转义输出习惯的话)。实际上,这时是否转义基本上不会产生影响,因为这时没有特殊字符需要转换。在防止SQL注入这一点上,参数化查询语句为你的程序提供了强大的保护。
译注:关于SQL注入,不得不说的是现在大多虚拟主机都会把magic_quotes_gpc选项打开,在这种情况下所有的客户端GET和POST的数据都会自动进行addslashes处理,所以此时对字符串值的SQL注入是不可行的,但要防止对数字值的SQL注入,如用intval()等函数进行处理。但如果你编写的是通用软件,则需要读取服务器的magic_quotes_gpc后进行相应处理。
以上就是PHP安全-SQL 注入的内容,更多相关内容请关注PHP中文网(m.sbmmt.com)!