SQL注入是从正常的WWW连线埠访问，而且表面看起来跟一般的Web页面访问没什幺区别，所以目前市面的防火墙都不会对SQL注入发出警报，如果管理员没查看IIS日誌的习惯，可能被入侵很长时间都不会发觉。但是，SQL注入的手法相当灵活，在注入的时候会碰到很多意外的情况。能不能根据具体情况进行分析，构造巧妙的SQL语句，从而成功获取想要的数据。

据统计，网站用ASP+Access或SQLServer的占70%以上，PHP+MySQL占20%，其他的不足10%。

Incorrectly filtered escape characters

This form of SQL injection occurs when user input is not filtered for escape characters and is then passed into a SQL statement. This results in the potential manipulation of the statements performed on the database by the end user of the application.

The following line of code illustrates this vulnerability:

statement := "SELECT * FROM users WHERE name = '" + userName + "';"

This SQL code is designed to pull up the records of a specified username from its table of users, however, if the "userName" variable is crafted in a specific way by a malicious user, the SQL statement may do more than the code author intended. For example, setting the "userName" variable as

a' or 't'='t

renders this SQL statement by the parent language:

SELECT * FROM users WHERE name = 'a' OR 't'='t';

If this code were to be used in an authentication procedure then this example could be used to force the selection of a valid username because the evaluation of 't'='t' is always true.

On some SQL servers such as MS SQL Server any valid SQL command may be injected via this method, including the execution of multiple statements. The following value of "userName" in the statement below would cause the deletion of the "users" table as well as the selection of all data from the "data" table (in essence revealing the information of every user):

a';DROP TABLE users; SELECT * FROM data WHERE name LIKE '%

This input renders the final SQL statement as follows:

SELECT * FROM users WHERE name = 'a';DROP TABLE users; SELECT * FROM DATA WHERE name LIKE '%';

Other SQL implementations won't execute multiple commands in the same SQL query as a security measure. This prevents hackers from injecting entirely separate queries, but doesn't stop them from modifying queries.

Incorrect type handling

This form of SQL injection occurs when a user supplied field is not strongly typed or is not checked for type constraints. This could take place when a numeric field is to be used in a SQL statement, but the programmer makes no checks to validate that the user supplied input is numeric. For example:

statement := "SELECT * FROM data WHERE id = " + a_variable + ";"

It is clear from this statement that the author intended a_variable to be a number correlating to the "id" field. However, if it is in fact a string then the end user may manipulate the statement as they choose, thereby bypassing the need for escape characters. For example, setting a_variable to

1;DROP TABLE users

will delete the "users" table from the database as the rendered SQL would be rendered as follows:

SELECT * FROM DATA WHERE id = 1;DROP TABLE users;

php 网站的使用超过了20% asp的使用已经减少了(更正) php已经成了主流web开发语言之一!

1.1 普通SQL注入技术概述

目前没有对SQL注入技术的标準定义，以下是从2个方面进行了描述：

(1) 脚本注入式的攻击

(2) 恶意用户输入用来影响被执行的SQL脚本

当一个攻击者通过在查询语句中插入一系列的SQL语句来将数据写入到应用程式中，这种方法就可以定义成SQL注入。

“从一个资料库获得未经授权的访问和直接检索”，SQL注入攻击就其本质而言，它利用的工具是SQL的语法，针对的是应用程式开发者编程过程中的漏洞，“当攻击者能够运算元据，往应用程式中插入一些SQL语句时，SQL注入攻击就发生了”。实际上，SQL注入是存在于常见的多连线的应用程式中一种漏洞，攻击者通过在应用程式中预先定义好的查询语句结尾加上额外的SQL语句元素，欺骗资料库伺服器执行非授权的任意查询。这类应用程式一般是网路应用程式(Web Application)，它允许用户输入查询条件，并将查询条件嵌入SQL请求语句中，传送到与该应用程式相关联的资料库伺服器中去执行。通过构造一些畸形的输入，攻击者能够操作这种请求语句去获取预先未知的结果。

1.2 SQL注入攻击的防御手段

由于越来越多的攻击利用了SQL注入技术，也随之产生了很多试图解决注入漏洞的方案。目前被提出的方案有：

(1) 在服务端正式处理之前对提交数据的合法性进行检查；

(2) 封装客户端提交信息；

(3) 替换或删除敏感字元/字元串；

(4) 禁止出错信息。

方案(1)被公认是最根本的解决方案，在确认客户端的输入合法之前，服务端拒绝进行关键性的处理操作，不过这需要开发者能够以一种安全的方式来构建网路应用程式，虽然已有大量针对在网路应用程式开发中如何安全地访问资料库的文档出版，但仍然有很多开发者缺乏足够的安全意识，造成开发出的产品中依旧存在

注入漏洞；

方案(2)的做法需要RDBMS的支持，目前只有Oracle採用该技术；

方案(3)则是一种不完全的解决措施，例如，当客户端的输入为“…ccmdmcmdd…”时,在对敏感字元串“cmd”替换删除以后，剩下的字元

正好是“…cmd…”；

方案(4)是目前最常被採用的方法，很多安全文档都认为SQL注入攻击需要通过错误信息收集信息，有些甚至声称某些特殊的任务若缺乏详细的错误信息则不能完成，这使很多安全专家形成一种观念，即注入攻击在缺乏详细错误的情况下不能实施。而实际上，禁止错误信息是在服务端处理完毕之后进行补救，攻击其实已经发生，只是企图阻止攻击者知道攻击的结果而已。

SQL盲注技术就是一些攻击者使用的新技术，其在错误信息被禁止的情况下使攻击者仍能获得所需的信息，并继续实施注入攻击。