(服务端)跨站请求伪造：Cross-Site Request Forgery
客户端请求伪造：Client-Side Request Forgery 即通过各种方式在客户端利用受害者的凭证发起请求
既然是前端安全就一定与浏览器有关.CSRF漏洞的本质是浏览器在不应该发送Cookie的地方发送了Cookie.
Cookie目前一共有8个属性,分别是 key—值 value—键 expires—Cookie的持续时间 有效时间 domain—Cookie的有效域名 path—哪些路径会携带Cookie secure
cookie-secure的值改为true，true意味着"指示浏览器仅通过 HTTPS 连接传回 cookie。 这可以确保 cookie ID 是安全的，且仅用于使用 HTTPS 的网站。如果启用此功能，则 HTTP 上的会话 Cookie 将不再起作用。httponly
设置HttpOnly=true的cookie不能被js获取到，无法用document.cookie打出 cookie的内容。samesite—防止csrf的攻击
浏览器发送Cookie的策略很简单,只要本地缓存有Cookie,且目标URL符合Cookie的domain,path属性.则会发送.
浏览器不会验证是在哪里发起的请求.并且有个容易忽略的地方,same-site（同站）与same-origin（同源）是两个概念.对浏览器发送cookie来说只在乎same-site,也就是说,协议不同.端口不同或者domain配置错误的情况下子域名不同,也会发送cookie.
绝大多数Cookie的发送不受SOP（同源策略）限制,
XHR请求发送cookie受SOP限制.
最常用来触发CSRF的方式 当然是使用form自动提交GET或POST请求 这种方式利用burpsuite的CSRF poc generator快速生成
GET类型的CSRF来讲 还可以通过<img>,<iframe>,<link>,<script> 等标签来触发 甚至可以用a标签诱骗用户点击
(只需要src内的属性设置成你需要的get请求的url，达成跨站请求伪造)
因为对于服务器来说 获取图片 或者js脚本请求，与获取html请求没有什么不同
我们也都知道,防护CSRF攻击最常用的方式一是添加csrf token,二是服务端验证referer
绕过referer!
去目标网站找个可控上传文件名的上传点,把刚才的图片url传到目标网站上去.这样referer就来自本站了.CSRF蠕虫大多就是这样实现的,需要在本站找到html可控的点.
同源策略详解
域名和协议和端口都相同
传统的CSRF
1.GETGET类型的CSRF,可以使用img,link,script,frame等等方式发起.也可以使用form来利用.
img标签发起的好处在于,通常站内存在上传图片的功能,如果上传文件的url可控,就可以在站内触发CSRF,绕过对于referer的验证.
2.POST POST类型的CSRF最为常见,通过burpsuite生成poc快速又便捷. 如果站内存在HTML注入或上传HTML文件,但不能执行js的时候,也可以在站内注入对应的HTML,来实现绕过referer验证.但是，以上两种请求方式有一个弊端，当你用form来实现某些操作,形成新的链接了，跳转到另一个源，js不能获取返回数据,也就是说只能用来进行某些操作,无法窃取数据.
上面是一些跨域写操作和跨域资源嵌入
只能进行某些操作 而无法读取数据
(通过js获取数据的其他利用方式)
1.Ox01 XMLHttpRequest 简单来说.同源策略是用来限制两个源直接交互的安全策略.协议,端口,域名(包括子域名)都相同即为同源.same-origin是比same-site更为严格的策略. 所以XHR默认情况下是无法跨域的,但是跨域的需求又非常大. 为了这个需求.WGC制定了安全的跨源资源共享方案.即CORS(Cross-Origin Resource Sharing).
2.Ox02 AJAX 我们成功发送了cookie,并请求到了敏感数据. 这个漏洞叫做CORS配置错误.但本质上,也是一个CSRF漏洞. 与此类似的,ajax是基于XHR开发的异步请求框架.同样的攻击方式也适用于AJAX.
3.Ox03 FETCH Fetch同样遵循SOP与CORS.因此,一旦CORS出现配置错误,就有可能导致敏感数 详情看这里
刚才说到的XHR,AAX,FETCH本质上都是跨域读操作,而跨域读操作默认是不被允许的，需要配置CORS来解开限制,而CORS—旦配置错误,就有可能导致漏洞.但在浏览器早就注意到了这个问题,因此,在使用cookie(配置withCredentials= true),并且ACAO为*的时候,浏览器会报出错误.当然请求会被发送,但是数据会被浏览器block,无法访问.
当然,CORS配置错误不仅仅只有*,还有例如:
Access-Control-Allow-Origin:requester.com这可以通过注册一个evilrequester.com域名来绕过.
也可以通过xSS,包括子域的XSS来绕过
绕过httponly的小技巧Httponly只是限制设置了这个值的Cookie无法被js读取,但不代表无法被js使用.因为cookie的使用是浏览器控制的.
因此,假设我们在某站找到了xss,但无法读到cookie.
这种情况,我们可以通过CSRF攻击直接使用他的Cookie去完成我们想要完成的操作.当然,如果getshell或者添加高权限账号的操作在后台,需要拿到对应的http包.针对开源cms这个技巧比较好用.
4.Ox04JSONP Jsonp是json的一种使用方式,本质上就是script标签.是用来绕过SOP的跨域读资源限制的.并非浏览器提供的正规解决办法.因为不需要配置CORS,使用方便,因此被许多开发者大规模使用.这也导致了非常多的漏洞问题. 因为不是正规的解决方案,也就没有完善的安全策略.默认情况下的使用将会存在安全漏洞.并且在各大网站非常普遍. Jsonp使用不当的漏洞通常叫做jsonp劫持,本质上也是CSRF类的漏洞.5.Ox05 iframe lframe能在页面内引入其他HTML页面.通过设置src属性引入其他页面是个跨域嵌入操作,不受同源策略影响.但是如果要跨域通讯.而且iframe引入其他页面的时候,是会携带cookie的.也就是说.如果你已经登录,返回的是已登录的页面. 因为同源策略的原因无法读取子页面dom,也无法进行操作.当然这里也有一种CSRF技巧,名字都听说过点击劫持(ClickJacking),通过诱骗受害者点击,来执行引入的iframe上的操作.本质上也是利用用户的凭着发送请求.也可以归类到CSRF中.
虽然直接加载iframe不受SOP影响.
但是想要与iframe内通信,却遵循SOP
关于iframe还有一个trick,当加载iframe,并且iframe中存在img标签时.请求图片的referer是iframe的url.
刚才提到了,IFRAME无法跨域读,因此.有大佬想了奇技淫巧,通过window.name和loaction.hash绕过这个限制.（get到了！！） 当然也有官方提供的解决方案—postMessage
在监听message的时候,如果没有验证origin,则容易导致漏洞.
这个通讯方式是纯前端的,在burp抓不到包
这个比较容易理解,因为在前端是无法控制referer的.因此服务端只需要获取请求头中的referer来验证请求是否来自合法的源即可
Ox02添加CSRF token因为CSRF是通过伪造请求来实现,既然如此就可以通过添加一次性的token来缓解csrf攻击.没有携带token的请求或校验不通过的请求—律不返回任何数据.这里通常有两种方式,一是.在session保存一份token,页面上保存一份token.必须使得请求中的token与session中的计算结果校验一致.
还有一种方式则是在Cookie中保存一份,再在页面中保存一份.校验Cookie中与页面中的token是否一致.这种方法对服务器的负担小,但是不能防XSS.
Ox03 Same-Site Cookie近些年来,.为了彻底解决CSRF攻击.浏览器的开发者们给Cookie添加了一个新的参数-SameSite.Samesite属性有三个值,分别是:None,Lax,Strict.浏览器在不同属性下的对Cookie的处理不同
这个参数用来全局控制哪些情况发送cookie,哪些情况不发送cookie在Chrome80版本之前,默认值为Lax.
这几乎是个CSRF的完全的解决方案.缓解了绝大多数类型的CSRF攻击.
详情看这里
为了防止默认为lax的samesite属性影响到原本网站的功能,为了平缓的过度,浏览器lax将在cookie设置后的两分钟之后才会拒绝post请来友达的cOOKIe.此,如果存在logoutCSRF(通常这种CSRF都是被src忽略的),可以让用户重新登录再进行CSRF
Ox04其他修复方案与CSRF token类似的缓解措施,二次认证(短信,邮箱验证码)也能解决CSRF攻击.但用户体验差
面对点击劫持这样的CSRF,则可以通过添加X-Frame-Options头防御.
