SSRF——服务端请求伪造，上一篇，我谈到了CSRF客户端请求伪造，这个是我们通过攻击用户，引诱客户点击我们伪造好的表单，从而达到我们攻击的目的，是从客户端发起的，那么SSRF服务端请求伪造当然是通过我们的目标网站也就是我们的服务端而发起我们渗透攻击的目的。
再说一下，平常在做渗透测试工作的过程中哪些地方容易产生SSRF漏洞，可以看到大部分相关资料都会显示，容易产生SSRF的地方在社交分享、图片加载、邮件系统、数据库等。为什么这些地方会出现呢，社交分享可能会分享到其他网址对吧，如果我们替换其网址为我们的本地地址呢，会出现什么样得情况？同一个地址更换不同的端口又会有什么不同，加载图片请求的服务器可能和你所访问的网站不是同一个服务器，这样是不是能探测内网的同一局域网段的情况呢，邮件系统也是同一道理，这些都是探测SSRF漏洞的手段。
所以本质上就是因为你向其他地方请求的资源和你本身的网站资源不在同一个地方，因此，平常在做渗透测试过程中，只要参数带有URL的或者IP地址的就都有可能会产生SSRF漏洞，检查方法：改端口，探测哪些端口开启，换网址，局域网内不同的主机是否开启。这就和盲注的情况一样，存在和不存在会出现不同的情况。
接下来就让我们来看下Weblogic服务的SSRF漏洞是怎么体现的，通过这样的漏洞我们能获的什么样的信息。
本次复现的SSRF漏洞是Weblogic应用服务，版本号是10.3.6，漏洞编号为CVE-2014-4210，为了更好的让人理解，我将本次漏洞的展示与说明写的简洁明了，安装跳过，漏洞出现的页面位于 http://IP:7001/uddiexplorer/SearchPublicRegistries.jsp，这个是属于weblogic的一个组件，是不需要登录就能直接访问的网页，我们看下这个漏洞传输的数据包的展示，选择第一个Search PublicRegistries选项，我这里任意输入一个值text，点击Search按钮发送数据包。
这里我们知道请求并不是向某一网址发起请求，而是向本地发送一个test的表单数据，但这里我们可以看到表单数据其中的一个参数operator，它有一个网址值域名为http://www-3.ibm.com，这里是weblogic请求自带的一个参数，而这里就是产生SSRF漏洞的所在，和我们自己输入的参数值text却没有关系，我们只是为了发送这样一个请求才添加个test值。
为什么说在这里会产生SSRF漏洞呢，因为在这里我们通过变更这个URL的参数，根据响应包返回的数据获得服务器内部的相关信息。
这里我们既然开启了weblogic服务，那么，在没改默认端口的情况下，服务器的7001端口必然开启，为了方便，我直接将7001端口用来测试展示，发起请求，抓包将我们的operator参数后面的网址改为http://127.0.0.1:7001传给服务器，这里是要加上http协议的，此时我们可以看到页面响应的内容报出异常提示返回404错误码。
我知道我自己的服务器上7002端口是关闭没有服务的，这里将我的operator参数更换为http://127.0.0.1:7002来发包，这个时候我们可以看到网页上面的内容显示和端口为7001的不一样，现在报的异常是不能链接本地7002端口，而不是7001这样的返回404错误码。
也就是说，服务端口开启与未开启会给你返回两种不同的网页状态，通过这种不同的情况，我们能够探测该weblogic所在服务器哪些危险端口开启和未开启，这就和盲注判断数据的性质一样，通过这种朝向服务端自己的请求让我们能够了解内网信息的漏洞，我们将它归类为SSRF漏洞。
本次漏洞复现资源，微信公众号：渗透之师，回复005，另外附赠wooyun大佬-猪猪侠的ssrf渗透框架的ppt内容哦！下期内容XXE，敬请期待！
)
)
