PHP防止SQL注入式攻击方法

2021-06-20 作者:未知   |   浏览(
1、 注入式攻击的种类

  3、 INVISION Power BOARD SQL注入脆弱性

  Invision Power Board是一个著名的论坛系统。2005年5月6号,在登录代码中发现了一处SQL注入脆弱性。其发现者为GulfTech Security Research的James Bercegay。

  这个登录查看如下所示:

$DB->query;

  其中,成员ID变量$mid和口令ID变量$pid被用下面两行代码从my_cookie函数中检索出:

$mid = intval);$pid = $std->my_getcookie;

  在此,my_cookie函数用下列语句从cookie中检索需要的变量:

return urldep;

  【注意】从该cookie返回的值根本没被处置。尽管$mid在用于查看之前被强制转换成一个整数,但$pid却维持不变。因此,它比较容易遭受大家前面所讨论的注入种类的攻击。

  因此,通过以如下方法修改my_cookie函数,这种脆弱性就会暴露出来:

if ) )

{

return $this->

clean_value);

}

else

{

return urldep;

  经过如此的改正之后,其中的重要变量在"通过"全局clean_value函数后被返回,而其它变量却没有进行检查。

  目前,既然大家大致知道了啥是SQL注入,它的注入原理与这种注入的脆弱程度,那样下面,让大家探讨怎么样有效地预防它。幸好,PHP为大家提供了丰富的资源,因此大家有充分的信心预言,一个经仔细地彻底地用大家所推荐的技术构建的应用程序将会从你的脚本中根本上消除任何可能性的SQL注入-通过在它可能导致任何损毁之前"清理"你的用户的数据来达成。

  可能存在很多不相同种类型的攻击动机,但乍看起来,好像存在更多的种类。这是很真实的-假如恶意用户发现了一个可以实行多个查看的方法的话。

  假如你的脚本正在实行一个SELECT指令,那样,攻击者可以强迫显示一个表格中的每一行记录-通过把一个比如"1=1"如此的条件注入到WHERE子句中,如下所示:

SELECT * FROM wines WHERE variety = 'lagrein' OR 1=1;'

  正如大家在前面所讨论的,这本身可能是非常有用的信息,由于它揭示了该表格的通常结构,与潜在地显示包含机密信息的记录。

  一条更新指令潜在地具备更直接的威胁。通过把其它属性放到SET子句中,一名攻击者可以修改目前被更新的记录中的任何字段,比如下面的例子(其中,注入部分以粗体显示):

UPDATE wines SET type='red','vintage'='9999' WHERE variety = 'lagrein'

  通过把一个比如1=1如此的恒真条件添加到一条更新指令的WHERE子句中,这种修改范围可以扩展到每一条记录,比如下面的例子(其中,注入部分以粗体显示):

UPDATE wines SET type='red','vintage'='9999 WHERE variety = 'lagrein' OR 1=1;'

  最危险的指令可能是DELETE-这是不难想像的。其注入技术与大家已经看到的相同-通过修改WHERE子句来扩展受影响的记录的范围,比如下面的例子(其中,注入部分以粗体显示):

DELETE FROM wines WHERE variety = 'lagrein' OR 1=1;'

  2、 多个查看注入

  多个查看注入将会加剧一个攻击者可能引起的潜在的损毁-通过允很多条破坏性指令包括在一个查看中。在用MySQL数据库时,攻击者通过把一个出人预料以外的终止符插入到查看中即可比较容易达成这一点-此时一个注入的引号标记期望变量的结尾;然后用一个分号终止该指令。目前,一个另外的攻击指令可能被添加到目前终止的原始指令的结尾。最后的破坏性查看可能看着如下所示:

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扩展负责管理的。幸好,默认状况下,它是不允许在一个查看中实行多个指令的;试图实行两个指令将会容易地致使失败-不设置任何错误,并且没生成任何输出信息。在这样的情况下,尽管PHP也只不过"安安分分"地达成其缺省行为,但确实可以保护你免于大部分容易的注入式攻击。

  PHP5中的新的mysqli扩展,就象mysql一样,内在地也不支持多个查看,不过却提供了一个mysqli_multi_query函数以支持你达成多查看-假如你确实想如此做的话。

  然而,对于SQLite-与PHP5绑定到一块的可嵌入的SQL数据库引擎状况更为可怕,因为其易于用而吸引了很多用户的关注。在有的状况下,SQLite缺省地允许如此的多指令查看,由于该数据库可以优化批查看,尤其是很有效的批INSERT语句处置。然而,假如查看的结果为你的脚本所用的话(比如在用一个SELECT语句检索记录的状况下),sqlite_query函数却不会允许实行多个查看。

相关文章