您现在的位置是:网站首页> 内容页

【10.15总结】绕过CSRF的Referer保护

  • 澳门vip贵宾厅作假
  • 2019-03-19
  • 274人已阅读
简介今天下午可能要出远门,所以现在就把总结写好了。Write-up地址:[Critical]BypassCSRFprotectiononIBM这个CSRF漏洞存在于IBM的修改邮

今天下午可能要出远门,所以现在就把总结写好了。

Write-up地址:[Critical] Bypass CSRF protection on IBM

这个CSRF漏洞存在于IBM的修改邮箱页面,修改邮箱的地址是

https://www.ibm.com/ibmweb/myibm/account/sendmail?locale=us-en&email=NEW_EMAIL

所以理论上讲,只要修改上面链接中的NEW_EMAIL为自己的邮箱,被攻击者在登录了自己的IBM账户后点击该链接,就能达到修改被攻击者邮箱的目的。

但是作者Mohamed Sayed在尝试时,发现IBM会检测请求发出的Referer头部,正常修改邮箱的请求Referer头部为

https://www.ibm.com/ibmweb/myibm/profile/profile-edit.jsp

作者经过几个小时的尝试,发现使用下面的Referer头部可以成功绕过IBM的验证

http://my_website/www.ibm.com/ibmweb/myibm/profile/profile-edit.jsp.php

在测试漏洞时,作者使用了Moakt的临时邮箱服务生成了一个临时邮箱地址作为NEW_EMAIL,在自己的网站上创建文件profile-edi.jsp.php

<script type="text/javascript"> document.location.href="https://www.ibm.com/ibmweb/myibm/account/sendmail?locale=us-en&email=NEW_EMAIL"</script>

这样,只要欺骗被攻击者访问该网页,就可以在自己生成的临时邮箱里收到确认修改邮箱的邮件,成功修改被攻击者IBM账号的邮箱了。


其实这个漏洞原理很简单,我之前在看对CSRF介绍的文章时也有看到过验证Referer的防御手段,只是真实案例是第一次接触,所以仍然很有新鲜感。从该案例也可以看出,CSRF可以使用验证Referer头部的方式进行防御,但是网站对Referer的验证方法仍然可能存在漏洞,需要进行不断的尝试


今天还看了另外一篇文章DevOops — An XML External Entity (XXE) HackTheBox Walkthrough,一开始没明白文章中提到的DevOops是什么东西,只是觉得可以通过这篇文章了解一下渗透测试的简单流程,后来谷歌了一下,才发现Hack the box是一个在线的渗透测试平台,感觉还蛮不错的,注册需要通过一个小测试,并不难,虽然网上已经有教程了,但我还是遵守规则不说出通过测试的方法,只是一个小tip——看网页的源码。

文章评论

Top