在Web表单中的跨站请求伪造攻击 创建一个Web表单的副本 上面所涉及的知识会很容易让人联想到：攻击者将您的邮件地址更改成任何他想要的信息。他可以去复制web表单，并放置到自己的Web服务器上，例如：http://www.attacker.com/evil.php。下面就是新表单的示例： 从上述代码您也许能注意到：该表单并没有提交按钮，因此攻击者可以在未经您同意或知晓的情况下触发该Web表单。此处应该有的按钮被替换成了一行JavaScript，如下所示： document.getElementById('csrf_form').submit(); 这段JavaScript代码先选取表单里的元素，然后以JavaScript的形式进行提交。随着提交的发生，受害者的电子邮件地址随即被更改成了bob@example.com，而在上述代码中属性值正是这个值。 攻击者的HTTP请求 以下是由此类攻击所产生的HTTP POST请求。为了便于阅读，我们在此删掉了那些不相关的请求头部信息： POST /email.php HTTP/1.1 Host: example.com Origin: http://attacker.com Referer: http://attacker.com/csrf.html Cookie: SESSION=e29a31e41c9512a4bd Content-Type:application/x-www-form-urlencoded mail=bob@example.com 下面我们列出攻击者所伪造的HTTP POST请求中的明细： · 浏览器发送一个POST请求。
·
· 我们例子中的example.com是用户所登录到的一个脆弱的站点。请注意它的referrer和origin都表明请求是来自attacker.com。
·
· Cookies的头部信息包含了用户的会话cookie。尽管浏览器请求是被恶意脚本所触发的，但浏览器仍然会将这个Cookie头部连同请求一同发送。由于该请求指向的是example.com，而用户正好具有该网站的会话cookie。这也意味着，Web应用程序会去识别会话里的用户登录状态。
·
· Cookie头部的下面一行是Content-Type类型的HTTP，它表明该请求是由一个表单所发出的。
·
·
用CSRF攻击来诱骗受害者 攻击者是如何使用CSRF攻击来诱骗受害者的呢？让我们假设攻击者将该表单发布到了https://attacker.com/csrf.html。为了诱骗用户浏览到的这个URL，他通常会通过电子邮件的形式去诱骗受害者访问该URL。 因此，一旦受害者访问了https://attacker.com/csrf.html，该表单的提交就会被触发。而那个脆弱的https://example.com网站随即会接受到该请求。由于其Web应用程序根据会话cookie，判定是由受害者亲自提交而来，因此它将邮件地址更改为bob@attacker.com。 接下来，攻击者所需要做的就是发送一封带有“密码重置”功能的电子邮件了。由于电子邮件已经被改成了bob@attacker.com，因此Bob会收到该邮件，并且能够轻而易举地改变Alice的密码了。至此，Bob完全接管了她的帐号，甚至会把她锁在了“门外”。 向受害者隐藏CSRF攻击 为了不使受害者注意到已经遭受了CSRF攻击，攻击者一般会创建另一个称为info.html的网页，来包含一些受害者感兴趣的主题信息。同时，该网页会包含一个指向https://attacker.com/csrf.html的隐藏iframe。一旦受害者访问到了info.html，在csrf.html上的表单就会在受害者不可见的情况下自动触发。 可见，攻击者通常使用CSRF攻击来更改密码或表单上的电子邮件，从而劫持受害者的帐户，或是在Web应用上创建一个新的管理员帐号。 预防跨站请求伪造攻击 攻击者只有在获知到表单里使用了哪些参数和值的组合时，才能发动CSRF攻击。因此，如果增加一个对于攻击者来说是未知的参数值，并且能够通过服务器端进行验证，那么您就可以防止受到CSRF的攻击。下面我们为您罗列了一些可以用来预防跨站请求伪造攻击的方法。 使用反CSRF的令牌 这是一个只能被用户端的浏览器和Web应用程序所知悉的一个随机字符串。它通常被存储在一个会话的变量中。而且，它通常被放在在网页的一个隐藏表单的字段内，连同请求被一起发送出去。 如果会话的变量值和隐藏的表单字段相匹配的话，web应用程序就会接受该请求。而如果它们不匹配，则该请求会被web应用所丢弃。由于在这种情况下，攻击者并不知道可用于接受请求的那个被隐藏表单的精确值，也就无法发动CSRF攻击了。 在cookies中使用相同的站点标志 相同的站点标志（https://www.netsparker.com/blog/ ... te-request-forgery/）是一个比较新的，可用来预防CSRF攻击的方法。在上述场景中，https://attacker.com/将带有会话cookie的POST请求发往https://example.com/。该会话cookie对于每一个用户都是唯一的，而Web应用程序可以用它来区分不同的用户，并确定您是否已经登录过。 如果给会话cookie标记上“相同站点的cookie”特征，将它与那些仅来自同一个域的请求一起发送出去。那么，当https://example.com/index.php向https://example.com/post_comment.php发送POST请求时，它就会被允许。而由于https://attacker.com/是在另一个不同的域，它无法将会话cookie连同请求一起发送出去，因此也就不能向https://example.com/post_comment.php产生POST请求了。 最后我们罗列出漏洞分类和严重性的对应表，供您参考。
Classification
| ID / Severity
|
PCI v3.1
| 6.5.9
|
PCI v3.2
| 6.5.9
|
OWASP 2013
| A8
|
CWE
| 352
|
CAPEC
| 62
|
WASC
| 9
|
HIPAA
| 164.306(a)
|
Netsparker
| Low
|
【原标题】 What a Cross-Site Request Forgery Attack Is and How to Prevent It 作者:Sven Morgenroth 原文链接：https://dzone.com/articles/what- ... ry-attack-is-and-ho
