PHP防范SQL注入的基本方法
一个优秀的PHP程序员除了要能顺利的编写代码，还需要具备使程序处于安全环境下的能力。今天我们要向大家讲解的是有关PHP防范SQL注入的相关方法。
说到网站安全就不得不提到SQL注入（SQL Injection），如果你用过ASP，对SQL注入一定有比较深的理解，PHP的安全性相对较高，这是因为MYSQL4以下的版本不支持子语句，而且当php.ini里的magic_quotes_gpc 为On 时。
提交的变量中所有的' (单引号), " (双引号), \ (反斜线) and 空字符会自动转为含有反斜线的转义字符，给SQL注入带来不少的麻烦。
请看清楚：“麻烦”而已~这并不意味着PHP防范SQL注入，书中就讲到了利用改变注入语句的编码来绕过转义的方法，比如将SQL语句转成ASCII编码（类似：char(100,58,92,108,111,99,97,108,104,111,115,116…)这样的格式），或者转成16进制编码，甚至还有其他形式的编码，这样以来，转义过滤便被绕过去了，那么怎样防范呢：
1、打开magic_quotes_gpc或使用addslashes()函数
在新版本的PHP中，就算magic_quotes_gpc打开了，再使用addslashes()函数，也不会有冲突，但是为了更好的实现版本兼容，建议在使用转移函数前先检测magic_quotes_gpc状态，或者直接关掉，代码如下：
PHP防范SQL注入的代码
// 去除转义字符
function stripslashes_array($array) {
if (is_array($array)) {
foreach ($array as $k => $v) {
$array[$k] = stripslashes_array($v);
}
} else if (is_string($array)) {
$array = stripslashes($array);
}
return $array;
}
@set_magic_quotes_runtime(0);
// 判断 magic_quotes_gpc 状态
if (@get_magic_quotes_gpc()) {
$_GET = stripslashes_array($_GET);
$_POST = stripslashes_array($_POST);
$_COOKIE = stripslashes_array($_COOKIE);
}
去除magic_quotes_gpc的转义之后再使用addslashes函数，代码如下：
PHP防范SQL注入的代码
$keywords = addslashes($keywords);
$keywords = str_replace("_","\_",$keywords);//转义掉”_”
$keywords = str_replace("%","\%",$keywords);//转义掉”%”
后两个str_replace替换转义目的是防止黑客转换SQL编码进行攻击。
2、强制字符格式（类型）
在很多时候我们要用到类似xxx.php?id=xxx这样的URL，一般来说$id都是整型变量，为了防范攻击者把$id篡改成攻击语句，我们要尽量强制变量，代码如下：
PHP防范SQL注入的代码
$id=intval($_GET[‘id’]);
当然，还有其他的变量类型，如果有必要的话尽量强制一下格式。
3、SQL语句中包含变量加引号
这一点儿很简单，但也容易养成习惯，先来看看这两条SQL语句：
SQL代码
SELECT * FROM article WHERE articleid='$id'
SELECT * FROM article WHERE articleid=$id
两种写法在各种程序中都很普遍，但安全性是不同的，第一句由于把变量$id放在一对单引号中，这样使得我们所提交的变量都变成了字符串，即使包含了正确的SQL语句，也不会正常执行，而第二句不同，由于没有把变量放进单引号中，那我们所提交的一切，只要包含空格，那空格后的变量都会作为SQL语句执行，因此，我们要养成给SQL语句中变量加引号的习惯。
4、URL伪静态化
URL伪静态化也就是URL重写技术，像Discuz！一样，将所有的URL都rewrite成类似xxx-xxx-x.html格式，既有利于SEO，又达到了一定的安全性，也不失为一个好办法。但要想实现PHP防范SQL注入，前提是你得有一定的“正则”基础。
观察近来的一些安全事件及其后果，安全专家们已经得到一个结论，这些威胁主要是通过SQL注入造成的。虽然前面有许多文章讨论了SQL注入，但今天所讨论的内容也许可帮助你检查自己的服务器，并采取相应防范措施。 SQL注入攻击的种类 知彼知己，方可取胜。首先要清楚SQL注入攻击有哪些种类。 1.没有正确过滤转义字符 在用户的输入没有为转义字符过滤时，就会发生这种形式的注入式攻击，它会被传递给一个SQL语句。这样就会导致应用程序的终端用户对数据库上的语句实施操纵。比方说，下面的这行代码就会演示这种漏洞： statement := "SELECT * FROM users WHERE name = '" + userName + "';" 这种代码的设计目的是将一个特定的用户从其用户表中取出，但是，如果用户名被一个恶意的用户用一种特定的方式伪造，这个语句所执行的操作可能就不仅仅是代码的作者所期望的那样了。例如，将用户名变量(即username)设置为：a' or 't'='t，此时原始语句发生了变化：SELECT * FROM users WHERE name = 'a' OR 't'='t'; 如果这种代码被用于一个认证过程，那么这个例子就能够强迫选择一个合法的用户名，因为赋值't'='t永远是正确的。 在一些SQL服务器上，如在SQL Server中，任何一个SQL命令都可以通过这种方法被注入，包括执行多个语句。下面语句中的username的值将会导致删除“users”表，又可以从“data”表中选择所有的数据(实际上就是透露了每一个用户的信息)。 a';DROP TABLE users; SELECT * FROM data WHERE name LIKE '% 这就将最终的SQL语句变成下面这个样子： SELECT * FROM users WHERE name = 'a';DROP TABLE users; SELECT * FROM DATA WHERE name LIKE '%'; 其它的SQL执行不会将执行同样查询中的多个命令作为一项安全措施。这会防止攻击者注入完全独立的查询，不过却不会阻止攻击者修改查询。 2.Incorrect type handling 如果一个用户提供的字段并非一个强类型，或者没有实施类型强制，就会发生这种形式的攻击。当在一个SQL语句中使用一个数字字段时，如果程序员没有检查用户输入的合法性(是否为数字型)就会发生这种攻击。例如： statement := "SELECT * FROM data WHERE id = " + a_variable + ";" 从这个语句可以看出，作者希望a_variable是一个与“id”字段有关的数字。不过，如果终端用户选择一个字符串，就绕过了对转义字符的需要。例如，将a_variable设置为:1;DROP TABLE users，它会将“users”表从数据库中删除，SQL语句变成： SELECT * FROM DAT A WHERE id = 1;DROP TABLE users;
数据库SQL注入分类及防护思路 作者：安华金和思成 一. 背景 数据库凭借其强大的数据存储能力和卓越的数据处理性能，在各行各业的信息化建设中发挥着关键的作用。随着数据库在各行业的大规模应用，数据泄露事件也频繁发生，这就使数据库安全问题也日益凸显，逐渐变成用户越来越担心的问题。虽然数据库厂商已经做了许多有效的措施来尽量解决数据库存在的安全问题，但至今为止数据库的安全漏洞仍然不断增加。下图为近5年数据库漏洞数量图。 在数据库漏洞中最为常见的漏洞类型是SQL注入漏洞。安华金和数据库攻防实验室结合多年的实践结果总结出了数据库注入的分类分享给大家，以便大家对SQL注入型漏洞有一个更加全面的了解。 SQL注入漏洞不仅出现在WEB端，也出现在数据库的自定义或标准库的存储过程、函数、触发器中。数据库自身的SQL注入漏洞比WEB端的注入漏洞对数据库的威胁性更大。本文对SQL注入的分类是从数据库的角度来划分，不考虑WEB端的角度，这两者在分类上有着不同的角度。 首先在解释不同的数据库SQL注入漏洞之前先简要说明一下数据库攻击者能够进行SQL 注入的主要原理：SQL注入漏洞是用户在输入中混入了程序命令。最直接的例子就是攻击者
在正常的Web 页面中把自己的SQL 代码通过用户输入传输到相应的应用程序中,从而执行 一些非授权的SQL 代码,以达到修改、窃取或者破坏数据库信息的目的。SQL 注入攻击甚至可以帮组攻击者绕过用户认证机制，使其可以完全的操控远程服务器上的数据库。如果应用 程序使用一些用户输入的数据来构造动态的SQL语句去访问数据库，将可能遭受到SQL 注入攻击。同样的如果在代码中使用了存储过程，并且这些存储过程缺乏对用户输入的合理限 制也很容易发生SQL 注入。 二. SQL注入分类 2.1 注入途径分类 SQL注入漏洞按照注入的物理途径可以分成两大类：通过WEB端对数据库进行注入攻 击和直接访问数据库进行注入攻击。 直接访问数据库进行注入攻击是以数据库用户的身份直接连接数据库进行SQL注入攻击。在这种攻击方式中，攻击者可以通过SQL注入来执行SQL语句从而提高用户权限或者越权 执行。而那些在PL/SQL程序中在给用户授权的时候没有使用authidcurrent_user进行定义的存储过程、函数、触发器、程序块将更容易受到SQL注入攻击。 通过WEB应用程序的用户对数据库进行连接并进行SQL注入攻击。在这种类型的SQL 注入攻击中，攻击者多采用拼接语句的方法来改变查询的内容。获取该账号权限下的全部信息。
【转】Hibernate防止SQL注入 2009-05-14 13:10 今天读《Hibernate In Action》，看到有关的SQL中可能被注入单引号的问题 前阶段我做完了一个系统，如果在查询字段中输入单引号"'"，则会报错，这是因为输入的单引号和其他的sql组合在一起编程了一个新的sql，实际上这就是SQL注入漏洞，后来我在前台和后台都对输入的字符进行了判断。 今天看《Hibernate In Action》第七章7.1.2绑定参数时发现也提到了这一点，以下是我的简短的翻译： 永远也不要写这样的代码： String queryString = "from Item i where i.description like '" + searchString + "'"; List result = session.createQuery(queryString).list(); 如果用户输入:foo' and callSomeStoredProcedure() and 'bar' = 'bar，则你的程序在执行一个简单查询后，还会调用某个存储过程， 这样你的程序就开了一个安全漏洞，如果用户偶尔输入了一个单引号，你的程序就可能报错（我的程序就这样呀！）。 永远也不要把未经检查的用户输入的值直接传给数据库！ 幸运的时有一个简单的机制可以避免这种错误： JDBC在绑定参数时有一个安全机制，它可以准确的将那些需要转义的字符进行转义（escape）， 如上面的searchString，它被escape，不再作为一个控制字符了，而是作为被查询的匹配的字符串的一部分。（这里指的是prepared statement，而是用普通的statment不行，我试过）。 另外，如果我们使用参数绑定，还可以提高数据库的执行效率，prepared statement语句被编译一次后，被放在cache中，就不再需要编译，可以提高效率。 参数绑定有2种办法：使用positional parameter或者named parameter。 Hibernate支持JDBC样式的positional parameter（查询字符串中使用？），它同使用named parameter的效果一样（查询字符串中使用:）。 使用named parameter
前段时间，在很多博客和微博中暴漏出了12306铁道部网站的一些漏洞，作为这么大的一个项目，要说有漏洞也不是没可能，但其漏洞确是一些菜鸟级程序员才会犯的错误。其实sql注入漏洞就是一个。作为一个菜鸟小程序员，我对sql注入的东西了解的也不深入，所以抽出时间专门学习了一下。现在把学习成果分享给大家，希望可以帮助大家学习。下面我们就来看一下。 一、什么是sql注入呢？ 所谓SQL注入，就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL 命令，比如先前的很多影视网站泄露VIP会员密码大多就是通过WEB 表单递交查询字符暴出的，这类表单特别容易受到SQL注入式攻击．当应用程序使用输入内容来构造动态sql语句以访问数据库时，会发生sql 注入攻击。如果代码使用存储过程，而这些存储过程作为包含未筛选的用户输入的字符串来传递，也会发生sql注入。黑客通过SQL注入攻击可以拿到网站数据库的访问权限，之后他们就可以拿到网站数据库中所有的数据，恶意的黑客可以通过SQL注入功能篡改数据库中的数据甚至会把数据库中的数据毁坏掉。做为网络开发者的你对这种黑客行为恨之入骨，当然也有必要了解一下SQL注入这种功能方式的原理并学会如何通过代码来保护自己的网站数据库 二、sql注入产生原因
sql注入攻击是利用是指利用设计上的漏洞，在目标服务器上运行Sql 语句以及进行其他方式的攻击，动态生成Sql语句时没有对用户输入的数据进行验证是Sql注入攻击得逞的主要原因。对于java数据库连接JDBC而言，SQL注入攻击只对Statement有效，对PreparedStatement 是无效的，这是因为PreparedStatement不允许在不同的插入时间改变查询的逻辑结构。 如验证用户是否存在的SQL语句为： 用户名'and pswd='密码 如果在用户名字段中输入: 'or 1=1或是在密码字段中输入:'or 1=1 将绕过验证，但这种手段只对只对Statement有效，对PreparedStatement 无效。相对Statement有以下优点： 1.防注入攻击 2.多次运行速度快 3.防止数据库缓冲区溢出 4.代码的可读性可维护性好 这四点使得PreparedStatement成为访问数据库的语句对象的首选，缺点是灵活性不够好，有些场合还是必须使用Statement。 三、sql注入原理 下面我们来说一下sql注入原理，以使读者对sql注入攻击有一个感性的认识，至于其他攻击，原理是一致的。
SQL注入专题(防范+攻击)全手册 SQL注入是从正常的WWW端口访问，而且表面看起来跟一般的Web页面访问没什么区别，所以目前市面的防火墙都不会对SQL注入发出警报，如果管理员没查看IIS日志的习惯，可能被入侵很长时间都不会发觉。 随着B/S模式应用开发的发展，使用这种模式编写应用程序的程序员也越来越多。但是由于这个行业的入门门槛不高，程序员的水平及经验也参差不齐，相当大一部分程序员在编写代码的时候，没有对用户输入数据的合法性进行判断，使应用程序存在安全隐患。用户可以提交一段数据库查询代码，根据程序返回的结果，获得某些他想得知的数据，这就是所谓的SQL Injection，即SQL注入。SQL注入是从正常的WWW端口访问，而且表面看起来跟一般的Web页面访问没什么区别，所以目前市面的防火墙都不会对SQL注入发出警报，如果管理员没查看IIS日志的习惯，可能被入侵很长时间都不会发觉。 但是，SQL注入的手法相当灵活，在注入的时候会碰到很多意外的情况。能不能根据具体情况进行分析，构造巧妙的SQL语句，从而成功获取想要的数据，是高手与“菜鸟”的根本区别。 1楼:SQL注入漏洞全接触--入门篇 2楼:SQL注入漏洞全接触--进阶篇 3楼:SQL注入漏洞全接触--高级篇 4楼:SQL Server应用程序中的高级SQL注入 5楼:编写通用的ASP防SQL注入攻击程序 6楼:利用instr()函数防止SQL注入攻击 7楼:SQL注入攻击的原理及其防范措施 8楼:跨站式SQL注入技巧 9楼:防范Sql注入式攻击 10楼:Dreamweaver中sql注入式攻击的防范 11楼:PHP与SQL注入攻击 12楼:SQL注入攻击零距离 13楼:SQL注入技术和跨站脚本攻击的检测 14楼:菜鸟入门级：SQL注入攻击 15楼:三步堵死SQL注入漏洞 16楼:SQL注入实战---利用“dbo”获得SQL管理权限和系统权限 17楼:两个防SQL注入过滤代码 18楼:蓝雨设计整站SQL注入漏洞 19楼:SQL注入渗透某网络安全公司的网站全过程 20楼:sql注入防御 21楼:终极防范SQL注入漏洞 22楼:SQL注入与ASP木马上传 23楼:如何在SQL注入时保护数据库 24楼:天晨设计整站SQL注入漏洞
SQL注入及XSS(跨站脚本)攻击防御技术方案 SQL注入 、、什么是SQL注入 SQL注入：利用现有应用程序，将（恶意）的SQL命令注入到后台数据库引擎执行的能力，这是SQL注入的标准释义。 SQL注入利用的是正常的HTTP服务端口，表面上看来和正常的web访问没有区别，隐蔽性极强，不易被发现。 、、SQL注入的危害 SQL注入的主要危害包括： 1、未经授权状况下操作数据中的数据 2、恶意篡改网页内容 3、私自添加系统账号或是数据库使用者账号 4、网页挂木马。 、、SQL注入的方法 1.没有正确过滤转义字符 在用户的输入没有为转义字符过滤时，就会发生这种形式的注入式攻击，它会被传递 给一个SQL语句。这样就会导致应用程序的终端用户对数据库上的语句实施操纵比方 说，下面的这行代码就会演示这种漏洞： statement := "SELECT * FROM users WHERE name = '" + userName + "'; "
这种代码的设计目的是将一个特定的用户从其用户表中取出，但是，如果用户名被一个恶意的用户用一种特定的方式伪造，这个语句所执行的操作可能就不仅仅是代码的作者所期望的那样了。例如，将用户名变量(即username)设置为：a' or 't'='t，此时原始语句发生了变化： SELECT * FROM users WHERE name = 'a' OR 't'='t'; 如果这种代码被用于一个认证过程，那么这个例子就能够强迫选择一个合法的用户名，因为赋值't'='t永远是正确的。 在一些SQL服务器上，如在SQL Server中，任何一个SQL命令都可以通过这种方法被注入，包括执行多个语句。下面语句中的username的值将会导致删除“users”表，又可以从“data”表中选择所有的数据(实际上就是透露了每一个用户的信息)。 a'; DROP TABLE users; SELECT * FROM data WHERE name LIKE '% 这就将最终的SQL语句变成下面这个样子： SELECT * FROM users WHERE name = 'a'; DROP TABLE users; SELECT * FROM DATA WHERE name LIKE '%'; 其它的SQL执行不会将执行同样查询中的多个命令作为一项安全措施。这会防止攻击者注入完全独立的查询，不过却不会阻止攻击者修改查询。 2.Incorrect type handling 如果一个用户提供的字段并非一个强类型，或者没有实施类型强制，就会发生这种形式的攻击。当在一个SQL语句中使用一个数字字段时，如果程序员没有检
什么是SQL注入式攻击如何防范 一、什么是SQL注入式攻击？ 所谓SQL注入式攻击，就是攻击者把SQL命令插入到Web表单的输入域或页面 请求的查询字符串，欺骗服务器执行恶意的SQL命令。在某些表单中，用户输入的内容直接用来构造（或者影响）动态SQL命令，或作为存储过程的输入参数，这类表单特别容易受到SQL注入式攻击。常见的SQL注入式攻击过程类如： ⑴某个https://www.doczj.com/doc/6f7822671.html, Web应用有一个登录页面，这个登录页面控制着用户是否有权访问应用，它要求用户输入一个名称和密码。 ⑵登录页面中输入的内容将直接用来构造动态的SQL命令，或者直接用作存储过程的参数。下面是https://www.doczj.com/doc/6f7822671.html,应用构造查询的一个例子： System.Text.StringBuilder query = new System.Text.StringBuilder（"SELECT * from Users WHERE login = '"）。Append（txtLogin.Text）。Append（"' AND password='"）。Append（txtPassword.Text）。Append（"'"）； ⑶攻击者在用户名字和密码输入框中输入"'或'1'='1"之类的内容。 ⑷用户输入的内容提交给服务器之后，服务器运行上面的https://www.doczj.com/doc/6f7822671.html,代码构造出查询用户的SQL命令，但由于攻击者输入的内容非常特殊，所以最后得到的SQL 命令变成：SELECT * from Users WHERE login = '' or '1'='1' AND password = '' or '1'='1'. ⑸服务器执行查询或存储过程，将用户输入的身份信息和服务器中保存的身份信息进行对比。 ⑹由于SQL命令实际上已被注入式攻击修改，已经不能真正验证用户身份，所以系统会错误地授权给攻击者。 如果攻击者知道应用会将表单中输入的内容直接用于验证身份的查询，他就会尝试输入某些特殊的SQL字符串篡改查询改变其原来的功能，欺骗系统授予访问权限。 系统环境不同，攻击者可能造成的损害也不同，这主要由应用访问数据库的安全权限决定。如果用户的帐户具有管理员或其他比较高级的权限，攻击者就可能对数据库的表执行各种他想要做的操作，包括添加、删除或更新数据，甚至可能直接删除表。 二、如何防范？ 好在要防止https://www.doczj.com/doc/6f7822671.html,应用被SQL注入式攻击闯入并不是一件特别困难的事情，只要在利用表单输入的内容构造SQL命令之前，把所有输入内容过滤一番就可以了。过滤输入内容可以按多种方式进行。 ⑴对于动态构造SQL查询的场合，可以使用下面的技术： 第一：替换单引号，即把所有单独出现的单引号改成两个单引号，防止攻击者修改SQL命令的含义。再来看前面的例子，“SELECT * from Users WHERE login = ''' or
BFG 【2015】I：第021-1号 开发代码安全规范 防SQL注入和XSS跨站攻击代码编写规范修订历史 目录 概述 (2) 适用范围 (3) 一、第一类漏洞类型-SQL注入（SQL INJECTION）及规范 (3)
1.1名词解释： (3) 1.2经典案例说明： (3) 1.3代码实例分析： (6) 1.4防止SQL注入攻击的代码安全规范总结： (8) 二、第二类漏洞类型-XSS跨站脚本攻击及规范 (9) 2.1名词解释： (9) 2.2经典案例说明： (9) 2.3 防止XSS跨站脚本攻击的代码安全规范总结： (10) 三、安全操作实践 (11) 概述 在技术高速发展的今天，Web应用被广泛使用，伴随而来的是各种安全隐患，主要是编程人员的安全意识较淡薄，缺乏安全编程经验，上线前安全检测不全面。因此，给心怀不轨之人以机会，对公司和个人财产安全造成威胁。本规范希望给编程人员一个较清晰的安全概念，在代码编写时提高警惕。 第 2 页共 11 页
第 3 页 共 11 页 适用范围 xx 集团及其分子公司业务系统的所有开发人员，包括系统外包的第三方开发人员。 一、第一类漏洞类型-SQL 注入（SQL Injection ）及规范 1.1 名词解释： SQL 注入攻击：通过把SQL 命令插入到Web 表单递交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL 命令。 具体来说，它是利用现有应用程序，将（恶意）的SQL 命令注入到后台数据库引擎执行的能力，它可以通过在Web 表单中输入（恶意）SQL 语句得到一个存在安全漏洞的网站上的数据库，而不是按照设计者意图去执行SQL 语句。 1.2 经典案例说明： 例1：用户登录界面及标准输入格式： Web 与数据库连接调用方式：
SQL注入入侵防范技术措施 防止SQL注入，通常一个一个文件修改不仅麻烦而且还有漏掉的危险，下面我说一下如何从整个系统防止注入。 做到以下三步，相信你的程序就会比较安全了，而且对整个网站的维护也将变的简单。 一、数据验证类 parameterCheck.cs public class parameterCheck{ public static bool isEmail(string emailString){ return System.Text.RegularExpressions.Regex.IsMatch(emailString, "['\\w_-]+(\\. ['\\w_-]+)*@['\\w_-]+(\\.['\\w_-]+)*\\.[a-zA-Z]{2,4}"); } public static bool isInt(string intString){ return System.Text.RegularExpressions.Regex.IsMatch(intString ,"^(\\d{5}-\\d{4})| (\\d{5})$"); } public static bool isUSZip(string zipString){ return System.Text.RegularExpressions.Regex.IsMatch(zipString ,"^-[0-9]+$|^[0-9] +$"); } } 二、Web.config 在你的Web.config文件中，在下面增加一个标签，如下：
随着B/S模式应用开发的发展，使用这种模式编写应用程序的程序员也越来越多。但是由于这个行业的入门门槛不高，程序员的水平及经验也参差不齐，相当大一部分程序员在编写代码的时候，没有对用户输入数据的合法性进行判断，使应用程序存在安全隐患。用户可以提交一段数据库查询代码，根据程序返回的结果，获得某些他想得知的数据，这就是所谓的SQL Injection，即ＳＱＬ注入。 ＳＱＬ注入是从正常的WWW端口访问，而且表面看起来跟一般的Web页面访问没什么区别，所以目前市面的防火墙都不会对ＳＱＬ注入发出警报，如果管理员没查看IIS日志的习惯，可能被入侵很长时间都不会发觉。 但是，ＳＱＬ注入的手法相当灵活，在注入的时候会碰到很多意外的情况。能不能根据具体情况进行分析，构造巧妙的SQL语句，从而成功获取想要的数据，是高手与“菜鸟”的根本区别。 根据国情，国内的网站用ASP+Access或SQLServer的占70%以上，PHP+MySQ占L20%，其他的不足10%。在本文，我们从分入门、进阶至高级讲解一下ASP注入的方法及技巧，PHP 注入的文章由NB联盟的另一位朋友zwell撰写，希望对安全工作者和程序员都有用处。了解ASP注入的朋友也请不要跳过入门篇，因为部分人对注入的基本判断方法还存在误区。大家准备好了吗？Let's Go... 入门篇 如果你以前没试过ＳＱＬ注入的话，那么第一步先把IE菜单=>工具=>Internet选项=>高级=>显示友好HTTP 错误信息前面的勾去掉。否则，不论服务器返回什么错误，IE都只显示为HTTP 500服务器错误，不能获得更多的提示信息。 第一节、ＳＱＬ注入原理以下我们从一个网站https://www.doczj.com/doc/6f7822671.html,开始（注：本文发表前已征得该站站长同意，大部分都是真实数据）。在网站首页上，有名为“IE不能打开新窗口的多种解决方法”的链接，地址为：https://www.doczj.com/doc/6f7822671.html,/showdetail.asp?id=49，我们在这个地址后面加上单引号’，服务器会返回下面的错误提示：Microsoft JET Database Engine 错误'80040e14' 字符串的语法错误在查询表达式'ID=49'' 中。/showdetail.asp，行8 从这个错误提示我们能看出下面几点： 1. 网站使用的是Access数据库，通过JET引擎连接数据库，而不是通过ODBC。 2. 程序没有判断客户端提交的数据是否符合程序要求。 3. 该SQL语句所查询的表中有一名为ID的字段。从上面的例子我们可以知道，ＳＱＬ注入的原理，就是从客户端提交特殊的代码，从而收集程序及服务器的信息，从而获取你想到得到的资料。 第二节、判断能否进行ＳＱＬ注入看完第一节，有一些人会觉得：我也是经常这样测试能否注入的，这不是很简单吗？其实，这并不是最好的方法，为什么呢？ 首先，不一定每台服务器的IIS都返回具体错误提示给客户端，如果程序中加了cint(参数)之类语句的话，ＳＱＬ注入是不会成功的，但服务器同样会报错，具体提示信息为处理URL 时服务器上出错。请和系统管理员联络。 其次，部分对ＳＱＬ注入有一点了解的程序员，认为只要把单引号过滤掉就安全了，这种情况不为少数，如果你用单引号测试，是测不到注入点的 那么，什么样的测试方法才是比较准确呢？答案如下：①https://www.doczj.com/doc/6f7822671.html,/showdetail.asp?id=49 ②https://www.doczj.com/doc/6f7822671.html,/showdetail.asp?id=49 ;and 1=1 ③https://www.doczj.com/doc/6f7822671.html,/showdetail.asp?id=49 ;and 1=2 这就是经典的1=1、1=2测试法了，怎么判断呢？看看上面三个网址返回的结果就知道了：可以注入的表现：①正常显示（这是必然的，不然就是程序有错误了）②正常显示，内容基本与①相同③提
如何防范SQL注入漏洞，下面给出4个函数，足够你抵挡一切SQL注入漏洞！读懂代码，你就能融会贯通。 注意要对所有的request对象进行过滤：包括 request.cookie, request.Server Variables 等等容易被忽视的对象： function killn(byval s1) '过滤数值型参数 if not isnumeric(s1) then killn=0 else if s1<0 or s1>2147483647 then killn=0 else killn=clng(s1) end if end if end function function killc(byval s1) 过滤货币型参数 if not isnumeric(s1) then killc=0 else killc=formatnumber(s1,2,-1,0,0) end if end function function killw(byval s1) '过滤字符型参数 if len(s1)=0 then killw="" else killw=trim(replace(s1,"'","")) end if end function function killbad(byval s1) 过滤所有危险字符，包括跨站脚本 If len(s1) = 0 then killbad="" else killbad = trim(replace(replace(replace(replace (replace(replace(replace(replace(s1,Chr(10), "
"), Chr(34), """), ">", ">"), "<", "<"), "&", "&"), chr(39),"'"),chr(32)," "),chr(13),""))
PHP防范SQL注入的基本方法 一个优秀的PHP程序员除了要能顺利的编写代码，还需要具备使程序处于安全环境下的能力。今天我们要向大家讲解的是有关PHP防范SQL注入的相关方法。 说到网站安全就不得不提到SQL注入（SQL Injection），如果你用过ASP，对SQL注入一定有比较深的理解，PHP的安全性相对较高，这是因为MYSQL4以下的版本不支持子语句，而且当php.ini里的magic_quotes_gpc 为On 时。 提交的变量中所有的' (单引号), " (双引号), \ (反斜线) and 空字符会自动转为含有反斜线的转义字符，给SQL注入带来不少的麻烦。 请看清楚：“麻烦”而已~这并不意味着PHP防范SQL注入，书中就讲到了利用改变注入语句的编码来绕过转义的方法，比如将SQL语句转成ASCII编码（类似：char(100,58,92,108,111,99,97,108,104,111,115,116…)这样的格式），或者转成16进制编码，甚至还有其他形式的编码，这样以来，转义过滤便被绕过去了，那么怎样防范呢： 1、打开magic_quotes_gpc或使用addslashes()函数 在新版本的PHP中，就算magic_quotes_gpc打开了，再使用addslashes()函数，也不会有冲突，但是为了更好的实现版本兼容，建议在使用转移函数前先检测magic_quotes_gpc状态，或者直接关掉，代码如下： PHP防范SQL注入的代码 // 去除转义字符 function stripslashes_array($array) { if (is_array($array)) { foreach ($array as $k => $v) { $array[$k] = stripslashes_array($v);
论文编码：WZ201511 摘要 随着计算机网络的发展，Web应用程序得到极为广泛的应用，其自身的安全也面临越来越多的威胁，结构化查询语言（SQL）注入攻击也是目前Web应用程序面临的主要安全威胁之一，因此对SQL注入攻击应用现状与防御对策对于理解和加强Web应用程序的安全具有十分重要的意义。 SQL注入攻击是黑客对数据库进行攻击的常用手段之一。随着B/S模式应用开发的发展，使用这种模式编写应用程序的程序员也越来越多。但是由于程序员的水平及经验也参差不齐，相当大一部分程序员在编写代码的时候，没有对用户输入数据的合法性进行判断，使应用程序存在安全隐患。用户可以提交一段数据库查询代码，根据程序返回的结果，获得某些他想得知的数据，这就是所谓的SQL Injection，即SQL注入。 本文所论述的内容主要是对于在现存的群体结构中，对于SQL诸如攻击的应用现状的一些了解，以及对于减小SQL注入攻击所造成的危害，降低WEB系统的安全威胁的一些防御对策，对于提高web程序质量具有重要的意义。 关键词：注入攻击应用现状防御对策网络管理
SQL注入攻击应用现状与防御对策的调研报告 ABSTRACT Title: SQL injection attack and defense With the development of computer networks, web applications extremely wide range of applications, its security is also facing increasing threats and Structured Query Language (SQL) injection attacks is facing web application security threats SQL injection attack and defense is of great significance for the understanding and enhance the security of web applications. SQL injection attacks are one of the common means of hacker attacks on the database. With the development of the B / S mode application development, more and more programmers to write applications that use this model. However, due to the uneven level and experience of the programmers, a large part of the programmer when writing code, not the legitimacy of the user input data to judge, to make the application a security risk. Users can submit a database query code, according to the procedure to return the results, get some data he would like to know, This is known as SQL Injection, namely SQL injection. Expounds the main content of this article is for the existing population structure of SQL, such as the present situation of the application of attack for some of the understanding, as well as reduce SQL injection attacks caused harm, some prevention measures to reduce WEB system security threat, has the vital significance to improve the quality of WEB application. Key words: Injection attacks, Application status, Defense countermeasure，Network management
2008-10-14 SQL注入攻击及其防范浅谈 SQL注入攻击 SQL注入攻击的基本原理，是从客户端合法接口提交特殊的非法代码，让其注入到服务器端执行业务的SQL中去，进而改变SQL语句的原有逻辑和影响服务器端正常业务的处理。 SQL注入攻击是Web应用中一个重要的安全问题，虽然Java具备较高的安全性，但如果开发人员不注意，也有可能留下安全隐患，请看示例： 执行验证的SQL语句 现有一个Login页面用来控制WebApp的入口，用户想要进入只有输入“用户名”和“密码”，负责用户登录处理的Servlet接受到请求后，将看数据表usertable中是否存在这个用户名和密码，如果存在则让其进入，否则拒绝，进行验证的SQL语句如下： select count ( * ) from usertable where name ='用户名'and pswd ='密码… 执行完这条SQL语句后，如果记录数等于零说明在usertable表找不到用户名和密码对应的记录，应该拒绝；如果记录数大于零则说明能在usertable表中找到对应的记录，应予放行。 如果用户进行SQL注入则可使验证无效 如果用户通过某种途径知道或是猜测出了验证SQL语句的逻辑，他就有可能在表单中输入特殊字符改变SQL原有的逻辑，比如在名称文本框中输入“… or ?1…=?1… or ?1…=?1”或是在密码文本框中输入“1… or ?1…=?1”，SQL语句将会变成： 1 . select count ( * ) from usertable where name =''or'1'='1'or'1'='1 'an d pswd ='' 2 . select count ( * ) from usertable where name =''and pswd ='1'or'1'='1' 明显，or和单引号的加入使得where后的条件始终是true原有的验证完全无效了。 使用正则表达式屏蔽特殊字符 使用SQL注入攻击多在特殊字符上下手脚，如“?”，“*”，“/” ,”--”等，如果用正则表达式限制特殊字符输入，这些手段将没有效果。下面的代码将阻止含有特殊字符的请求。 if (Pattern.matches( " \\w+ " , name) == false || Pattern.matches( " \\w+ " , pswd) == false ) { //返回login界面 request.setAttribute( " feedbackMsg " , " 用户名和密码不允许包括特殊字符 " ); RequestDispatcher dispatcher = request.getRequestDispatcher( " /web/page/login1.jsp? curr=0 " ); dispatcher.forward(request, response); return ; } 使用PreparedStatement代替Statement
避免SQL注入三大方法 要说SQL注入还要从看.NET视频开始说起，听说在程序开发过程中，我们经常会遇到SQL 注入问题，也就是指令隐码攻击。具体的原理到底是怎么回事儿，查了些资料好像涉及到了编译原理，也没能够看明白，只是视频中讲到了这三种方法是经常用来避免SQL注入最常用的方法，于是查些资料希望能对现学的知识有一定的了解。下面是对这三种方法具体如何使用的一个简单的介绍。 一、存储程序 在学习数据库视频的时候接触过，它是存储在数据库中的一些事先编译好的指令。在用的时候不用重新编写，直接调用就好了。所以，使用它可以大大提高程序的执行效率。 那么，如何创建一个存储程序并使用它呢？这是我们今天要解决的问题。 1.创建过程 可编程性——下拉菜单——存储过程——右键——查询菜单———指定模板参数的值——新建查询——输入语句——查询菜单中的分析检查语法是否正确——执行 2.具体创建语法 在创建存储程序时，为了应对各种变换的数据，通常会涉及到带参数的存储程序，其中参数用@来表示。 Create Procedure procedurename[:number] --[:number]表示一组存储程序中的第几个，如果只有一个，此参数可忽略 [@parameter data_type] [default] [OUTPUT] --@parameter表示存储过程中的参数，default 表示默认值，OUTPUT表示输出值即输出值as SqlStatement --[]代表可选参数 3.具体执行过程 exec[ute] procedurename [参数] 举例： --创建 CreateProcedure scores @score1smallint，@score2smallint，@score3smallint，@score4smallint，@score5smallint，@myAvgsmallint Output --Output可用return来代替As select @myAvg=(@score1+@score2+@score3+@score4+@score5)/5 --调用过程 Declare@avgscore smallint --将输出结果放在avgscore中 Execavgscore Output 5,6,7,8,9, --带有参数的存储过程调用时，必须加上Output关键字，否则SQL会当做参数来对待 小结：存储程序的创建可分为带参数和不带参数，以及含有默认值和输出值得存储程序，但是它们的使用原理是一样的。只是带输出值得存储程序在调用过程中要使用关键字Output 来对要输出的变量进行声明，否则SQL会将它当做参数来处理。 注意：创建存储程序后，我们可以在编写程序时，直接调用存储程序的名称来代替复杂的查询语句： strSQL="select ............;" strSQL="Execute procedureName;" 二、参数化SQL 是指在设计与数据库链接并访问数据时，在需要填入数值或数据的地方，使用参数(Parameter) 来给值，用@或？来表示参数。 在使用参数化查询的情况下，数据库服务器不会将参数的内容视为SQL指令的一部份来处理，而是在数据库完成SQL 指令的编译后，才套用参数运行，因此就算参数中含有恶意的指令，
如果用户输入的是直接插入到一个SQL语句中的查询，应用程序会很容易受到SQL注入，例如下面的例子: 复制代码代码如下: $unsafe_variable = $_POST['user_input']; mysql_query("INSERT INTO table (column) VALUES ('" . $unsafe_variable . "')"); 这是因为用户可以输入类似VALUE"); DROP TABLE表; - ，使查询变成： 复制代码代码如下: INSERT INTO table (column) VALUES('VALUE'); DROP TABLE table;' 我们应该怎么防止这种情况呢?下面我们来看看Theo的回答 使用预备义语句和参数化查询。对于带有任何参数的sql语句都会被发送到数据库服务器，并被解析！对于攻击者想要恶意注入sql是不可能的！ 实现这一目标基本上有两种选择： 1.使用PDO(PHP Data Objects ) 复制代码代码如下: $stmt = $pdo->prepare('SELECT * FROM employees WHERE name = :name'); $stmt->execute(array(':name' => $name)); foreach ($stmt as $row) { // do something with $row } 2.使用mysqli 复制代码代码如下: $stmt = $dbConnection->prepare('SELECT * FROM employees WHERE name = ?'); $stmt->bind_param('s', $name); $stmt->execute(); $result = $stmt->get_result(); while ($row = $result->fetch_assoc()) { // do something with $row }