前端开发者需要知道的CSRF攻击 - Githubissues

luoway / blog

个人博客，issues管理

19 stars 3 forks source link

前端开发者需要知道的CSRF攻击 #3

Open luoway opened 5 years ago

luoway commented 5 years ago

CSRF（Cross-site request forgery）跨站请求伪造，听起来很洋气，实践起来一句话概括：

攻击者借助用户浏览器访问攻击者所指定的链接

举例

用户A登录过bank.com且没有失效，
攻击者提供一个链接诱使/强制使用户A访问，如：

<a href="http://bank.com/insecurely-pay?target=AComOwner&money=xxx" target="_blank">点我</a>

bank.com/insecurely-pay没有防范伪造请求，认为这是用户A的意愿予以执行接口功能，则完成了CSRF攻击。

简析

攻击要点：

受攻击网站存在CSRF漏洞
攻击者清楚漏洞参数配置
用户在受攻击的网站的登录状态没有过期

防范

CRSF攻击的原理是：攻击者通过浏览器默认行为，借用了用户的登录信息，达成攻击者的目的。

理解了这个原理，防范就有两个方向：避免登录信息被借用，或识别登录信息被借用。

防范方案：

SameSite SameSite 是现代浏览器更新的Cookie安全配置项，用于控制Cookie传输的行为，有三种选项：
- None：跨站请求也会携带此项cookie
- Lax：默认值。简单请求会携带此项cookie
- Strict：跨站请求不会携带此项cookie
Referer检查

Referer 请求头包含了当前请求资源的来源页面的地址，即表示当前资源是通过此来源页面发起的。

通过检查referer确保请求来源是可信网站。
但Referer也可能被借用，例如被XSS攻击的可信网页发出的请求，就带了可信网页的Referer。
Token校验要求请求参数中包含一段服务器生成的token，校验不通过认为请求不可信。

这个token是随机的，一般存放在cookie里，需要开发者手动从中获取后，添加到指定位置如URL上。
由于攻击者只能借用而不是获取到并可以使用cookie，因此有效防御攻击。
前端XHR修改HTTP请求头，自定义用于校验的属性类似Token校验，区别在于XHR是从可控页面发起的，并且自定义请求头不会被借用，达到Referer检查的效果。
验证码、再次确认等强制与用户交互，以告知用户谨慎操作。适用于第三方支付等跨站请求不可避免的场景。

思考

CSRF到XSS攻击后的页面，执行恶意脚本，发起的请求如何防范？
在不安全的WIFI下，未加密的请求都可能被抓取、修改。

luoway commented 5 years ago

CSRF攻击实例：当通过url传递一些页面展示信息时，如传递图片，接收页若直接将图片链接放到img.src上。那么攻击者就可以将图片链接替换为攻击者指定的链接，由于img标签会发起请求，即可达成CSRF。若该图片链接的使用未做XSS防护，则还能执行脚本，达成XSS（Cross Site Scripting，跨站脚本）。

luoway commented 5 years ago

推荐阅读：《CSRF 攻击的应对之道》

luoway commented 1 year ago

考题：b.com 向 a.com 发出请求

存在哪些问题？
满足哪些条件可以使请求成功响应？