CSRF、XSS 科普与防御

最新推荐文章于 2024-02-25 13:14:10 发布

牧羊狼爱学习

最新推荐文章于 2024-02-25 13:14:10 发布

阅读量2.8k

点赞数

分类专栏：前端文章标签： html 前端

本文链接：https://blog.csdn.net/edwardwzw/article/details/122297261

版权

前端专栏收录该内容

32 篇文章 1 订阅

订阅专栏

CSRF (Cross Site Request Forgery) 跨站请求伪造

CSRF 攻击只是借用了 Cookie，并不能获取 Cookie 中的信息，所以不能获取 Cookie 中的 token，也就不能在发送请求时在 POST 或者 GET 中设置 token，把请求发送到服务器端时，token 验证不通过，也就不会处理请求了。

案例演示：

用户登录http://127.0.0.1:9000的网站，输入用户名密码登录某网站后，服务端把记录用户登录的cookie保存到浏览器中，此时用户登录的状态为已登录

此后该网站域名下每次接口请求都会携带cookie（接口收到请求后认为用户已登录）

此时用户调用接口实现转账：

当用户操作完转账后，并没有及时退出登录（cookie中依旧有用户登录的状态），

这时候有一个钓鱼网站诱导用户访问：该钓鱼网站有一张图片(更高明地，宽高都为0，此时用户压根都看不到)，图片的src 路径为转账接口地址，

当钓鱼网站加载时，相当于调用了一次转账接口：（由于该域名下cookie为已登录，请求时带上了该cookie传给了服务端，转账接口调用成功！）

如果是 POST 提交表单，可以这样做：

用户的身份识别就是利用cookie，那么冒充用户身份的方式即利用访问一个域名下其他页面请求，浏览器会携带当前域下的cookie这一特性。

防御思路：

1. 区分请求来自于自己的前端页面还是第三方网站
2. 让自己的前端页面请求和第三方伪造请求有所不同

解决方案：

尽量使用POST，限制GET

GET接口太容易被拿来做 CSRF攻击，看上面示例就知道，只要构造一个 img标签，而 img标签又是不能过滤的数据。接口最好限制为 POST使用， GET则无效，降低攻击风险。

当然 POST并不是万无一失，攻击者只要构造一个 form就可以，但需要在第三方页面做，这样就增加暴露的可能性。

将 cookie设置为 HttpOnly

CRSF攻击很大程度上是利用了浏览器的 cookie，为了防止站内的 XSS漏洞盗取 cookie,需要在 cookie中设置 “HttpOnly”属性，这样通过程序(如 JavaScript脚本、 Applet等)就无法读取到 cookie信息，避免了攻击者伪造 cookie的情况出现。

在 Java的 Servlet的API中设置 cookie为 HttpOnly的代码为：response.setHeader("Set-Cookie","cookiename=cookievalue;HttpOnly");

增加Token

CSRF攻击之所以能够成功，是因为攻击者可以伪造用户的请求，该请求中所有的用户验证信息都存在于 cookie中，因此攻击者可以在不知道用户验证信息的情况下直接利用用户的 cookie来通过安全验证。由此可知，抵御 CSRF攻击的关键在于：在请求中放入攻击者所不能伪造的信息，并且该信总不存在于 cookie之中。鉴于此，系统开发人员可以在 HTTP请求中以参数的形式加入一个随机产生的 token，并在服务端进行 token校验，如果请求中没有 token或者 token内容不正确，则认为是 CSRF攻击而拒绝该请求。

通过Referer识别

根据 HTTP协议，在 HTTP头中有一个字段叫 Referer，它记录了该 HTTP请求的来源地址。在通常情况下，访问一个安全受限的页面的请求都来自于同一个网站。比如某银行的转账是通过用户访问 http://www.xxx.com/transfer.do页面完成的，用户必须先登录 www.xxx.com，然后通过单击页面上的提交按钮来触发转账事件。当用户提交请求时，该转账请求的 Referer值就会是提交按钮所在页面的 URL。

如果攻击者要对银行网站实施 CSRF攻击，他只能在其他网站构造请求，当用户通过其他网站发送请求到银行时，该请求的 Referer的值是其他网站的地址，而不是银行转账页面的地址。因此，要防御 CSRF攻击，银行网站只需要对于每一个转账请求验证其 Referer值即可，如果是以 www.xx.om域名开头的地址，则说明该请求是来自银行网站自己的请求，是合法的；如果 Referer是其他网站，就有可能是 CSRF攻击，则拒绝该请求。