① php中防止sql注入，该如何解决
防sql注入的一个简单方法就是使用框架，一般成熟框架中会集成各种安全措施。
当然也可以自己处理，如果用户的输入能直接插入到SQL语句中，那么这个应用就易收到SQL注入的攻击。我认为最重要的一点，就是要对数据类型进行检查和转义。
php.ini
------------
display_errors 选项，应该设为display_errors = off。这样 php 脚本出错之后，不会在 web 页面输出错误，以免让攻击者分析出有作的信息。
打开magic_quotes_gpc来防止SQL注入，magic_quotes_gpc= Off，这个默认是关闭的，如果它打开后将自动把用户提交对sql的查询进行转换，比如把 ' 转为 '等，对于防止sql注射有重大作用。如果magic_quotes_gpc=Off，则使用addslashes()函数。
mysql 函数
---------------
调用mysql_query 等mysql 函数时，前面应该加上 @，即 @mysql_query(...)，这样 mysql 错误不会被输出。同理以免让攻击者分析出有用的信息。另外，有些程序员在做开发时，当mysql_query出错时，习惯输出错误以及sql 语句。
mysql_real_escape_string -- 转义 SQL 语句中使用的字符串中的特殊字符，并考虑到连接的当前字符集。
Sql语句
------------
对提交的 sql 语句，进行转义和类型检查。如果请求是数值型，那么调用is_numeric() 判断是否为数值。如果不是，则返回程序指定的默认值。简单起见，对于文本串，我将用户输入的所有危险字符（包括HTML代码），全部转义。由于php 函数addslashes()存在漏洞，我用str_replace()直接替换。get_magic_quotes_gpc()函数是php 的函数，用来判断magic_quotes_gpc 选项是否打开。
其它
---------
使用预处理语句和参数化查询（PDO或mysqli）。预处理语句和参数分别发送到数据库服务器进行解析，参数将会被当作普通字符处理。这种方式使得攻击者无法注入恶意的SQL。
② 求助，关于SQL注入如何绕过SELECT语句的过滤
1,：转换个别字母大小写，无效
2：输入SESELECTLECT之类的语句来代替SELECT，无效
3：用转义的URL编码来代替SELECT（不知道这么表述对不对，就是%后面跟上16进制的ascii码……），无效
4：用/**/来隔开SELECT中的各个字母，无效
③ 浅析sql注入漏洞与防范措施谁写的
这是一个比较激掘常见的题目，我可以给您提供一个浅析 SQL 注入漏洞和防范措施的参考：
一明伏核、 SQL 注入漏洞是什么？
SQL 注入漏洞是指攻击者通过输入恶意的 SQL 代码来实现对数据库的非法访问和操作的一种漏洞攻击方式。攻击者通过在表单等输入框中注入 SQL 语句，即可绕过应用程序的认证和授权机制，获取、更改、删除等非法操作数据库中的敏感数据。
二、 SQL 注入漏洞的影响及危害
1. 窃取数据：攻击者可以通过 SQL 注入漏洞窃取系统中的敏感数据，如用户名、密码、支付信息等等。
2. 破坏数据：攻击者通过 SQL 注入漏洞可以删除、更改、破坏数据库中的数据，致使系统服务不可用。
3. 破坏系统：攻击者可通过 SQL 注入漏洞执行攻击代码，破坏系统和服务器稳定性和安全性。
三、 SQL 注入漏洞防范措施
针对 SQL 注入漏洞的攻击可能性，可以采取以下几种防范措施：
1. 使用参数化的 SQL 查询。使用预编译语句能有效避免 SQL 注入攻击。
2. 过滤用户输入数据。对于用户输入的数据进行校验和过滤，例如过滤掉单引号、引号等特殊字符。
3. 使用安全的编程语言。使用一些安全的编程语言，例如 Java、Python、PHP 等语言，它们都提供了一些高级防范 SQL 注入 的 API。
4. 定期检查和更新应用程序。更新应用程序可以修复已知的漏洞并增强系统的安全性，在检查应用程序的漏洞时可以检测 SQL 注入漏洞的存在。
5. 对数据和系统进行加密。加密数据库中的数据和系统文件可以增强对敏感数据和保护系统的安全性。
总结：SQL 注入漏洞是一种比较危险的漏洞攻击方式，为了保障系统安全，我们需要认真选择开发语言、定期更新系统和应用程序，对用户输入的数据进行过滤和处理，以及加强数据和系统的安全。厅坦同时，也要提高开发人员的安全意识，从源头上预防 SQL 注入漏洞的出现。
④ 求助，关于SQL注入如何绕过SELECT语句的过滤
1,：转换个别字母大小写，无效
2：输入SESELECTLECT之类的语句来代替SELECT，无效
3：用转义的URL编码来代替SELECT（不知道这么表述对不对，就是%后面跟上16进制的ascii码……），无效
4：用/**/来隔开SELECT中的各个字母，无效
⑤ 通过代码限制输入select，能防止sql注入了有绕过方法吗
直接把符号的编码转换或者转义可以了。一般sql注入根本用不到select，譬如账号密码你默认就是在where条件上进行查询，如果人家or 1=1则默认真。另外也能通过UNION 返回的错误判断返回值的数量和类型。如果没限制 换行+GO 的话甚至能执行自己想要的SQL。但是这些最终都需要一个符号例如单引号"'"吧系统误以为输入框的内容已阶段。如果转义或者转编码后，最多就变成一段长字符而已
⑥ sql注入 form过滤怎么绕过
我常用的三种方法：
1，参数过滤，过滤掉 单引号，or，1=1 等类似这样的 。
2，使用 参数化方法格式化 ，不使用拼接SQL 语句。
3，主要业务使用存储过程，并在代码里使用参数化来调用（存储过程和方法2结合）
⑦ 用什么方法绕过SQL注入的限制
1、运用编码技术绕过
如URLEncode编码，ASCII编码绕过。例如or 1=1即%6f%72%20%31%3d%31，而Test也可以为CHAR(101)+CHAR(97)+CHAR(115)+CHAR(116)。
2、通过空格绕过
如两个空格代替一个空格，用Tab代替空格等，或者删除所有空格，如or’ swords’ =‘swords’ ，由于mssql的松散性，我们可以把or ‘swords’ 之间的空格去掉，并不影响运行。
3、运用字符串判断代替
用经典的or 1=1判断绕过,如or ‘swords’ =’swords’，这个方法就是网上在讨论的。
4、通过类型转换修饰符N绕过
可以说这是一个不错的想法，他除了能在某种程度上绕过限制，而且还有别的作用，大家自己好好想想吧。关于利用，如or ‘swords’ = N’ swords’ ，大写的N告诉mssql server 字符串作为nvarchar类型，它起到类型转换的作用，并不影响注射语句本身，但是可以避过基于知识的模式匹配IDS。
5、通过+号拆解字符串绕过
效果值得考证，但毕竟是一种方法。如 or ‘swords’ =‘sw’ +’ ords’ ；EXEC(‘IN’ +’ SERT INTO ‘+’ …..’ )
6、通过LIKE绕过
以前怎么就没想到呢？如or ‘swords’ LIKE ‘sw’！！！显然可以很轻松的绕过“=”“>”的限制……
7、通过IN绕过
与上面的LIKE的思路差不多,如or ‘swords’ IN (‘swords’)
8、通过BETWEEN绕过
如or ‘swords’ BETWEEN ‘rw’ AND ‘tw’
9、通过>或者<绕过
or ‘swords’ > ‘sw’
or ‘swords’ < ‘tw’
or 1<3
……
10、运用注释语句绕过
用/**/代替空格，如：UNION /**/ Select /**/user，pwd，from tbluser
用/**/分割敏感词，如：U/**/ NION /**/ SE/**/ LECT /**/user，pwd from tbluser
11、用HEX绕过，一般的IDS都无法检测出来
=hex(sysadmin)
=hex(db_owner)
另外，关于通用点的过滤方法，我们可以考虑采用赋值的方法，例如先声明一个变量a，然后把我们的指令赋值给a，然后调用变量a最终执行我们输入的命令。变量a可以是任何命令。如下：
declare @a sysname
select @a=
exec master.dbo.xp_cmdshell @a
效果 how.asp?id=1;declare%20@a% 20sysname%20select%20@a=7300730020002f
00610064006400%20exec%20master.dbo.xp_cmdshell%20@a;–
其中的 7300730020002f00610064006400 就是“net user angel pass /add”的意思。
⑧ 针对sql注入攻击，有哪些防范措施
SQL注入攻击的危害很大，而且防火墙很难对攻击行为进行拦截，主要的SQL注入攻击防范方法，具体有以下几个方面。
1、分级管理
对用户进行分级管理，严格控制用户的权限，对于普通用户，禁止给予数据库建立、删除、修改等相关权限，只有系统管理员才具有增、删、改、查的权限。
2、参数传值
程序员在书写SQL语言时，禁止将变量直接写入到SQL语句，必须通过设置相应的参数来传递相关的变量。从而抑制SQL注入。数据输入不能直接嵌入到查询语句中。同时要过滤输入的内容，过滤掉不安全的输入数据。或者采用参数传值的方式传递输入变量，这样可以最大程度防范SQL注入攻击。
3、基础过滤与二次过滤
SQL注入攻击前，入侵者通过修改参数提交and等特殊字符，判断是否存在漏洞，然后通过select、update等各种字符编写SQL注入语句。因此防范SQL注入要对用户输入进行检查，确保数据输入的安全性，在具体检查输入或提交的变量时，对于单引号、双引号、冒号等字符进行转换或者过滤，从而有效防止SQL注入。
当然危险字符有很多，在获取用户输入提交参数时，首先要进行基础过滤，然后根据程序的功能及用户输入的可能性进行二次过滤，以确保系统的安全性。
4、使用安全参数
SQL数据库为了有效抑制SQL注入攻击的影响。在进行SQLServer数据库设计时设置了专门的SQL安全参数。在程序编写时应尽量使用安全参数来杜绝注入式攻击，从而确保系统的安全性。
5、漏洞扫描
为了更有效地防范SQL注入攻击，作为系统管理除了设置有效的防范措施，更应该及时发现系统存在SQL攻击安全漏洞。系统管理员可以采购一些SQL漏洞扫描工具，通过专业的扫描工具，可以及时的扫描到系统存在的相应漏洞。
6、多层验证
现在的网站系统功能越来越庞大复杂。为确保系统的安全，访问者的数据输入必须经过严格的验证才能进入系统，验证没通过的输入直接被拒绝访问数据库，并且向上层系统发出错误提示信息。同时在客户端访问程序中验证访问者的相关输入信息，从而更有效的防止简单的SQL注入。但是如果多层验证中的下层如果验证数据通过，那么绕过客户端的攻击者就能够随意访问系统。因此在进行多层验证时，要每个层次相互配合，只有在客户端和系统端都进行有效的验证防护，才能更好地防范SQL注入攻击。
7、数据库信息加密
传统的加解密方法大致分为三种：对称加密、非对称加密、不可逆加密。
⑨ ASP.NET 实现SQL注入过滤
一 什么是SQL注入式攻击 所谓SQL注入式攻击 就是攻击者把SQL命令插入到Web表单的输入域或页面请求的查询字符串 欺骗服务器执行恶意的SQL命令 在某些表单中 用户输入的内容直接用来构造（或者影响）动态SQL命令 或作为存储过程的输入参数 这类表单特别容易受到SQL注入式攻击 常见的SQL注入式攻击过程类如 ⑴ 某个ASP NET Web应用有一个登录页面 这个登录页面控制着用户是否有权访问应用 它要求用户输入一个名称和密码 ⑵ 登录页面中输入的内容好尘将直接用来构造动态的SQL命令 或者直接用作存储过程的参数 下面是ASP NET应用构造查询的一个例子 System Text StringBuilder query = new System Text StringBuilder（ SELECT * from Users WHERE login = ） Append（txtLogin Text） Append（ AND password= ） Append（txtPassword Text） Append（ ） ⑶ 攻击者在用户名字和密码输入框中输入 或 = 之类的内容 ⑷ 用户输入的内容提交给服务器之后 服务器运行上猛袜清面的ASP NET代码构造出查询用户的SQL命令 但由于攻击者输入的内容非常特殊 所以最后得到的SQL命令变成 SELECT * from Users WHERE login = or = AND password = or = ⑸ 服务器执行查询或存储过程 将用户输入的身份信息和服务器中保存的身份信息进行对比 ⑹ 由于SQL命令实际上已被注入式攻击修改 已经不能真正验证用户身份 所以系统会错误地授权给攻击者 如果攻击者知道应用会将表单中输入的内容直接用于验证身份的查询 他就会尝试输入某些特殊的SQL字符串篡改查询改变其原来的功能 欺骗系统授予访问权限 枝前 系统环境不同 攻击者可能造成的损害也不同 这主要由应用访问数据库的安全权限决定 如果用户的帐户具有管理员或其他比较高级的权限 攻击者就可能对数据库的表执行各种他想要做的操作 包括添加 删除或更新数据 甚至可能直接删除表 二 如何防范 好在要防止ASP NET应用被SQL注入式攻击闯入并不是一件特别困难的事情 只要在利用表单输入的内容构造SQL命令之前 把所有输入内容过滤一番就可以了 过滤输入内容可以按多种方式进行⑴ 对于动态构造SQL查询的场合 可以使用下面的技术 第一 替换单引号 即把所有单独出现的单引号改成两个单引号 防止攻击者修改SQL命令的含义 再来看前面的例子 SELECT * from Users WHERE login = or = AND password = or = 显然会得到与 SELECT * from Users WHERE login = or = AND password = or = 不同的结果 第二 删除用户输入内容中的所有连字符 防止攻击者构造出类如 SELECT * from Users WHERE login = mas AND password = 之类的查询 因为这类查询的后半部分已经被注释掉 不再有效 攻击者只要知道一个合法的用户登录名称 根本不需要知道用户的密码就可以顺利获得访问权限 第三 对于用来执行查询的数据库帐户 限制其权限 用不同的用户帐户执行查询 插入 更新 删除操作 由于隔离了不同帐户可执行的操作 因而也就防止了原本用于执行SELECT命令的地方却被用于执行INSERT UPDATE或DELETE命令 ⑵ 用存储过程来执行所有的查询 SQL参数的传递方式将防止攻击者利用单引号和连字符实施攻击 此外 它还使得数据库权限可以限制到只允许特定的存储过程执行 所有的用户输入必须遵从被调用的存储过程的安全上下文 这样就很难再发生注入式攻击了 ⑶ 限制表单或查询字符串输入的长度 如果用户的登录名字最多只有 个字符 那么不要认可表单中输入的 个以上的字符 这将大大增加攻击者在SQL命令中插入有害代码的难度 ⑷ 检查用户输入的合法性 确信输入的内容只包含合法的数据 数据检查应当在客户端和服务器端都执行 之所以要执行服务器端验证 是为了弥补客户端验证机制脆弱的安全性 在客户端 攻击者完全有可能获得网页的源代码 修改验证合法性的脚本（或者直接删除脚本） 然后将非法内容通过修改后的表单提交给服务器 因此 要保证验证操作确实已经执行 唯一的办法就是在服务器端也执行验证 你可以使用许多内建的验证对象 例如RegularExpressionValidator 它们能够自动生成验证用的客户端脚本 当然你也可以插入服务器端的方法调用 如果找不到现成的验证对象 你可以通过CustomValidator自己创建一个 ⑸ 将用户登录名称 密码等数据加密保存 加密用户输入的数据 然后再将它与数据库中保存的数据比较 这相当于对用户输入的数据进行了 消毒 处理 用户输入的数据不再对数据库有任何特殊的意义 从而也就防止了攻击者注入SQL命令 System Web Security FormsAuthentication类有一个 非常适合于对输入数据进行消毒处理 ⑹ 检查提取数据的查询所返回的记录数量 如果程序只要求返回一个记录 但实际返回的记录却超过一行 那就当作出错处理
以上资料参考与 赛迪网资料 但是我觉得在我们的ASP NET程序里防止SQL 注入 首先应该尽量使用存储过程 关于使用存储过程的好处在这里就不展开讨论了 使用参数传递变量 最不妥当的方法就是认为判断SQL注入信息 尽管如此 可能日常开发中由于种种原因不能做的面面具道 存在各种各种的实际问题 现在是最近在一个项目中没有考虑SQL注入项目补救写的一个组件库 资料也参考来源与网络 实现很简单 下面是具体实现的源程序 using System; using System Text RegularExpressions; using System Web; namespace FSqlKeyWord …{ /**//// <summary> /// SqlKey 的摘要说明 /// </summary> public class SqlKey …{ private HttpRequest request; private const string StrKeyWord = @ select|insert|delete|from|count（|drop table|update|truncate|asc（|mid（|char（|xp_cmdshell|exec master|netlocalgroup administrators|:|net user| |or|and ; private const string StrRegex = @ [ |;| |/|（|）|[|]|}|{|%|@|*|!| ] ; public SqlKey（System Web HttpRequest _request） …{ // // TODO: 在此处添加构造函数逻辑 // this request = _request; } /**//// <summary> /// 只读属性 SQL关键字 /// </summary> public static string KeyWord …{ get …{ return StrKeyWord; } } /**//// <summary> /// 只读属性过滤特殊字符 /// </summary> public static string RegexString …{ get …{ return StrRegex; } } /**//// <summary> /// 检查URL参数中是否带有SQL注入可能关键字 /// </summary> /// <param name= _request >当前HttpRequest对象</param> /// <returns>存在SQL注入关键字true存在 false不存在</returns> public bool CheckRequestQuery（） …{ if （request QueryString Count != ） …{ //若URL中参数存在 逐个比较参数 for （int i = ; i < request QueryString Count; i++） …{ // 检查参数值是否合法 if （CheckKeyWord（request QueryString[i] ToString（））） …{ return true; } } } return false; } /**//// <summary> /// 检查提交表单中是否存在SQL注入可能关键字 /// </summary> /// <param name= _request >当前HttpRequest对象</param> /// <returns>存在SQL注入关键字true存在 false不存在</returns> public bool CheckRequestForm（） …{ if （request Form Count > ） …{ //获取提交的表单项不为 逐个比较参数 for （int i = ; i < request Form Count; i++） …{ //检查参数值是否合法 if （CheckKeyWord（request Form[i]）） …{ //存在SQL关键字 return true; } } } return false; } /**//// <summary> /// 静态方法 检查_sword是否包涵SQL关键字 /// </summary> /// <param name= _sWord >被检查的字符串</param> /// <returns>存在SQL关键字返回true 不存在返回false</returns> public static bool CheckKeyWord（string _sWord） …{ if （Regex IsMatch（_sWord StrKeyWord RegexOptions IgnoreCase） || Regex IsMatch（_sWord StrRegex）） return true; return false; } /**//// <summary> /// 反SQL注入 返回 无注入信息 否则返回错误处理 /// </summary> /// <returns>返回 无注入信息 否则返回错误处理</returns> public string CheckMessage（） …{ string msg = ; if （CheckRequestQuery（）） //CheckRequestQuery（） || CheckRequestForm（） …{ msg = <span style= font size: px; >非法操作！<br> ; msg += 操作IP: + request ServerVariables[ REMOTE_ADDR ] + <br> ; msg += 操作时间 + DateTime Now + <br> ; msg += 页面 + request ServerVariables[ URL ] ToLower（） + <br> ; msg += <a # onclick= history back（） >返回上一页</a></span> ; } return msg ToString（） } } } lishixin/Article/program/net/201311/11680