在不需要用户登录的 POST 表单中，我是否面临 CSRF 攻击的风险? [英] Am I under risk of CSRF attacks in a POST form that doesn't require the user to be logged in?

问题描述

我在这里可能完全是个菜鸟，但我仍然不确定 CSRF(跨站点请求伪造)攻击究竟是什么.那么让我们来看看三种情况...

I'm probably being a total noob here, but I'm still uncertain about what a CSRF (Cross-Site Request Forgery) attack is exactly. So lets look at three situations...

1) 我有一个 POST 表单，用于编辑我网站上的数据.我希望这些数据仅被登录的用户编辑.

1) I have a POST form that I use to edit data on my site. I want this data to be edited only by users that are logged in.

2) 我有一个站点，登录的用户和访客都可以使用它.网站的部分内容仅供登录用户使用，但也有可供所有用户使用的 POST 表单 - 匿名而非匿名(例如标准联系表单).是否应该保护联系表单免受 CSRF 攻击?

2) I have a site, which can be used by both users who are logged in as well as guests. Parts of the site are for logged in users only, but there are also POST forms that can be used by all users - anonymous and not (for example a standard contact form). Should the contact form be safeguarded against CSRF attacks?

3) 我有一个根本没有身份验证系统的站点(好吧，也许这不切实际，所以可以说它有一个管理站点，它与其余站点分开，并且管理部分得到了适当的保护).该网站的主要部分仅供匿名用户使用.上面的POST表单需要保护吗?

3) I have a site which doesn't have an authentication system at all (well, perhaps that's unrealistic, so lets say it has an admin site which is separate from the rest of it and the admin part is properly safeguarded). The main part of the site is only used by anonymous users. Do the POST forms on it need to be safeguarded?

在 1) 的情况下，答案显然是肯定的.但在 2 和 3 的情况下，我不知道(而且 2 和 3 之间的差异是否显着?).

In the case of 1) the answer is clearly yes. But in the case of 2 and 3 I don't know (and is the difference between 2 and 3 even significant?).

推荐答案

CSRFa> 每当针对您网站的恶意 HTML 或 JavaScript 被嵌入到另一个 HTML 页面(或电子邮件)中并成功执行时.

There's means of CSRF whenever malicious HTML or JavaScript which is targeted on your website is been embedded in another HTML page (or an email message) which is been successfully executed.

一个例子是以下内容，它被放置在另一个网页中，该网页在继续之前无辜地询问您的姓名和年龄:

An example is the following which is been placed in another webpage which innocently asks for your name and age before proceeding:

<form action="http://yoursite.com/transferfunds" method="post">
    Your name: <input type="text"><br>
    Your age: <input type="text"><br>
    <input type="submit">
    <input type="hidden" name="amount" value="1000">
    <input type="hidden" name="toaccount" value="12345678">
</form>

请注意，该操作指向您的网站，并且隐藏的输入包含所需的 POST 信息.此示例将尝试将 1000(任何货币)的资金转移到帐号 12345678.如果您需要在表单上登录并实际检查它，那么当然只有在不知情的用户有最近登录了您的网站，但尚未注销，或者会话尚未过期.

Note that the action points to your website and that the hidden inputs contains the needed POST information. This example will try to transfer a fund of 1000 (in whatever currency) to account number 12345678. If you require a login on your form and also actually checks on that, then the above will of course only be successfully executed if the unaware user has recently logged in your website, but not logged out yet, or the session is not expired yet.

为了防止这种情况发生，最好的办法是向表单添加基于请求的令牌并在服务器端对其进行验证.IE.生成一个长的、唯一的、无法猜测的随机字符串，您将其存储在会话中并作为表单的 元素嵌入.提交表单后，将提交的令牌值与会话中的令牌值进行比较(并立即删除会话中的令牌值).要更进一步，请使用 CAPTCHA.

To prevent that to happen, your best bet is to add a request based token to the form and validate it in the server side. I.e. generate a long, unique and impossible-to-guess random string which you store in the session and embed as <input type="hidden"> element of the form. When the form is submitted, compare the submitted token value with the one already in session (and immediately remove the one in session). To go a step further, make use of a CAPTCHA.

在您的特定情况下，我认为您实际上更担心 XSS，这是 CSRF 的对立面，但反过来也可以是 CSRF 的来源.XSS 的一个例子是当用户在输入字段中输入以下内容时，该字段迟早会在同一网站上重新显示:

In your particular case, I think you're actually more worrying about XSS, which is an opposite of CSRF, but which in turn can also be a source for CSRF. An example of XSS is when the user enters the following in an input field which is going to be redisplayed sooner or later at the same website:

<form name="delete" action="admin/deleteusers" method="post"></form>
<script>document.form.delete.submit();</script>

每当您 - 作为管理员 - 查看带有(不可见！)表单和脚本的评论页面时，它将成功执行.

Whenever you -as being the administrator- views the page with the comment with the (invisible!) form and script inside, then it will be successfully executed.

防止 XSS 其实很容易.在网页上显示它们之前，只需 HTML 转义任何用户控制的输入(即请求 URL、请求标头、请求参数和请求正文).在 PHP 中，您可以使用 htmlspecialchars() 来实现此目的，在 Java/JSP 中，您可以使用 JSTL fn:escapeXml().这样在每个<下将被转换为<和>到>> 这将使任何输入的 HTML/JS 将按原样显示，因此无法执行.

Preventing XSS is actually quite easy. Just HTML-escape any user-controlled input (i.e. request URL, request headers, request parameters and request body) prior to displaying them at the webpage. In PHP you can use htmlspecialchars() for this and in Java/JSP the JSTL fn:escapeXml(). This way under each the < will be converted to < and > to > which will make that any entered HTML/JS will be displayed literally as-is and thus can't be executed.

这篇关于在不需要用户登录的 POST 表单中，我是否面临 CSRF 攻击的风险?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！