Web安全之CSRF,SSRF
CSRF漏洞原理:
用户访问存在csrf漏洞的网站A，并在会话持续期间点开了攻击者的网站，同时攻击者
的网站中存在精心准备的代码在用户进入后会伪装成用户偷偷向网站A发送请求，而在 服务器看来这个请求完全是合法的
漏洞利用条件:
1.用户访问存在CSRF漏洞的网站
2.在没有关闭网站的情况下访问攻击者嵌有非法请求的网站触发攻击
漏洞防御：
为了防止CSRF的发生，创建Token处理机制，Token数据结构与时间、加密签名直接相关， 这么设计的的目的如上所说，是给“身份凭证”加上时间生存周期管理和签名校验管理，如果的凭证被人拿到了， 要先判断Token中的“签名”与时间戳是否都有效，再进行正常的业务处理， 这样通过对非法数据的校验过滤，来降低CSRF攻击的成功率。
CSRF常见的几种情况:
1.页面嵌入csrf_token但是通过修改请求的方法,get变为post，或者post变为get后 后端不会对token进行验证
2.页面嵌入token但是是有token就验证，没有就不验证 这种情况poc里的表单就可以不传token。
3.页面的token没有跟用户的session绑定在一起 这种情况就可以利用另一个用户的token来绕过
4.页面的token同样存在于cookie，后端会把页面的token与cookie中的token进行 比较。 这种情况要看网站功能点存不存在能够把假token注入到cookie当中去。
5.Rerferer验证不严格
burp生成的poc中在pushState('','','/target.com')方法中第三个参数传入存在csrf漏洞的网站 如果发现不成功可以尝试在服务器响应头中添加Header，字段跟值为 Referrer-Policy:unsafe-url 这是因为大多数浏览器单独把Referer字段默认从header中单独剥离了出来， 为了确保重载这个行为并且确保整个URL都在请求中包含，需要在 服务器响应头中添加 Referrer-Policy:unsafe-url Referrer属性能够返回载入当前文档的文档的url，当值为unsafe-url策略时，无论 同源还是非同源，都发送完整的url（移除参数信息之后）作为引用地址。
6.有Referer才验证同源，没有就不验 在poc中添加<meta name="referrer" content="no-referrer"> 剥离referer
SSRF漏洞原理
SSRF（Server-side Request Forgery）服务器端请求伪造
目标:从外网无法访问的内部系统
漏洞成因:由于服务端提供了从其他服务器应用获取数据的功能没有对目标地址进行过滤和限制。
漏洞危害:攻击者能够利用该漏洞进行端口扫描，指纹识别，漏洞利用，内网探针等
各个协议调用探针:http,file,dict,ftp,gopher等
http://192.168.1.152/phpmyadmin/
file:///D:/www.txt
dict://192.168.1.152:3306/info
漏洞防御：
1、过滤返回的信息，如果web应用是去获取某一种类型的文件。那么在把返回结果展示给用户之前先验证返回的信息是否符合标准。
2、统一错误信息，避免用户可以根据错误信息来判断远程服务器的端口状态。
3、限制请求的端口，比如80,443,8080,8090。
4、禁止不常用的协议，仅仅允许http和https请求。可以防止类似于file:///,gopher://,ftp://等引起的问题。
5、使用DNS缓存或者Host白名单的方式。
