预防跨站请求伪造—Web安全深度剖析(3)

发表于:2015-5-11 11:13

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:张炳帅    来源:51Testing软件测试网原创

  10.1.6  预防跨站请求伪造
  在预防CSRF攻击时,不像其他漏洞那样复杂,你只需要在关键部分增加一些小操作就可以防御CSRF攻击。
  1.二次确认
  在调用某些功能时进行二次验证,如:删除用户时,产生一个提示对话框,提示"确定删除用户吗?"。转账操作时,要求用户输入二次密码。
  设置验证码,在进行敏感操作时输入验证码。关于验证码认证的内容,在后面章节中将会详细讲解。
  当二次验证后,即使用户打开了CSRF POC页面,也不会直接去执行,而需要用户再次输入才可以完成攻击。这样,当用户突然收到提示后,可能会心存怀疑,就不再会乖乖地中招。
  2.Token认证
  Token即标志、记号的意思,在IT领域也叫作令牌。
  回顾CSRF攻击的原理,CSRF攻击成功的两个要素如下:
  -攻击者可得知URL的所有参数项,并了解其含义;
  -诱导用户访问构造好的POC。
  假设出现最坏的情况,攻击者知道了重要的HTTP参数项,并且构造出POC,这时当用户单击了攻击者精心构造的POC后,还有补救的方法吗?答案当然是有的,比如,上一节中提到的验证操作就可防御,但这样就大大降低了用户体验。试问:每当你发表一篇文章或者修改一些资料时都会弹出对话框提示输入验证码,这样是你想要的吗?相信没有人喜欢这样。
  那么更好的一种操作就是使用Token验证,Token也是业内针对CSRF防御的一致做法。Token类似于"验证码",但是这种验证码不需要输入。
  验证码的验证思路是在服务器端生成验证字符串并保存在Session中,然后在客户端使用图片显示这段字符串,当用户输入验证码之后交给服务器处理,如果验证码与Session中的字符串相匹配,就代表验证码正确,可以发起请求,反之亦然。而Token则是一个不用输入的验证码,当用户登录Web应用程序后,首先,服务器端会随机产生一段字符串分配给此用户,并且存储在Session中,当用户进入某些页面时,直接传递在用户界面或者Cookie中。如果在HTML中,那么为了用户体验更好,一般都会隐藏起来,如:
  <input type="hidden" name="token" value="6wku2jsdoi7ew0s"  />
  当用户进行提交表单操作时,这段token代码也会随之被提交。当服务器端接收到数据时,就会判断这段"验证码"是否与Session中存储的字符串一致,如果一致,则认为是合法的请求,如果不一致,则有可能是CSRF攻击。如图10-11所示,HTML表单中就存在一个隐藏的Token,彻底解决了CSRF的问题。
  
图10-11  表单中的token
  有时用户进行一些操作可能不需要提交表单,比如删除用户操作,仅仅发出一个GET请求即可:
  http://www.xxser.com/delUser.action?userid=2
  这样form表单中插入Token就不合适。此时,通常会在Cookie中存储Token,因为无论是GET请求还是POST请求,只要向服务器进行请求,那么一般都会带入Cookie,这样就解决了GET请求传入Token值的问题,如图10-12所示。
  
图10-12  Cookie中的Token
  在使用Token防御CSRF时,详细步骤如下。
  ① 每当用户登录后会随机生成一段字符串,并且存储在Session中。
  ② 在敏感操作中加入隐藏标签,value即为Session中保存的字符串,如:
  <form action="addUser.action" method="GET">
  账号:<input type="text" name="username" /><br/>
  密码:<input type="password" name="password" /><br/>
  确认密码:<input type="password" name="password2" /><br/>
  <input type="hidden" name="token" value="3a8d9fx0s8v8" /><br/>
  <input type="submit" value="添加">
  </form>
  注:如果为GET请求,考虑使用在Cookie中存储Token。
  ③ 提交请求后,服务器端取出Session中的字符串与提交的Token对比,如果一致,则认为是正常请求,否则可能是CSRF攻击。
  ④ 更新Token值。
  另外,这里提出一点,当网站同时存在XSS、CSRF漏洞时,Token防御机制将会失效,因为攻击者可以通过JavaScript获取Token值。
  如果一个网站上同时存在XSS与CSRF漏洞时,那么XSS可以比CSRF做得更多。笔者认为,CSRF其实就是XSS攻击的一种"缩小版"。从前面的知识可知,通过XSS获取WebShell不就是XSS与CSRF吗?
  所以在防范CSRF时,首先需要确定网站是否存在XSS漏洞,如果网站存在XSS漏洞,那么防范CSRF是没有任何意义的。
本文选自《Web安全深度剖析》第十章,本站经电子工业出版社和作者的授权。
版权声明:51Testing软件测试网获电子工业出版社和作者授权连载本书部分章节。
任何个人或单位未获得明确的书面许可,不得对本文内容复制、转载或进行镜像,否则将追究法律责任。
21/212>
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号