我是否处于不需要用户登录的POST形式的CSRF攻击风险中？ [英] Am I under risk of CSRF attacks in a POST form that doesn't require the user to be logged in?

问题描述

我在这里可能完全是菜鸟，但是我仍然不确定CSRF（跨站请求伪造）攻击的确切含义。因此，让我们看一下三种情况...

1）我有一个POST表单，用于编辑网站上的数据。我希望已登录的用户仅对这些数据进行编辑。

2）我有一个站点，两个站点都可以使用登录的用户和访客。该网站的部分内容仅适用于已登录的用户，但也有可供所有用户使用的POST表单-匿名而不是匿名（例如，标准联系表单）。应该保护联系表单免受CSRF攻击吗？

3）我有一个根本没有身份验证系统的网站（嗯，也许那是不现实的，所以让我们说它有一个与其他网站分开的管理网站，并且管理部分得到了适当的保护）。该网站的主要部分仅由匿名用户使用。

在1）的情况下，答案显然是肯定的。但是在2和3的情况下，我不知道（2和3之间的差异甚至还很明显吗？）。

解决方案

只要针对您的恶意HTML或JavaScript，就有 CSRF 的方式网站已嵌入成功执行的另一个 HTML页面（或电子邮件）中。

例如随后将其放置在另一个网页上，该网页无害地询问您的姓名和年龄，然后再继续：

 < form action = http ：//yoursite.com/transferfunds method = post> 
您的姓名：< input type = text>< br> 
您的年龄：< 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。如果您需要在表单上登录并进行实际检查，则只有在不知道用户拥有以下内容的情况下，以上内容才能成功执行最近登录您的网站，但尚未注销，或者会话尚未到期。

为防止这种情况发生，最好的选择是在表单中添加基于请求的令牌，并在服务器端对其进行验证。即生成一个长且唯一且无法猜测的随机字符串，该字符串将存储在会话中并嵌入为表单的< input type = hidden> 元素。提交表单后，将提交的令牌值与会话中已经存在的令牌值进行比较（并立即删除会话中的一个令牌值）。要更进一步，请使用 CAPTCHA 。

在您的特定情况下，我认为您实际上更担心 XSS ，与CSRF相反，但也可以作为CSRF的来源。 XSS的一个示例是，当用户在一个输入字段中输入以下内容时，迟早会在同一网站上显示该内容：

 < form name = delete action = admin / deleteusers method = post>< / form> 
< script> document.form.delete.submit（）;< / script> 
  

每当您（作为管理员）以（不可见！）形式查看带有注释的页面

实际上，预防XSS非常容易。在将它们显示在网页上之前，只需先对其进行HTML转义任何用户控制的输入（即请求URL，请求标头，请求参数和请求正文）。在PHP中，您可以为此使用 htmlspecialchars（）；在Java / JSP中，可以使用JSTL fn：escapeXml（）。这样，每个< 下的内容将转换为& lt; 和>。 到& gt; ，这将使所有输入的HTML / JS都按原样显示，因此无法执行。 / p>

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) 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) 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) 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?

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?).

解决方案

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>

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.

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.

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.

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屋！