保护我的网站答案

【问题标题】：Securing my site保护我的网站
【发布时间】：2011-11-23 06:37:02
【问题描述】：

我正在使用w3af 审核我的网站。

它说它在我的网站上发现了几个问题，但我怀疑情况是否真的如此。

其中一个问题是：

URL：http://localhost/en/login 容易受到跨站请求伪造的攻击。它允许攻击者在向服务器发送数据时将方法从 POST 转换为 GET。

我很确定它不容易受到 csrf 攻击，因为我在表单中使用了 crsf 保护（带有被检查的令牌的字段）。

所以我想知道这条消息是关于什么的：

它允许攻击者在向服务器发送数据时将方法从 POST 转换为 GET。

我不在乎攻击者是否能够从POST 切换到GET，还是我可以？

如果我这样做，你能解释一下我为什么这样做吗？如何利用它？

【问题讨论】：

您是否在该表单中使用 $_REQUEST，而不是 _POST？
@MarcB：是的，我是。但我不明白这将如何被利用（考虑到 csrf 预防领域）。
@Macmade：你能解释一下我为什么关心它吗？
@peehaa：攻击允许 GET 输入的登录表单要容易得多。考虑一下有人发布了一个恶意的 FB 应用程序，该应用程序承诺 meme-du-jour 并输入<img src="yoursite.com/login.php?user=xxx&password=yyy"> 你会让整个 FB 潮流都撞上你的前门。
为了完美，您可以返回 403 Forbidden 用于 CSRF 检测或 401 Unauthorized 用于登录质询响应。响应主体仍然可以是用户友好的。例如。 CSRF 响应可以解释该请求看起来是不请自来的（我们系统的 CSRF 响应是一个表单字段验证组件，因此所有表单字段都保留供用户查看），并且 401 响应应该是登录表单。在检查 HTTP 日志文件时，使用清晰的状态代码和结构良好、有意义的 URL 有很大帮助。

【解决方案1】：

从没有使用 w3af 经验的角度来看，我认为它有一些非常基本的规则写入其中，它会检查这些规则并报告它们。

在这种情况下，它可能会检查您是否使用了$_REQUEST 而不是$_POST 或$_GET，然后在发现时报告错误，无论您为保护这一点付出了多少努力。

每个人都会以不同的方式编写代码，因此让软件能够理解代码的上下文将是一项了不起的成就，而且可能超出了这个人的智能。这并不是对软件的攻击，但老实说，如果我想出了一些可以理解其他人代码的上下文和意图的程序，我不会在 sourceforge 上放弃它：p

这有关系吗？可能取决于您对网站的保护程度（参见上面 Marc B 的 (+1) 评论）。

-- 编辑--

通过使用$_REQUEST 而不是指定$_POST 或$_GET，您已将自己置于容易关闭的攻击区域。不仅如此，$_REQUEST 还包括$_COOKIE。这已经覆盖here，而不是我复制别人的答案。

【讨论】：

告诉我为什么 +1，因为我有 csrf 保护内置......我不明白。另请参阅我对 Marc B 评论的评论。当 csrf 保护到位时，如何利用它。还是我在这里遗漏了一些巨大的东西（也可能是这种情况。有时会发生:)）
哦@PeeHaa 顺便为 w3af +1。刚看了一下，看起来非常棒。
我认为这是有道理的。它测试它是否也可以使用GET 发送变量。但我得出的结论是，我对我来说并不重要，因为我有 csrf 保护。关于$_COOKIE 变量的精彩编辑供其他人阅读。尽管我总是更改 GPC 的顺序并确保我的 cookie 有一个不错的前缀以防万一。我曾经遇到过这个问题，这是一个很好的补充供其他人阅读。
还可以查看我在@LeeKowalkowski 的评论以获取不错的渗透测试者名单
这个话题是我如此喜欢这个网站的原因；每个人都会学到一些东西：D