sql injection

随着B/S模式应用开发的发展，使用这种模式编写应用程序的程序员也越来越多。但是由于程序员的水平及经验也参差不齐，相当大一部分程序员在编写代码的时候，没有对用户输入数据的合法性进行判断，使应用程序存在安全隐患。用户可以提交一段数据库查询代码，根据程序返回的结果，获得某些他想得知的数据，这就是所谓的SQL Injection，即SQL注入。
　　SQL注入是从正常的WWW端口访问，而且表面看起来跟一般的Web页面访问没什么区别，所以目前市面的防火墙都不会对SQL注入发出警报，如果管理员没查看IIS日志的习惯，可能被入侵很长时间都不会发觉。但是，SQL注入的手法相当灵活，在注入的时候会碰到很多意外的情况。能不能根据具体情况进行分析，构造巧妙的SQL语句，从而成功获取想要的数据。
　　据统计，网站用ASP+Access或SQLServer的占70%以上，PHP+MySQ占L20%，其他的不足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盲注技术就是一些攻击者使用的新技术，其在错误信息被屏蔽的情况
　　下使攻击者仍能获得所需的信息，并继续实施注入攻击。