PHP 보안-SQL 주입

SQL 주입

SQL 주입은 PHP 애플리케이션에서 가장 일반적인 취약점 중 하나입니다. 실제로 개발자가 SQL 주입 취약점을 유발하기 위해 동시에 두 가지 실수를 해야 한다는 것은 놀라운 일입니다. 하나는 입력 데이터를 필터링하지 않는 것이고(입력을 필터링하는 것), 다른 하나는 데이터베이스로 전송되는 데이터를 필터링하지 않는 것입니다. . 이스케이프(이스케이프 출력). 이 두 가지 중요한 단계는 반드시 필요하며 프로그램 오류를 줄이려면 특별한 주의가 필요합니다.

공격자의 경우 SQL 주입 공격을 수행하려면 데이터베이스 솔루션에 대한 근거 있는 추론을 수행하는 것이 매우 필요합니다(물론 공격자가 소스 프로그램과 데이터베이스 솔루션을 볼 수 없다고 가정).

코드:

아아앙

그림 3-1은 이 양식이 브라우저에 표시되는 모습을 보여줍니다.

공격자로서 그는 사용자 이름과 비밀번호를 확인하기 위해 쿼리를 추측하는 것부터 시작했습니다. 그는 소스 파일을 보고 당신의 습관을 추측하기 시작할 수 있습니다.

그림 3-1. 브라우저의 로그인 양식 표시

명명 규칙. 일반적으로 양식의 필드 이름은 데이터 테이블의 필드 이름과 동일하다고 가정합니다. 물론 서로 다르다는 것을 보장하는 것이 반드시 신뢰할 수 있는 보안 조치는 아닙니다.

첫 번째 추측의 경우 일반적으로 다음 예의 쿼리를 사용합니다.

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>

예전에는 사용자 비밀번호의 MD5 값을 사용하는 것이 일반적이었지만 이제는 지금은 특별히 안전하지 않습니다. 최근 연구에 따르면 MD5 알고리즘에 결함이 있으며 MD5 데이터베이스 수가 많아 MD5 역 크래킹의 어려움이 줄어드는 것으로 나타났습니다. http://www.php.cn/을 방문하세요. 데모를 확인해 보세요.

번역 주석: 이것은 산둥 대학교 교수인 Wang Xiaoyun의 연구에 따르면 MD5 "충돌", 즉 동일한 MD5 값을 생성할 수 있는 두 개의 다른 파일과 문자열을 빠르게 찾을 수 있음을 보여줍니다. MD5는 암호화 알고리즘이 아닌 정보 다이제스트 알고리즘이므로 역크래킹은 불가능합니다. 그러나 이 결과에 따르면 위의 특별한 경우에는 md5를 직접 사용하는 것은 위험합니다.

가장 좋은 보호 방법은 비밀번호에 고유한 정의 문자열을 추가하는 것입니다. 예:

코드:

아아앙

물론 공격자는 처음에는 제대로 작동하지 않을 수 있으며 종종 몇 가지 실험을 수행해야 합니다. 실험하는 더 좋은 방법은 사용자 이름으로 작은따옴표를 입력하는 것입니다. 이렇게 하면 몇 가지 중요한 정보가 노출될 수 있기 때문입니다. 많은 개발자들은 Mysql 문 실행 중에 오류가 발생하면 오류를 보고하기 위해 mysql_error() 함수를 호출합니다. 아래 예를 참조하세요.

CODE:

<?php
 
$password_hash = md5($_POST[&#39;password&#39;]);
 
$sql = "SELECT count(*)
      FROM   users
      WHERE  username = &#39;{$_POST[&#39;username&#39;]}&#39;
      AND    password = &#39;$password_hash&#39;";
 
?>

이 방법은 개발에는 유용하지만 공격자에게 중요한 정보가 노출될 수 있습니다. 공격자가 사용자 이름으로 작은따옴표를 사용하고 비밀번호로 mypass를 사용하는 경우 쿼리 문은 다음과 같습니다.

CODE:

<?php
 
$salt = &#39;SHIFLETT&#39;;
$password_hash = md5($salt . md5($_POST[&#39;password&#39;]
. $salt));
 
?>

명령문이 MySQL로 전송되면 시스템에 다음 오류 메시지가 표시됩니다.

아아앙

어떠한 노력도 하지 않고도 공격자는 이미 두 개의 필드 이름(사용자 이름과 비밀번호)과 쿼리에 나타나는 순서를 알고 있습니다. 또한 공격자는 데이터가 올바르게 필터링되지 않고(프로그램이 불법적인 사용자 이름을 표시하지 않음) 탈출(데이터베이스 오류 발생)했다는 사실도 알고 있으며 전체 WHERE 조건의 형식도 노출되므로 공격자가 다음과 같은 작업을 수행할 수 있습니다. 조작을 시도해보세요. 쿼리와 일치하는 기록이 있습니다.

이 시점에서 공격자에게는 많은 옵션이 있습니다. 하나는 사용자 이름과 비밀번호의 일치 여부에 관계없이 쿼리가 일치하도록 특별한 사용자 이름을 입력하는 것입니다.

myuser' or 'foo' = 'foo' --

假定将mypass作为密码，整个查询就会变成：

CODE:

<?php
 
$sql = "SELECT *
      FROM   users
      WHERE  username = &#39;myuser&#39; or &#39;foo&#39; = &#39;foo&#39;
--
      AND    password =
&#39;a029d0df84eb5549c641e04a9ef389e5&#39;";
 
?>

由于中间插入了一个SQL注释标记，所以查询语句会在此中断。这就允许了一个攻击者在不知道任何合法用户名和密码的情况下登录。

如果知道合法的用户名，攻击者就可以该用户(如chris)身份登录：

chris' --

只要chris是合法的用户名，攻击者就可以控制该帐号。原因是查询变成了下面的样子：

CODE:

<?php
$sql = "SELECT *
      FROM   users
      WHERE  username = &#39;chris&#39; --
      AND    password =
&#39;a029d0df84eb5549c641e04a9ef389e5&#39;";
?>

幸运的是，SQL注入是很容易避免的。正如第一章所提及的，你必须坚持过滤输入和转义输出。

虽然两个步骤都不能省略，但只要实现其中的一个就能消除大多数的SQL注入风险。如果你只是过滤输入而没有转义输出，你很可能会遇到数据库错误（合法的数据也可能影响SQL查询的正确格式），但这也不可靠，合法的数据还可能改变SQL语句的行为。另一方面，如果你转义了输出，而没有过滤输入，就能保证数据不会影响SQL语句的格式，同时也防止了多种常见SQL注入攻击的方法。

当然，还是要坚持同时使用这两个步骤。过滤输入的方式完全取决于输入数据的类型（见第一章的示例），但转义用于向数据库发送的输出数据只要使用同一个函数即可。对于MySQL用户，可以使用函数mysql_real_escape_string( )：

CODE:

<?php
 
$clean = array();
$mysql = array();
 
$clean[&#39;last_name&#39;] = "O&#39;Reilly";
$mysql[&#39;last_name&#39;] =
mysql_real_escape_string($clean[&#39;last_name&#39;]);
 
$sql = "INSERT
      INTO   user (last_name)
      VALUES (&#39;{$mysql[&#39;last_name&#39;]}&#39;)";
 
?>

尽量使用为你的数据库设计的转义函数。如果没有，使用函数addslashes( )是最终的比较好的方法。

当所有用于建立一个SQL语句的数据被正确过滤和转义时，实际上也就避免了SQL注入的风险。

CODE:

如果你正在使用支持参数化查询语句和占位符的数据库操作类（如PEAR::DB, PDO等），你就会多得到一层保护。见下面的使用PEAR::DB的例子：

CODE:

<?php
$sql = &#39;INSERT
      INTO   user (last_name)
      VALUES (?)&#39;;
$dbh->query($sql,
array($clean[&#39;last_name&#39;]));
?>

CODE:

 

由于在上例中数据不能直接影响查询语句的格式，SQL注入的风险就降低了。PEAR::DB会自动根据你的数据库的要求进行转义，所以你只需要过滤输出即可。

如果你正在使用参数化查询语句，输入的内容就只会作为数据来处理。这样就没有必要进行转义了，尽管你可能认为这是必要的一步（如果你希望坚持转义输出习惯的话）。实际上，这时是否转义基本上不会产生影响，因为这时没有特殊字符需要转换。在防止SQL注入这一点上，参数化查询语句为你的程序提供了强大的保护。

 

  译注：关于SQL注入，不得不说的是现在大多虚拟主机都会把magic_quotes_gpc选项打开，在这种情况下所有的客户端GET和POST的数据都会自动进行addslashes处理，所以此时对字符串值的SQL注入是不可行的，但要防止对数字值的SQL注入，如用intval()等函数进行处理。但如果你编写的是通用软件，则需要读取服务器的magic_quotes_gpc后进行相应处理。

 以上就是PHP安全-SQL 注入的内容，更多相关内容请关注PHP中文网（www.php.cn）！