CSRF和SSRF

CSRF

什么是？

Cross-site request forgery，跨站脚本伪造（客户端）。CSRF通过伪装来自受信任的用户的请求来攻击受信任的网站。与XSS相比，CSRF攻击往往不太流行（因此对其进行防范的资源也是相当紧缺的）和难以防范的，所以被认为比XSS更具危险性。

CSRF攻击：首先攻击者会先盗用你的身份，然后以你的名义进行某些非法操作，甚至盗走你的账户购买的商品等。CSRF攻击其值是利用web中用户身份认证验证的一个漏洞：简答的身份验证仅仅可以保证请求发自某一个用户的浏览器，却无法保证请求本身是用户资源发出的。

任何网站都有CSRF，没有危害不是漏洞

攻击流程

1. 用户C打开浏览器，访问受信任网站A，输入用户名和密码请求登录网站A；
2. 在用户信息通过验证后，网站A产生Cookie信息并返回给浏览器，此时用户登录网站A成功，可以正常发送请求到网站A；
3. 用户未退出网站A之前，在同一浏览器中，打开一个TAB页访问网站B；
4. 网站B接收到用户请求后，返回一些攻击性代码，并发出一个请求要求访问第三方站点A；
5. 浏览器在接收到这些攻击性代码后，根据网站B的请求，在用户不知情的情况下携带Cookie信息，向网站A发出请求。网站A并不知道该请求其实是由B发起的，所以会根据用户C的Cookie信息以C的权限处理该请求，导致来自网站B的恶意代码被执行。

从上述的流程可以看出，想要达成CSRF攻击，必须达成两个基本条件。

• 登录受信任网站A，并且在本地生成Cookie。
• 在不退出登录网站A的前提下，访问危险网站B.

常见的CSRF攻击

GET类型

银行站点A: 它以GET请求的方式来完毕银行转账的工作：如http://www.mybank.com.Transfer.php?toBankId=11&money=1000
危险站点B:其中存在一段html代码为<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000 >
首先你登录了银行站点A，然后访问危险站点B,这时你就会发现自己的银行账号少了1000元。为什么会这样呢？原因是银行站点A违反了HTTP规范，使用GET请求更新资源。在访问危急站点B的之前，你已经登录了银行站点A，而B中的 一个合法的请求，但这里被不法分子利用了）。所以你的浏览器会带上你的银行站点A的Cookie发出Get请求，去获取资源以GET的方式请求第三方资源（这里的第三方就是指银行站点了，原本这是http://www.mybank.com/Transfer.php?toBankId=11&money=1000 ，结果银行站点服务器收到请求后，觉得这是一个更新资源操作（转账操作），所以就立马进行转账操作。

POST类型

POST类型的CSRF危害没有GET类型的大，利用起来通常使用的是一个自动提交的表单，如

<formaction=http://wooyun.org/csrf.phpmethod=POST>
​        <inputtype="text"name="xx"value="11"/>
​       <inputtype="submit"id="postSubmit"value=""/></form><script>
  window.onload=function(){
    document.getElementById("postSubmit").click();}</script>

访问该页面后，表单会自动提交，相当于模拟用户完成一次POST操作

CSRF漏洞检测

检测CSRF漏洞是一项比较繁琐的工作，最简单的方法就是抓取一个正常请求的数据包，去掉Referer字段后再重新提交，如果该提交还有效，那么基本上可以确定存在CSRF漏洞（referer的ip标识着请求的ip）

工具：CSRFTester，CSRF Request Builder等

使用CSRFTester进行测试时，首先需要抓取我们在浏览器中访问过的所有链接以及所有的表单等信息，然后通过在CSRFTester中修改相应的表单等信息，重新提交，这相当于一次伪造客户端请求。如果修改后的测试请求成功被网站服务器接受，则说明存在CSRF漏洞，当然此款工具也可以被用来进行CSRF攻击。

CSRF漏洞防御

三种策略：

• 验证HTTP的 Referer 字段
• 在请求地址中添加 token 并验证
• 在 HTTP 头中自定义属性并验证

SSRF

介绍

服务器端请求伪造，是一种由攻击者构造，由服务端发起请求的一个网络攻击，一般用来在外网探测或攻击内网服务，其影响效果根据服务器用的函数不同，从而造成不同的影响。

有些web网站会提供从其他服务器上传数据的功能，会使用用户指定的url获取数据。

由于对远程的url没有进行严格的过滤，所以攻击者可以通过该漏洞控制该web网站作为代理服务器攻击远程服务器或者该web的本地服务器。

跳板：（隐藏自己的ip）基于一个网站去攻击另外一个网站，基于SSRF漏洞的都可以当作跳板

SSRF漏洞相关函数和类

• **file_get_contents()**：将整个文件或一个url所指向的文件读入一个字符串中。
• **readfile()**：输出一个文件的内容。
• **fsockopen()**：打开一个网络连接或者一个Unix 套接字连接。
• **curl_exec()**：初始化一个新的会话，返回一个cURL句柄，供curl_setopt()，curl_exec()和curl_close() 函数使用。
• **fopen()**：打开一个文件文件或者 URL。
• ……

上述函数函数使用不当会造成SSRF漏洞。 此外，PHP原生类SoapClient在触发反序列化时可导致SSRF。

SSRF漏洞利用（危害）

• 可以对内网，本地进行端口扫描，查看端口的关闭状态；
• 攻击运行在内网或者本地的应用程序；
• 对内网应用程序做指纹识别；
• 利用协议获取本地的文件；

挖SSRF漏洞

1. 由于ssrf漏洞的产生原理是web服务器向其他远程服务器获取相关的数据从而产生的。
2. ssrf漏洞可能存在的场景- 分享，通过URL地址分享网页内容，通过URL获取目标页标签等内容- 转码服务，适应硬件设备的大小；- 图片的加载与下载- 图片，文章的收藏；

3. 通过url地址分享网页内容

（后面的网页在前面网页展示，是显示前面的ip访问的而不是本机）

3.1、首先当我们点击该连接时，观察url位置，会发现http协议，此时可能存在漏洞。

3.2、输入http://www.baidu.com进行验证，发现可以访问，说明存在SSRF

3.3、读取本地文件

3.4、对端口进行探测（可使用BP）

返回了信息，说明端口开放

输入1000端口 发现尝试连接了一会并没有返回信息，说明端口没有开

3.5、后端使用了file_get_content()函数
读取网页后端源代码以base64编码的方式

http://localhost/pikachu/vul/ssrf/ssrf_fgc.php?file=php://filter/read=convert.base64-encode/resource=ssrf.php

测试端口是否打开

端口打开： 会一直转圈尝试连接

端口关闭：显示错误信息

3.6、 转码服务

通过URL地址把原地址的网页内容调优使其适合手机屏幕浏览

3.7、在线翻译

通过URL地址翻译对应文本的内容。提供此功能的百度、有道等。

3.8、图片下载

通过URL地址加载或下载图片图片加载远程图片地址此功能用到的地方很多，但大多都是比较隐秘，比如在有些公司中的加载自家 图片服务器上的图片用于展示。（此处可能会有人有疑问，为什么加载图片服务器上的图片也会有问题， 直接使用img标签不就好了，没错是这样，但是开发者为了有更好的用户体验通常对图片做些微小调整例 如加水印、压缩等，就必须要把图片下载到服务器的本地，所以就可能造成SSRF问题）。

3.9、url编码中一些关键字

share、wap、url、link、src、source、 target、u、3g、display、sourcellRL、imageURL、domain

3.10、Weblogic(wbe中间件)配置不当，天生ssrf漏洞

如何防御ssrf漏洞

1.统一错误信息

2.限制请求端口

3.黑名单内网IP

4.禁用不需要的协议