SSRF篇-本着就了解安全本质的想法，尽可能的用通俗易懂的语言去解释安全漏洞问题
0x01 Brief Description
SSRF(Server-Side Request Forgery:服务器端请求伪造) 见名知意，是一种由攻击者构造形成由服务端发起请求的一个安全漏洞。一般情况下，SSRF攻击的目标是从外网无法访问的内部系统。（正是因为它是由服务端发起的，所以它能够请求到与它相连而与外网隔离的内部系统）。
对比csrf，csrf是客户端浏览器的跨站伪造请求，而ssrf是服务器端产生的伪造请求。
SSRF 形成的原因大都是由于服务端提供了从其他服务器应用获取数据的功能且没有对目标地址做过滤与限制。比如从指定URL地址获取网页文本内容，加载指定地址的图片，下载等等。
like this
0x02 Vulnerability impact
ssrf可以做什么呢？
1.本地任意（对应应用的权限）文件读取
2.和服务器相同环境的端口扫描以及服务banner信息探测。
3.攻击存在漏洞的内网程序，例如s2等。
利用shellshock漏洞命令执行的 见：https://www.youtube.com/watch?v=xR8tWcimALw&feature=youtu.be
还可以sql注射 见：https://www.youtube.com/watch?v=F0xKXT5IyEk
总之，一些常见的漏洞都可以通过服务器去实现，这个时候服务器的作用相当于一个代理的作用。还是比较有意思的。
0x03Vulnerability scenario
大多数社交网站都提供了通过用户指定的url上传图片的功能。如果用户输入的url是无效的。大部分的web应用都会返回错误信息。攻击者可以输入一些不常见的但是有效的URI，比如
http://example.com:8080/dir/images/
http://example.com:22/dir/public/image.jpg
http://example.com:3306/dir/images/
然后根据服务器的返回信息来判断端口是否开放。大部分应用并不会去判断端口，只要是有效的URL，就发出了请求。而大部分的TCP服务，在建立socket连接的时候就会发送banner信息，banner信息是ascii编码的，能够作为原始的html数据展示。当然，服务端在处理返回信息的时候一般不会直接展示，但是不同的错误码，返回信息的长度以及返回时间都可以作为依据来判断远程服务器的端口状态。
code like this below
<html>
<body>
<h1>Enter the URL</h1>
<h3>This page cULR to Fetch content from a specific URL</h3>
<form name="px" method="post" action="http://127.0.0.1/ssrf/ssrf.php">
<input type="text" name="url" value="">
<input type="submit" name="commit" value="submit">
</form>
<script>
</script>
</body>
</html>
<?php
if (isset($_POST['url']))
{
$link = $_POST['url'];
$filename = '.\\curled\\'.rand().'.txt';
$curlobj = curl_init($link);
$fp = fopen($filename,"w");
curl_setopt($curlobj, CURLOPT_FILE, $fp);
curl_setopt($curlobj, CURLOPT_HEADER, 0);
curl_exec($curlobj);
curl_close($curlobj);
fclose($fp);
$fp = fopen($filename,"r");
$result = fread($fp, filesize($filename));
fclose($fp);
$result=str_replace("\n","<br>",$result);
echo $result;
}
?>
正常情况下，请求http://www.qq.com/robots.txt 返回结果如下：
如果请求非http服务的端口，比如：http://192.168.1.106:22/test.txt 会返回banner信息
请求关闭的端口会报错 http://192.168.1.106:21/test.txt
当然大多数互联网的应用并不会直接返回banner信息。不过可以通过前面说过的,处错误信息,响应时间,响应包大小来判断。
当如除了端口扫描探测外，还可以进行内网应用识别，进而攻击内网应用。
ssrf本身的危害可能不如rce这种简单粗暴，但是如果和一些漏洞结合起来利用，可能会起到意想不到的效果，比如2016hctf里面有道题目（ATField writeup），就是利用了ssrf以及python的urlilb header注入攻击了内网的redis，通过redis写计划任务反弹shell，ssrf是我们构造攻击的第一步可见其重要性
0x04 tricks
exploitingt SSRF with localhost techniques
http://127.0.0.1
http://[::]/ (ipv6)
http://0/
http://localtest.me (dns to 127.0.0.1)
http://2130706433/ (decimal)
http://0x7f000001/ (hex)
http://0x7f.0x00.0x00.0x01 (hex)
http://0177.0.0.01 (octal)
0x05How to Avoid
1.不要“相信”用户的数据，对用户输入的数据做校验。
2.统一错误信息，避免恶意用户可以根据错误信息来进行信息刺探。
3.对内网资源服务进行加固，关闭不必要的端口和服务。
0x06 Reference
1.http://www.freebuf.com/articles/web/20407.html
2.https://securingtomorrow.mcafee.com/mcafee-labs/server-side-request-forgery-takes-advantage-vulnerable-app-servers/
3.http://joychou.org/index.php/web/javassrf.html
4.http://joychou.org/index.php/web/phpssrf.html
5.https://github.com/cujanovic/SSRF-Testing/
