SQL注入是从正常的WWW端口访问，而且表面看起来跟一般的Web页面访问没什么区别，所以目前市面的防火墙都不会对SQL注入发出警报，如果管理员没有查看Web日志的习惯，则可能被入侵很长时间都不会发觉。但是，SQL注入的手法相当灵活，在注入时会碰到很多意外的情况，能根据具体情况进行分析，构造巧妙的SQL.语句，从而成功获取想要的数据。 SQL注入攻击的总体思路是: 发现 SQL 注入位置; 。判断后台数据库类型; 确定 shell可执行情况; 。发现 Web虚拟目录; 。上传木马; 。得到管理员权限。 11.5.2 MySQL中的SQL注入 SQL注入可能是最令人担心的针对MySQL系统的攻击，因为它最有可能成为连接到互联网服务器上的初始攻击媒介。利用SQL注入，有可能把数据库服务器用作进入互联网的登录场一 一或者至少是进入MySOL服务器所在网络的登录场 并有可能成为发动进一步攻击的平台。 由于忽视对引入的数据进行检查，因此经常导致应用程序可以在其后台数据库执行任意查询。当应用程序创建的字符串持有SQL查询，包括未对用户所提供的数据进行任何输入验证时，就会发生问题。 请设想一个登录表单，用户在表单内输入用户名和口令。该数据被直接传递给数据库查询，因此，如果用户在表单内输入用户名fred和口令sesame，执行如下查询 select * from tblUsers where username = 'fred' and password 'sesame" 在本例中，当用户指定的字符串中带有单引号时就会产生问题。用户可以提供一 个如下所示的用户名： fred'# 这将导致如下所示的SQL查询字符串： select * from tblusers where username = ='sesame' 显然，利用该语句，可以在不知道用户fred口令的情况下以fred身份进行登录，因为数据库在「#」（MySQL单行注释符号）处停止了对查询的解释。更糟糕的是，用户可以利用其他SQL语句，例如UNION、INSERT、DELETE等直接操纵数据库。 尽管安全社团已经对此问题持续宣传了好几年，但SQL注入仍然是个大问题。问题本身源自在 Web应用程序中没有对输入进行足够的验证，但是后台数据库的配置也对攻击者的成功攻击负有极大的责任。如果很好地锁定了MySQL的shell，甚至可以减轻严重的应用程序缺陷所导致的损失。 PHP是结合 MySQL使用的最常见的Web应用程序脚本语言，因此本节假定脚 本环境是 PHP— -但是每种脚本语言在这些攻击方面几乎是等效的。 在PHP内，magic_quotes_gpc 设置控制引擎是否自动转义单引号、双引号、反斜线和NULL。在magic_quotes_gpc内，gpc代表GET/POST/COOKIE。在较新的版本内，该设置默认有效，因此，如果用户正在提交的值被放入如下所示的字符串变量内： _REQUEST['user']. FROM user where 就不能进行SQL注入。但是，如果该值被放入查询的非界定部分，例如数值、 _REQUEST['user']; 或者 squery = "SELECT * FROM user where max_connections $_REQUEST['user']; 则仍然可能进行SQL注入。在MySQL/PHP内处理数值问题的一种方法是把全 部用户输入都界定在单引号内，包括数字。比较关系仍然有效，但是 magic_quotes_gpc 将防止攻击者转义字符串。 显然，如果关闭了magic-quotes，依赖于用户输入验证方式，总有可能进行 SQL注入。 假设攻击者能够进行SQL注入攻击，那么他可以做什么？主要的危险区域有： UNION SELECT LOAD_FILE函数 LOAD DATAINFILE语句 SELECT...INTO OUTFILE语句 BENCHMARK函数 User Defined Functions（用户自定义函数）
