安全网站对策之_SQL注入的防范

2012-07-04

安全网站策略之_SQL注入的防范一，问题概述某些web站点，会直接使用用户输入的字符串来作为SQL文的一部分。这

安全网站策略之_SQL注入的防范
一，问题概述

某些web站点，会直接使用用户输入的字符串来作为SQL文的一部分。这就会产生SQL注入的风险。

二，举例说明1、PHP + PostgreSQL

$query = "SELECT * FROM usr WHERE uid = '$uid' AND pass = '$passh';$result = pg_query($conn, $query);

场景：这是容易被理解的SQL注入发生的场景，使用用户输入的用户名和密码来验证该用户是否可以login。

恶意输入模式：
    uid:taro'--
   pass:任意值
   分析：这样一来，验证用的SQL就变成以下SQL文：

SELECT * FROM usr WHERE uid = 'taro'--' AND pass ='eefd5bc2...'

2、Perl+DBI

$query = "SELECT * FROM usr WHERE uid = '$uid' AND pass = '$passh'";$sth =$dbh->prepare($query);$sth->execute();

场景：同上

恶意输入模式：
    uid:taro'--
   pass:任意值
   分析：从代码上看，已经使用了预处理方法对SQL进行了预处理。但是由于SQL文中包含变量，导致预处理不能进行。因此还是会导致SQL注入风险。

三，可能的后果
    1、非公开信息的泄露
    2、数据库中保存信息的被恶意篡改，删除。
    3、绕开认证的login
    4、恶意者可能会利用该漏洞使用存储过程来运行恶意的os command。

四，可能被攻击网站的特征
    1、所有用到数据库的web站点

五，如何解决

    彻底解决方案
    1-1、使用Placeholder来产生SQL语句。即preparedstatement。
    1-2、无法使用preparedstatement的场合，尽量使用数据库引擎提供的escape函数来过滤用户字符串。
     2、不要使用用户输入的参数组成SQL文

    改善方案
     1、不要将系统产生的错误消息直接输出到最终用户的浏览器。
     2、数据库账号严格实行最小权限赋予原则

更容易阅读的版本，见附件。

热点排行

SQL Server

安全网站对策之_SQL注入的防范