时间:2021-07-01 10:21:17 帮助过:10人阅读
输出信息。在这种情况下,尽管PHP也只是"规规矩矩"地实现其缺省行为,但是确实能够保护你免于大多数简单的注入式攻击。
SELECT * FROM wines WHERE variety = 'lagrein';
GRANT ALL ON *.* TO 'BadGuy@%' IDENTIFIED BY 'gotcha';'
这个注入将创建一个新的用户BadGuy并赋予其网络特权(在所有的表格上具有所有的特权);其中,还有一个"不祥"的口令被加入到这个简单的SELECT语句中。如果你遵循我们在以前文章中的建议-严格限制该过程用户的特权,那么,这应该无法工作,因为web服务器守护程序不再拥有你撤回的GRANT特权。但是从理论上讲,这样的一个攻击可能给予BadGuy自由权力来实现他对你的数据库的任何操作。
至于这样的一个多查询是否会被MySQL服务器处理,结论并不唯一。这其中的一些原因可能是由于不同版本的MySQL所致,但是大多数情况却是由于多查询存在的方式所致。MySQL的监视程序完全允许这样的一个查询。常用的MySQL GUI-phpMyAdmin,在最终查询之前会复制出以前所有的内容,并且仅仅这样做。
但是,大多数的在一个注入上下文中的多查询都是由PHP的mysql扩展负责管理的。幸好,默认情况下,它是不允许在一个查询中执行多个指令的;试图执行两个指令(例如上面所示的注入)将会简单地导致失败-不设置任何错误,并且没有生成任何
$mid = intval($std->my_getcookie('member_id'));
$pid = $std->my_getcookie('pass_hash');
在此,my_cookie()函数使用下列语句从cookie中检索要求的变量:
return urldecode($_COOKIE[$ibforums->vars['cookie_id'].$name]);
【注意】从该cookie返回的值根本没有被处理。尽管$mid在使用于查询之前被强制转换成一个整数,但是$pid却保持不变。因此,它很容易遭受我们前面所讨论的注入类型的攻击。
因此,通过以如下方式修改my_cookie()函数,这种脆弱性就会暴露出来:
代码如下:
if ( ! in_array( $name,array('topicsread', 'forum_read','collapseprefs') ) )
{
return $this->
clean_value(urldecode($_COOKIE[$ibforums->vars['cookie_id'].$name]));
}
else
{
return urldecode($_COOKIE[$ibforums->vars['cookie_id'].$name]);
}
经过这样的改正之后,其中的关键变量在"通过"全局clean_value()函数后被返回,而其它变量却未进行检查。
现在,既然我们大致了解了什么是SQL注入,它的注入原理以及这种注入的脆弱程度,那么接下来,让我们探讨如何有效地预防它。幸好,PHP为我们提供了丰富的资源,因此我们有充分的信心预言,一个经仔细地彻底地使用我们所推荐的技术构建的应用程序将会从你的脚本中根本上消除任何可能性的SQL注入-通过在它可能造成任何损坏之前"清理"你的用户的数据来实现。
四、 界定你的查询中的每一个值
我们推荐,你确保界定了你的查询中的每一个值。字符串值首当其冲,以及那些你通常期望应该使用"单"(而不是"双")引号的内容。一方面,如果你使用双引号来允许PHP在字符串内的变量替代,这样可以使得输入查询更为容易些;另一方面,这(无可否认,只是极少量地)也会减少以后PHP代码的分析工作。
下面,让我们使用我们一开始使用的那个非注入式查询来说明这个问题:
SELECT * FROM wines WHERE variety = 'lagrein'
或以PHP语句表达为:
$query = "SELECT * FROM wines WHERE variety = '$variety'";
从技术上讲,引号对于数字值来说是不需要使用的。但是,如果你并不介意用引号把例如葡萄酒这样的一个域相应的一个值括起来并且如果你的用户把一个空值输入到你的表单中的话,那么,你会看到一个类似下面的查询:
SELECT * FROM wines WHERE vintage =
当然,这个查询从语法上讲是无效的;但是,下面的语法却是有效的:
SELECT * FROM wines WHERE vintage = ''
第二个查询将(大概)不会返回任何果,但是至少它不会返回一个错误消息。
五、 检查用户提交的值的类型
从前面的讨论中我们看到,迄今为止,SQL注入的主要来源往往出在一个意料之外的表单入口上。然而,当你经由一个表单向用户提供机会提交某些值时,你应该有相当的优势来确
定你想取得什么样的输入内容-这可以使得我们比较容易地检查用户入口的有效性。在以前的文章中,我们已经讨论过这样的校验问题;所以,在此,我们仅简单地总结当时我们讨论的要点。如果你正在期望一个数字,那么你可以使用下面这些技术之一来确保你得到的真正是一个数字类型:
· 使用is_int()函数(或is_integer()或is_long())。
· 使用gettype()函数。
· 使用intval()函数。
· 使用settype()函数。
为了检查用户输入内容的长度,你可以使用strlen()函数。为了检查一个期望的时间或日期是否有效,你可以使用strtotime()函数。它几乎一定能够确保一位用户的入口中没有包含分号字符(除非标点符号可以被合法地包括在内)。你可以借助于strpos()函数容易地实现这一点,如下所示:
if( strpos( $variety, ';' ) ) exit ( "$variety is an invalid value for variety!" );
正如我们在前面所提到的,只要你仔细分析你的用户输入期望,那么,你应该能够很容易地检查出其中存在的许多问题。
六、 从你的查询中滤去每一个可疑字符
尽管在以前的文章中,我们已经讨论过如何过滤掉危险字符的问题;但是在此,还是让我们再次简单地强调并归纳一下这个问题:
· 不要使用magic_quotes_gpc指令或它的"幕后搭挡"-addslashes()函数,此函数在应用程序开发中是被限制使用的,并且此函数还要求使用额外的步骤-使用stripslashes()函数。
· 相比之下,mysql_real_escape_string()函数更为常用,但是也有它自己的缺点。http://www.bkjia.com/PHPjc/322927.htmlwww.bkjia.comtruehttp://www.bkjia.com/PHPjc/322927.htmlTechArticle一、 注入式攻击的类型 可能存在许多不同类型的攻击动机,但是乍看上去,似乎存在更多的类型。这是非常真实的-如果恶意用户发现了一...