因为要对网站安全性进行测试，所以，学习了一些sql注入的知识。

    在网上看一些sql注入的东东，于是想到了对网站的输入框进行一些测试，本来是想在输入框中输入<SCRIPT>;alter(“abc”);</SCRIPT> ,但是输入框有字符限制，只好输入 <SCRIPT>结果网站出大问题了，呵呵，终于又出现了个bug。

　　另一个就是在URL最后随意输入一些字符或数字，结果，新闻模块那出现了问题，暴露了网站的一些信息，又一个bug，高兴下……

　　下面把今天看到的有关SQL注入方面的知识整理如下：

　　SQL注入是一种攻击方式，在这种攻击方式中，恶意代码被插入到字符串中，然后将该字符串传递到SQL Server的实例以进行分析和执行。任何构成SQL语句的过程都应进行注入漏洞检查，因为SQL Server将执行其接收到的所有语法有效的查询。一个有经验的、坚定的攻击者甚至可以操作参数化数据。

　　SQL注入的主要形式包括直接将代码插入到与SQL命令串联在一起并使其得以执行的用户输入变量。一种间接的攻击会将恶意代码注入要在表中存储或作为元数据存储的字符串。在存储的字符串随后串连到一个动态SQL命令中时，将执行该恶意代码。

　　注入过程的工作方式是提前终止文本字符串，然后追加一个新的命令。由于插入的命令可能在执行前追加其他字符串，因此攻击者将用注释标记“–”来终止注入的字符串。执行时，此后的文本将被忽略。

　　以下脚本显示了一个简单的SQL注入。此脚本通过串联硬编码字符串和用户输入的字符串而生成一个SQL查询：

　　var Shipcity;
　　ShipCity = Request.form. (“ShipCity”);
       var sql = “select * from OrdersTable where ShipCity = ‘” + ShipCity + “‘”;

　　用户将被提示输入一个市县名称。如果用户输入Redmond，则查询将由与下面内容相似的脚本组成：

　　SELECT * FROM OrdersTable WHERE ShipCity = ‘Redmond’
　　但是，假定用户输入以下内容：

　　Redmond’; drop table OrdersTable–
   此时，脚本将组成以下查询：
　　SELECT * FROM OrdersTable WHERE ShipCity = ‘Redmond’;drop table OrdersTable–‘

　　分号(;)表示一个查询的结束和另一个查询的开始。双连字符(–)指示当前行余下的部分是一个注释，应该忽略。如果修改后的代码语法正确，则服务器将执行该代码。SQL Server处理该语句时，SQL Server将首先选择OrdersTable中的所有记录（其中ShipCity为Redmond）。然后，SQL Server将删除OrdersTable。

    只要注入的SQL代码语法正确，便无法采用编程方式来检测篡改。因此，必须验证所有用户输入，并仔细检查在您所用的服务器中执行构造SQL命令的代码。本主题中的以下各部分说明了编写代码的最佳做法。
　　验证所有输入:

　  始终通过测试类型、长度、格式和范围来验证用户输入。实现对恶意输入的预防时，请注意应用程序的体系结构和部署方案。请注意，设计为在安全环境中运行的程序可能会被复制到不安全的环境中。以下建议应被视为最佳做法：

　　如果一个用户在需要邮政编码的位置无意中或恶意地输入了一个10 MB的MPEG文件，应用程序会做出什么反应？

　　如果在文本字段中嵌入了一个DROP TABLE语句，应用程序会做出什么反应？

　　测试输入的大小和数据类型，强制执行适当的限制。这有助于防止有意造成的缓冲区溢出</SCRIPT>