java 跨站点伪造请求_Web安全教程之CSRF(跨站点请求伪造)

前端面试过程中遇到的另一个最多的问题就是web安全了,之前博客有分享过XSS攻击的内容,这次聊聊CSRF攻击。CSRF是一种常见的攻击,但是也是web安全中最容易被忽略的一种攻击方式。

5821.html

什么是CSRF(跨站点请求伪造)

根据字面意思,大概能猜到,CSRF攻击就是攻击者伪造了用户的请求,在用户不知道的情况下,以用户的名义向服务器发送恶意请求。常见的场景是,用户首先登陆一个正常(下面称为被攻击网站)的网站,攻击者诱使用户在不关闭被攻击网站的同时打开攻击者的页面,这时攻击者就可以以用户的名义给被攻击网站发送恶意请求了。可以看出CSRF是有条件的,首先用户要登陆被攻击网站,并生成Cookie,然后在不登出被攻击网站的同时,访问攻击网站。这两个条件缺一不可。

CSRF进阶

浏览器Cookie策略

CSRF之所以能成功,主要还是因为用户的浏览器成功发送了Cookie的缘故。浏览器所持有的Cookie分为两种:一种是“Session Cookie”,又叫“临时Cookie”;另一种是“Third-party Cookie”,也称为“本地Cookie”。

Third-party Cookie,服务器在Set-Cookie时指定了Expire时间,只有到了Expire时间后Cookie才会失效,而Session Cookie则没有指定Expire时间,浏览器关闭后就失效了。如果浏览器从一个域的页面中,要加载另一个域的资源,由于安全原因,某些浏览器会阻止Third-party Cookie的发送。由于新打开的页面和原来的页面在同一个浏览器进程中,所以Session Cookie将会被发送。

IE浏览器处于安全考虑是禁止浏览器在、、

只有GET请求么?

在CSRF攻击流行之初,有一种错误的观点认为CSRF攻击只能由GET发起,这种错误观点的形成原因是大多数CSRF攻击发起时,使用的HTML标签都是、、

var f = document.getElementById("register");

f.inputs[0].value = "test";

f.inputs[1].value = "passwd";

f.submit();

CSRF防御

验证码

验证码是对抗CSRF攻击最简单有效地防御方法。CSRF攻击往往是在用户不知情的情况下构造了网络请求。而验证码则强制用户必须与应用进行交互,才能完成最终请求。

但是验证码并不是万能的,我们不可能给页面的所有操作都加上验证码。

Referer Check

Referer Check在互联网中最常见的应用就是“防止图片盗链”。同理,Referer Check也可以被用于检查请求是否来自合法的源。

Anti CSRF Token

CSRF攻击存在的本质原因还是网页中重要操作的所有参数都是可以被攻击者猜测到的。攻击者只有预测出url所有参数与参数值,才能成功地构造一个伪造的请求。所以我们可以通过把参数加密,或者使用一些随机数,从而让攻击者无法猜测到参数值。

我们可以给请求新增加一个token,这个token值是随机的。

http://host/path/delete?username=abc&item=123&token=[random(seed)]

由于token的存在,攻击者就无法再构造出一个完整的url来实施CSRF攻击了。

版权声明:本站所有文章和资源使用CC BY-NC-SA 4.0协议授权发布 , 转载应当以相同方式注明文章来自“SeaOMC.COM->Web安全教程之CSRF(跨站点请求伪造)!在下边可以分享本文哦!

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值