IT学习网 - 爱学习 - 最具影响力综合资讯网站 -- 中国IT界的领航者!
热门关键字:      88888  as  xxx
站外
广告
站外
广告

SSRF的新纪元:在编程语言中利用URL解析器

发布时间:2017-08-03 22:49文章来源:互联网文章作者: 佚名点击次数:
并非完全翻译,掺杂了一点自己的私货和见解。 什么是SSRF [1] 服务器端请求伪造 [2] 穿透防火墙,直达内网 [3] 让如下的内网服务陷入危险当中 Structs2 Redis Elastic SSRF中的协议走私 [1] 让SSRF的利用更加有效 本质上说,是利用原本的协议夹带信息,攻击到目

并非完全翻译,掺杂了一点自己的私货和见解。

什么是SSRF

[1] 服务器端请求伪造

[2] 穿透防火墙,直达内网

[3] 让如下的内网服务陷入危险当中

Structs2

Redis

Elastic

SSRF中的协议'走私'

[1] 让SSRF的利用更加有效

本质上说,是利用原本的协议夹带信息,攻击到目标的应用

[2] 用来'走私'的协议必须是适合的,比如

基于HTTP的各类协议=>Elastic,CouchDB,Mongodb,Docker

基于Text的各类协议=>FTP,SMTP,Redis,Memcached

一个有趣的例子

像这样的一个协议

\

我们来分析一下,各个不同的python库,分别请求到的是哪个域名呢?

\

可以看到,Python真是个矛盾的语言呢。

另一个有趣的例子

[1] HTTP协议中的CRLF(换行符)注入

[2] 使用HTTP协议'走私'信息来攻击SMTP协议

我们尝试构造CRLF注入,来进行如下的攻击

\

STMP '讨厌' HTTP协议

这似乎是不可利用的,可是,真的如此么?

我们在传统的SSRF利用中都使用gopher协议来进行相关攻击

可是事实上,如果真实的利用场景中不支持gopher协议呢?

利用HTTPS协议:SSL握手中,什么信息不会被加密?

[1] HTTPS协议中的CRLF(换行符)注入

[2] 化腐朽为神奇 - 利用TLS SNI(Server Name Indication),它是用来改善SSL和TLS的一项特性

允许客户端在服务器端向其发送证书之前请求服务器的域名。

https://tools.ietf.org/html/rfc4366RFC文档

简单的说,原本的访问,是将域名解析后,向目标ip直接发送client hello,不包含域名

而现在包含了域名,给我们的CRLF攻击提供了利用空间

我们尝试构造CRLF注入,来进行如下的攻击

\

监听25端口

\

分析发现,127.0.0.1被作为域名信息附加在了client hello之后

\

由此我们成功的向STMP'走私'了信息,实施了一次攻击

URL解析中的问题

[1] 所有的问题,几乎都是由URL解析器和请求函数的不一致造成的。

[2] 为什么验证一个URL的合法性是很困难的?

1.在 RFC2396/RFC3986 中进行了说明,但是也只是停留在说明书的层面。

2.WHATWG(网页超文本应用技术工作小组)定义了一个基于RFC的具体实现

但是不同的编程语言仍然使用他们自己的实现

RFC 3986中定义的URL组成部分

大致用这张图片来说明

\

其中的协议部分,在真实场景中一般都为http或https

而查询字符串和fragment,也就是#号后的部分,我们实际上是不关心的,因为这和我们的利用无关
SSRF的新纪元:在编程语言中利用URL解析器
本文由 IT学习网 整理,转载请注明“转自IT学习网”,并附上链接。
原文链接:http://www.ourlove520.com/Article/diannao/wangluo/1032137.html

标签分类:

上一篇:上一篇:元数据:黑客最好的朋友(上)
下一篇: 下一篇:没有了
无觅关联推荐,快速提升流量