页面输入框防止sql注入检验_关于防止sql注入的几种手段

㈠如何彻底防止sql注入

1、对，限制用户输入肯定有效
2、应该也可以做到，但正则不是一种高效的方法，用HtmlEncode的方法可以有效防止空格等被DBMS解释，但注意别把编码、解码搞反了；存储过程是DBMS执行的一段程序，把数据操纵交给存储过程执行，而不是提交SQL语句，可以有效防止SQL注入。
3、地址栏的Sql攻击，下面我引用了一段资料解释，他关于机制说的较清楚，关于解决，只是从客户端考虑的，实际上用存储过程等都可以防范。
资料：
首先，入侵者会对一个网站确定可不可以进行注入，假设一篇文章的地址为：http://www.naohou.cn/show.asp?id=325一般会以提交两个地址来测试，如：
http://www.naohou.cn/show.asp?id=325 and 1=1
http://www.naohou.cn/show.asp?id=325 and 1=2
第一个地址后面加了 and 1=1，构成的SQL语句也就变为了：Select * from 表单名 where id=1 and 1=1这句话要成立就必须and前后语句都成立。那么前面的文章地址是可以访问的，后面的1=1也是客观成立的，那么第一个地址就可以正常显示；相反1=2是显然不成立的，关键就看这步了，如果提交and 1=2页面还是正常显示说明他并没有将and 1=2写入SQL语句，此站也就不存在注入漏洞；但如果提交and 1=2之后返回了错误页面则说明此站点将后面的语句带入了SQL语句并执行了，也就说明他可以进行SQL注入。（注：如果地址后面跟的是news.asp?id='1'就得变为news.asp?id=1' and '1'='1来补全引号了）
那么，知道可以注入后入侵者可以做什么呢？
这里就简单的说一下，比如提交这样的地址：
http://www.naohou.cn/show.asp?id=325 and exists (select * from 表名 where 列名=数据)
根据返回的正确或错误页面来判断猜的表名和列名是否正确，具体实现时是先猜表名再猜列名。当猜出表名和列名之后还可以用ASC和MID函数来猜出各列的数据。MID函数的格式为：mid(变量名,第几个字符开始读取,读取几个字符)，比如：mid(pwd,1,2)就可以从变量pwd中的第一位开始读取两位的字符。ASC函数的格式为：ASC（"字符串"），如：asc("a")就可以读出字母a的ASCII码了。那么实际应用的时候就可以写为：asc(mid(pwd,1,1))这样读取的就是pwd列的第一个字符的ASCII码，提交： asc(mid(pwd,1,1))>97以返回的页面是否为正确页面来判断pwd列的第一个字符的ASCII码是否大于97（a的ASCII码），如果正确就再试是否小于122（z的ASCII码）……这样慢慢缩小字符的ASCII码的范围，猜到真实的ASCII码也只是时间的问题。一位一位的猜就可以得到数据库中的用户名和密码了。还有一种ASP验证缺陷——就是用户名和密码都输'or '1'='1，构造SQL语句Select * form 表单名 where username='' or '1'='1' and pwd='' or '1'='1'就可以达到绕过密码验证的目的。
说了那么多，其实防范的方法很简单，我们把特殊字符（如and、or、'、"）都禁止提交就可以防止注入了。ASP传输数据分为get和post两种， get是通过将数据添加到URL后提交的方式，post则是利用邮寄信息数据字段将数据传送到服务器。

㈡怎么样防止Sql注入

(1)对于动态构造SQL查询的场合，可以使用下面的技术：

第一：替换单引号，即把所有单独出现的单引号改成两个单引号，防止攻击者修改SQL命令的含义。再来看前面的例子，“SELECT * from Users WHERE login = ''' or ''1''=''1' AND password = ''' or ''1''=''1'”显然会得到与“SELECT * from Users WHERE login = '' or '1'='1' AND password = '' or '1'='1'”不同的结果。

第二：删除用户输入内容中的所有连字符，防止攻击者构造出类如“SELECT * from Users WHERE login = 'mas' -- AND password =''”之类的查询，因为这类查询的后半部分已经被注释掉，不再有效，攻击者只要知道一个合法的用户登录名称，根本不需要知道用户的密码就可以顺利获得访问权限。

第三：对于用来执行查询的数据库帐户，限制其权限。用不同的用户帐户执行查询、插入、更新、删除操作。由于隔离了不同帐户可执行的操作，因而也就防止了原本用于执行SELECT命令的地方却被用于执行INSERT、UPDATE或DELETE命令。

⑵ 用存储过程来执行所有的查询。SQL参数的传递方式将防止攻击者利用单引号和连字符实施攻击。此外，它还使得数据库权限可以限制到只允许特定的存储过程执行，所有的用户输入必须遵从被调用的存储过程的安全上下文，这样就很难再发生注入式攻击了。

⑶ 限制表单或查询字符串输入的长度。如果用户的登录名字最多只有10个字符，那么不要认可表单中输入的10个以上的字符，这将大大增加攻击者在SQL命令中插入有害代码的难度。

⑷ 检查用户输入的合法性，确信输入的内容只包含合法的数据。数据检查应当在客户端和服务器端都执行——之所以要执行服务器端验证，是为了弥补客户端验证机制脆弱的安全性。

在客户端，攻击者完全有可能获得网页的源代码，修改验证合法性的脚本（或者直接删除脚本），然后将非法内容通过修改后的表单提交给服务器。因此，要保证验证操作确实已经执行，唯一的办法就是在服务器端也执行验证。你可以使用许多内建的验证对象，例如RegularExpressionValidator，它们能够自动生成验证用的客户端脚本，当然你也可以插入服务器端的方法调用。如果找不到现成的验证对象，你可以通过CustomValidator自己创建一个。

⑸ 将用户登录名称、密码等数据加密保存。加密用户输入的数据，然后再将它与数据库中保存的数据比较，这相当于对用户输入的数据进行了“消毒”处理，用户输入的数据不再对数据库有任何特殊的意义，从而也就防止了攻击者注入SQL命令。System.Web.Security.FormsAuthentication类有一个，非常适合于对输入数据进行消毒处理。

⑹ 检查提取数据的查询所返回的记录数量。如果程序只要求返回一个记录，但实际返回的记录却超过一行，那就当作出错处理。
---------------------------------------------------------------------------------------------------------------------------
关键是明白原理，其实防范很简单的，
1.过滤SQL需要的参数中的敏感字符（注意加入忽略大小写）
2.禁用数据库服务器的xp_cmdshell存储过程，删除相应用到的dll
3.屏蔽服务器异常信息

㈢ asp网页制作中怎样防止sql注入

㈣输入框是否屏蔽sql注入

可以防止注入。
这种攻击一般叫做xss攻击有的时候页面中会有一个输入框，用户输入内容后会显示在页面中，类似于网页聊天应用。

㈤怎样防止sql注入

可以使用变量绑定的方式就可以防止sql注入，如果是直接拼接的方式那么就非常容易被注入。比如：select * from tablename where user='admin' and pwd ='123' 假设说这个是一个登录的sql语句，admin是用户文本框输入的，pwd是密码框输入的。如果密码文本框如果输入：' or '1'='1 那么拼接起sql就是select * from tablename where user='admin' and pwd ='' or '1'='1' 那么就会跳过sql的条件就直接进入登录，但是如果是使用绑定变量的就不一样
如下：
select * from tablename where user=@user and pwd =@pwd
@user=admin
@pwd=123
这样的话不管user和pwd传入的是什么内容都被sql server识别成字符串而不是直接拼接在sql 语句上。

㈥关于防止sql注入的几种手段

所谓SQL注入，就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。具体来说，它是利用现有应用程序，将（恶意）的SQL命令注入到后台数据库引擎执行的能力，它可以通过在Web表单中输入（恶意）SQL语句得到一个存在安全漏洞的网站上的数据库，而不是按照设计者意图去执行SQL语句。比如先前的很多影视网站泄露VIP会员密码大多就是通过WEB表单递交查询字符暴出的，这类表单特别容易受到SQL注入式攻击．
防护
归纳一下，主要有以下几点：
1.永远不要信任用户的输入。对用户的输入进行校验，可以通过正则表达式，或限制长度；对单引号和
双"-"进行转换等。
2.永远不要使用动态拼装sql，可以使用参数化的sql或者直接使用存储过程进行数据查询存取。
3.永远不要使用管理员权限的数据库连接，为每个应用使用单独的权限有限的数据库连接。
4.不要把机密信息直接存放，加密或者hash掉密码和敏感的信息。
5.应用的异常信息应该给出尽可能少的提示，最好使用自定义的错误信息对原始错误信息进行包装
6.sql注入的检测方法一般采取辅助软件或网站平台来检测，软件一般采用sql注入检测工具jsky，网站平台就有亿思网站安全平台检测工具。MDCSOFT SCAN等。采用MDCSOFT-IPS可以有效的防御SQL注入，XSS攻击等。

㈦如何防范SQL注入漏洞及检测

SQL注入漏洞攻击的防范方法有很多种，现阶段总结起来有以下方法：
(1)数据有效性校验。如果一个输入框只可能包括数字，那么要通过校验确保用户输入的都是数字。如果可以接受字母，那就要检查是不是存在不可接受的字符，最好的方法是增加字符复杂度自动验证功能。确保应用程序要检查以下字符：分号、等号、破折号、括号以及SQL关键字。另外限制表单数据输入和查询字符串输入的长度也是一个好方法。如果用户的登录名最多只有10个字符，那么不要认可表单中输入10个以上的字符，这将大大增加攻击者在SQL命令中插入有害代码的难度。
(2)封装数据信息。对客户端提交的数据进行封装，不要将数据直接存入cookie中，方法就是在编程的代码中，插入session、if、try、else，这样可以有效地防止攻击者获取cookie中的重要信息。
(3)去除代码中的敏感信息。将在代码中存在的用户名、口令信息等敏感字段删除，替换成输入框。
SQL=" select from users where username = ’admin’and password= ’1234567’ "
如：这样显然会暴露管理员的用户名、口令信息。可以将其修改成：
SQL= " select * from users where username='" +Txtuser.Text + "' and userpwd='" + Textpwd.Text + "'"
这样就安全了很多，入侵者也是不会轻易的就获取到用户名、口令信息。
(4)替换或删除单引号。使用双引号替换掉所有用户输入的单引号，这个简单的预防措施将在很大程度上预防SQL注入漏洞攻击，单引号时常会无法约束插入数据的Value，可能给予输入者不必要的权限。用双引号替换掉单引号可以使大部分SQL注入漏洞攻击失败。如：
“select* from users where username='" + admin + "' and userpwd='" + 1234567+ "'”
显然会得到与
“select * from users where username='admin' and password= '1234567'”
相同的结果。
(5)指定错误返回页面。攻击者有时从客户端尝试提交有害代码和攻击字符串，根据Web Service给出的错误提示信息来收集程序及服务器的信息，从而获取想得到的资料。应在Web Service中指定一个不包含任何信息的错误提示页面。
(6)限制SQL字符串连接的配置文件。使用SQL变量，因为变量不是可以执行的脚本，即在Web页面中将连接数据库的SQL字符串替换成指定的Value，然后将Web.config文件进行加密，拒绝访问。
(7)设置Web目录的访问权限。将虚拟站点的文件目录禁止游客用户(如：Guest用户等)访问，将User用户权限修改成只读权限，切勿将管理权限的用户添加到访问列表。
(8)最小服务原则。Web服务器应以最小权限进行配置，只提供Web服务，这样可以有效地阻止系统的危险命令，如ftp、cmd、vbscript等。
(9)鉴别信息加密存储。将保存在数据库users表中的用户名、口令信息以密文形式保存，也可以对users表进行加密处理，这样可以大大增加对鉴别信息访问的安全级别。
(10)用户权限分离。应尽可能的禁止或删除数据库中sa权限用户的访问，对不同的数据库划分不同的用户权限，这样不同的用户只能对授权给自己的数据库执行查询、插入、更新、删除操作，就可以防止不同用户对非授权的数据库进行访问。

㈧如何测试WEB应用程序防止SQL注入攻击

WEB应用程序的安全测试，防止SQL注入攻击，下面举一些简单的例子加以解释。——Inder P Singh。
许多应用程序运用了某一类型的数据库。测试下的应用程序有一个接受用户输入的用户界面，这些输入值用来执行下列任务。
给用户显示相关的存储数据。例如，程序通过用户输入的登录信息检查用户凭证（权限），从而只显示相关的功能和数据。
将用户输入的数据存储到数据库中。例如，用户填写了一张表格并提交，程序立即将之存储到数据库中；从而，用户可以在本次会话和下次会话中获取这些数据。
一些用户输入值可能会被接下来程序将执行的SQL语句运用到，而程序有可能不会正确执行用户输入的值。如果是这样的话，蓄意用户可以向程序提供非法数据，这些数据接下来被运用到框架中并且用来在数据库中执行SQL语句。这就是SQL注入。该行为的结果令人鸣起警钟。
SQL注入可能导致以下结果：
用户可以以另一用户的身份登录到程序，甚至是管理员的身份。
用户可以看到其他用户的隐私信息，如其他用户的简介细节，交易细节。
用户可以修改应用程序配置信息以及其他用户的数据。
用户可以修改数据库的结构，甚至是删除应用数据库中的表格。
用户可以控制数据库服务器并且按照自己意愿随意执行命令。
因为允许SQL注入的结果是相当严重的，所以在应用程序的安全测试阶段应对SQL注入进行测试。通过对SQL注入技术有一个总体的概括，让我们来理解一些SQL注入的实际例子！
重点：SQL注入问题只能在测试环境中测试
若应用程序页面有登录功能，程序有可能使用如下所示的动态SQL语句。这条语句本应从用户表中返回至少一条用户详细信息作为结果，当SQL语句中含有输入的用户名和密码时。

SELECT * FROM Users WHERE User_Name = ‘” & strUserName & “‘ AND Password = ‘” & strPassword & “’;”

如果测试人员输入John作为用户名（用户名文本框），输入Smith作为密码（密码文本框），上述SQL语句就变成：

SELECT * FROM Users WHERE User_Name = ‘John’ AND Password = ‘Smith’

如果测试人员输入John’-作为用户名，不输入密码，那么SQL语句变成：

SELECT * FROM Users WHERE User_Name = ‘John’– AND Password = ‘’;

我们可以注意到，SQL语句中John后面的部分成为了注释。如果用户表中有一些用户用户名为“John”，那么程序能够允许测试人员以用户John的身份登录，这样，测试人员可以看到用户John的隐私信息。
如果测试人员不知道任何程序中已存在的用户该怎么办呢？在这种情况下，测试人员可以尝试相似的用户名像“admin”，“administrator”，“sysadmin”。如果这些用户名在数据库中都不存在，测试人员可以输入John’ or ‘x’=’x作为用户名，Smith’ or ‘x’=’x作为密码。那么SQL语句如以下所示：

SELECT * FROM Users WHERE User_Name = ‘John’ or ‘x’='x’ AND Password = ‘Smith’ or ‘x’=’x’;

因为‘x’=’x’这一条件总是成立的，结果集包含用户表中所有行。程序允许测试人员以用户表中第一个用户的身份登录进去。
重点：测试人员在尝试下列SQL注入之前应该请求拥有数据库管理员或者开发人员权限以备份有问题的表格。
如果测试人员输入John’; DROP table users_details;’—作为用户名，任意值作为密码，那么SQL语句如下所示：

SELECT * FROM Users WHERE User_Name = ‘John’; DROP table users_details;’ –‘ AND Password = ‘Smith’;

这条语句将造成表格“users_details”从数据库中永久删除。
虽然上述例子说明的是页面中登录功能上运用SQL注入技术，但是测试人员应在应用程序中所有接受用户输入的页面运用该技术测试，如搜索页面，反馈页面等等。
SQL注入可能出现在运用了SSL的程序中，即使是防火墙也不能防御SQL注入攻击。
本文中，我尽量以简单的形式解释SQL注入技术。再次强调，SQL注入只能在测试环境中测试，不能再开发环境，生产环境或者其他任何环境下测试。除了手工测试程序是否易受SQL注入攻击，我们还应该使用web vulnerability scanner（一款扫描工具）来检查SQL注入。

㈨如何防止SQL注入

所谓SQL注入，就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令，比如先前的很多影视网站泄露VIP会员密码大多就是通过WEB表单递交查询字符暴出的，这类表单特别容易受到SQL注入式攻击．
1、如何防范?
好在要防止ASP.NET应用被SQL注入式攻击闯入并不是一件特别困难的事情，只要在利用表单输入的内容构造SQL命令之前，把所有输入内容过滤一番就可以了。过滤输入内容可以按多种方式进行。
⑴ 对于动态构造SQL查询的场合，可以使用下面的技术:
第一:替换单引号，即把所有单独出现的单引号改成两个单引号，防止攻击者修改SQL命令的含义。再来看前面的例子，“SELECT * from Users WHERE login = ''' or ''1''=''1' AND password = ''' or ''1''=''1'”显然会得到与“SELECT * from Users WHERE login = '' or '1'='1' AND password = '' or '1'='1'”不同的结果。
第二:删除用户输入内容中的所有连字符，防止攻击者构造出类如“SELECT * from Users WHERE login = 'mas' -- AND password =''”之类的查询，因为这类查询的后半部分已经被注释掉，不再有效，攻击者只要知道一个合法的用户登录名称，根本不需要知道用户的密码就可以顺利获得访问权限。
第三:对于用来执行查询的数据库帐户，限制其权限。用不同的用户帐户执行查询、插入、更新、删除操作。由于隔离了不同帐户可执行的操作，因而也就防止了原本用于执行SELECT命令的地方却被用于执行INSERT、UPDATE或DELETE命令。
⑵ 用存储过程来执行所有的查询。SQL参数的传递方式将防止攻击者利用单引号和连字符实施攻击。此外，它还使得数据库权限可以限制到只允许特定的存储过程执行，所有的用户输入必须遵从被调用的存储过程的安全上下文，这样就很难再发生注入式攻击了。
⑶ 限制表单或查询字符串输入的长度。如果用户的登录名字最多只有10个字符，那么不要认可表单中输入的10个以上的字符，这将大大增加攻击者在SQL命令中插入有害代码的难度。
⑷ 检查用户输入的合法性，确信输入的内容只包含合法的数据。数据检查应当在客户端和服务器端都执行——之所以要执行服务器端验证，是为了弥补客户端验证机制脆弱的安全性。
在客户端，攻击者完全有可能获得网页的源代码，修改验证合法性的脚本(或者直接删除脚本)，然后将非法内容通过修改后的表单提交给服务器。因此，要保证验证操作确实已经执行，唯一的办法就是在服务器端也执行验证。你可以使用许多内建的验证对象，例如RegularExpressionValidator，它们能够自动生成验证用的客户端脚本，当然你也可以插入服务器端的方法调用。如果找不到现成的验证对象，你可以通过CustomValidator自己创建一个。
⑸ 将用户登录名称、密码等数据加密保存。加密用户输入的数据，然后再将它与数据库中保存的数据比较，这相当于对用户输入的数据进行了“消毒”处理，用户输入的数据不再对数据库有任何特殊的意义，从而也就防止了攻击者注入SQL命令。System.Web.Security.FormsAuthentication类有一个，非常适合于对输入数据进行消毒处理。
⑹ 检查提取数据的查询所返回的记录数量。如果程序只要求返回一个记录，但实际返回的记录却超过一行，那就当作出错处理。

㈩请问怎样在网页中防止sql注入

防止SQL注入的方法就是不要在程序中使用拼接的方式生成SQL语句
如:"select * from TableName where columnName='" + 变量 + "'"
这样很容易被注入，
如果变量 = " ' or 1=1 --"
这句sql的条件将永远为真

如果采用拼接SQL要把变量中的'（单引号）替换为''（两个单引号）

页面输入框防止sql注入检验

与页面输入框防止sql注入检验相关的内容