跨站请求伪造CSRF攻击的原理以及防范措施

霉霉夏眠-:
笑死我了，我以为up引入的这个音乐是有想法的，斜杠还被转移义了，专门去解码了一下，结果[笑哭][笑哭][笑哭]

shenyunmomie:
登陆安全这个问题我也想了好几天，有点思考。 先明白浏览器都有同源策略，主要限制了三个方面： 1. **DOM层面**：不同源站点之间不能相互访问和操作DOM 2. **数据层面**：不能获取不同源站点的Cookie、LocalStorage、indexDB等数据 3. **网络层面**：不能通过XMLHttpRequest向不同源站点发送请求 总结同源策略，就是限制不同域名之间的交互。 由于开发也需要不同源交互，例如前后端分离项目，所以就定义了CORS标准，用来跨域资源共享。 浏览器在发现本次请求为跨域访问时，会执行CORS（CORS请求分为简单请求和预检请求），在请求头加入Origin来源站点，由服务端校验来源站点，例如从bilibili.com来的请求则通过，从meinvtupian.com网站来的，简单请求会发送正常响应，预检请求先询问是否允许此网站跨域，不允许则，浏览器发现响应没有CORS字段会拒绝加载(不过对黑客没用)。 所以设置CORS允许跨域的网站，就能一定程度上避免CSRF攻击。 视频中的方法应该叫浏览器cookie的同源策略，除了SameSite和Secure属性，还有一闪而过的HTTPOnly，防止通过客户端脚本访问cookie。这应该是防XSS的。 浏览器的同源策略一定程度防止了XSS攻击和CSRF攻击，是网络安全的重要基石。 老实说我还有好多问题没搞明白，之前写了篇博客一会发出来，希望有大佬为我解答。

【回复】option检查主要针对的是ajax，如果是form表单提交，即使浏览器在这个http上携带了cookie，也不需要进行option检查的，post请求会直接发送到对方服务器上，但是因为返回的http头中没有相应的Access-Control-Allow-Origin，所以攻击网站无法读取返回的数据，不过读不读取返回值已经不重要了，post请求的确已经在服务器上执行了。
【回复】http://swshenyun.top/2024/05/15/网络安全一-跨域访问/ 前面CORS写的还行，后面写的垃圾，别信。
ChengFIT_Corpora:
系统仅通过一个东西确认你的身份，而不采取其他手段，别人想冒充你的行为有两种方法：一是直接拿到你的令牌，直接变成你；二是伪造攻击者要做的操作，再让你执行[脱单doge]后者是经典CSRF的原理 之前做session cookie劫持才彻底理解的[doge]

疑似有点不服气了:
b站被csrf攻击感觉很严重 经常出现很多人在不知情的情况下回复一些片哥的话 或者发一些广告

WaterLemon7:
我来为后面的对跨站请求伪造CSRF（Cross-Site Request Forgery）有疑问的大家解答一下，如果有什么错误或者遗漏请指出。 CSRF指攻击者利用浏览器自动发送Cookie的特点，诱导用户点击图片或者链接跳转到指定页面进而伪装成用户窃取用户或者服务器的信息。 下面使用A代指正常页面、B代指恶意页面。如果用户在页面A的提交了登陆表单并通过验证，A为了保持会话状态会在后端服务器中在http请求头中设置cookie/session。在cookie/session过期之前，每次用户对A页面的访问都会带上Cookie，服务器从http请求头中解析Cookie后会直接跳过登录页面并返回用户页面给浏览器。攻击者可以利用这一特征在页面B诱导用户点击跳转到A的链接，从而伪装成用户对页面A发起其他请求。 而使用Token可以有效降低CSRF风险，因为Token可以选择不放在Cookie中，而是直接在客户端通过js脚本放在http请求头部中。这样页面B无法通过js脚本获取到该Token（浏览器同源策略不允许其他源的脚本获取另一个源的资源）。因此攻击者在页面B无法加入Token，也就无法伪装成用户发起对A的攻击。 而如果Token选择使用Cookie保存，则需要在浏览器中设置http-only属性（此时浏览器将禁止js脚本访问该cookie），以及Secure属性（仅通过https传输Cookie，防止传输途中被窃取）。

【回复】回复 @沐泠漓 :浏览器请求分为两类，一类是浏览器自身发起的请求，一类是js发起的xhr/fetch。 xhr/fetch发起的请求浏览器会先发一个options请求到服务器，得到服务器允许以后浏览器才会发起正式请求。 但是由浏览器自身发起的请求，比如点击链接、点击form 的submit，都没有这个options请求，所以会成功。 总之，只有js的请求才会有cors限制。 这个区别应该是出于兼容性考虑吧。
【回复】回复 @沐泠漓 :我的理解是，同源策略和cors限制的只是跨域的读操作，对于表单提交等写操作，同源策略和cors并不进行限制，所以不能解决csrf，需要额外的验证机制或者限制跨域时cookie的发送来保证安全
【回复】回复 @沐泠漓 :非佬，有问题我们都随时交流就好。同源策略会阻止不同源的页面对本页面发起的数据访问，但并不会阻止其他页面对本网页发起的请求。 所以说B页面可以借助这一点冒充用户对页面A发起请求（转账、修改密码、xss攻击注入）。这些请求不要求返回数据，所以csrf才有机会成功。
苦瓜少年爱吃苦瓜:
多来点这个系列啊[doge]，要hvv面试了[笑哭]

【回复】年年折腾一次，今年应该也快了还好我逃离了安服仔[doge]
冒泡ioa:
我有一个问题，就是如果要从站点B访问站点A的api，难道不是需要A的服务器启用了 COSR 吗，如果没有启用 COSR 的情况下还会有 CSRF 攻击吗

【回复】回复 @沐泠漓 :浏览器请求分为两类，一类是浏览器自身发起的请求，一类是js发起的xhr/fetch。 xhr/fetch发起的请求浏览器会先发一个options请求到服务器，得到服务器允许以后浏览器才会发起正式请求。 但是由浏览器自身发起的请求，比如点击链接、点击form 的submit，都没有这个options请求，所以会成功。 总之，只有js的请求才会有cors限制。 这个区别应该是出于兼容性考虑吧。
【回复】CORS是用来限制请求头的origin，浏览器通过preflight检查api是否可用。CSRF是用在同源伪造请求，所以要在源的payload添加nonce, 并且这个nonce要在session中保存，旨在到达api后验证真的是源发起的请求，之后抛弃这个nonce。
【回复】要清楚，限制不同源交互的是**浏览器**的同源策略。CORS是一个标准，用来给同源策略开后门的，浏览器服务器都有，只不过浏览器在跨域时都是自动发送的，如果服务器不设置CORS规则，服务器在接收“CORS普通请求”时，会发送正常http响应，不过浏览器看到不是CORS的响应，就不加载罢了，结果该得到还是能得到。而浏览器如果发送的是“CORS非普通请求”，则会先发送预检请求，看看服务器是否接受跨域，如果不接受，正式请求不会发送，就不会收到CSRF攻击。
谁家的小鉴:
以前qq情侣空间也能这样玩，做一个表单自动提交到发送邀请的api 只要发给别人这个网址别人就会自动向你发情侣空间邀请[笑哭]

1111收费账号以注销:
没有不被贼惦记重要。。。但是你没有通讯更被贼惦记。。这很矛盾

青城叶北:
呱，好恐怖啊，这个视频就偷了我的硬币

司雨Seey:
总结：使用https的时候记得把samesite属性从默认值lax改成none。 推导：https没有csrf攻击的风险。 如有错误，恳请指正！恳请指正！恳请指正！

风飏:
现在是不是很多网站都共享cookie了？[以闪亮之名_吃瓜]为了实现跨站收集用户信息来投放广告什么的？

好好干生活会越来越甜:
最简单的防CSRF攻击还是前端页面根据用户某一时间段的操作行为生成cookie（这样cookie就很难被伪造），后端的话，设置每个cookie只能被用作一次请求就可以了（防止被黑客重复使用进行攻击）。

【回复】纯纯不懂技术的人，瞎几把乱讲
【回复】最简单的方法就是验证referer！！！！没有之一
【回复】回复 @二叉树树 :没说清楚，是前端把某一时刻用户的操作行为作为特征传给后端，后端根据此特征生成cookie。
琴弦啥都会:
想问一下蛋老师，可以用海外云服务器登录谷歌吗？会不会不稳定或有安全问题