请选择 进入手机版 | 继续访问电脑版

设为首页 收藏本站
思科社区 关注
思科社区

  思科 CCO 登录 推荐
 找回密码
 立即注册

搜索
热搜: 邮件服务器
查看: 251|回复: 0

【小目标,一个“译”】+ 何为跨站请求伪造攻击,以及如何预防(2)

[复制链接]
发表于 2018-10-30 14:16:33 | 显示全部楼层 |阅读模式
Web表单中的跨站请求伪造攻击

创建一个Web表单的副本

上面所涉及的知识会很容易让人联想到:攻击者将您的邮件地址更改成任何他想要的信息。他可以去复制web表单,并放置到自己的Web服务器上,例如:http://www.attacker.com/evil.php。下面就是新表单的示例:

<form id = "csrf_form" method= "POST" action = "http://example.com/email.php">

<input type = "text" name ="mail" value = "bob@attacker.com">

<form>

<script>

document.getElementById('csrf_form').submit();

</script>


从上述代码您也许能注意到:该表单并没有提交按钮,因此攻击者可以在未经您同意或知晓的情况下触发该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,它表明该请求是由一个表单所发出的。
·        
·        整个post的底部最后一行是参数映射值。此处参数为mail,其值便是攻击者的邮箱地址:bob@attacker.com
·        


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.phphttps://example.com/post_comment.php发送POST请求时,它就会被允许。而由于https://attacker.com/是在另一个不同的域,它无法将会话cookie连同请求一起发送出去,因此也就不能向https://example.com/post_comment.php产生POST请求了。

最后我们罗列出漏洞分类和严重性的对应表,供您参考。
[td]  
   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



  • 1
  • 2
  • 3
  • 4
  • 5
  • 1
  • 2
  • 3
  • 4
  • 5
平均得分0 (0 评价)
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

Archiver | 思科社区  

GMT+8, 2018-11-14 09:26 , Processed in 0.093649 second(s), 32 queries .

京ICP备09041801号-187

版权所有 :copyright:1992-2019 思科系统  重要声明 | 保密声明 | 隐私权政策 | 商标 |

快速回复 返回顶部 返回列表