SSRF安全指北(5)_卜八电脑最全问题故障中心

SSRF安全指北

在红框部分是客户端与恶意HTTPS服务器建立了一个完整的TLS连接，Server Hello中恶意服务器返回了一个恶意的session ID，然后进行了一个跳转，利用DNS rebinding将域名指向了本地127.0.0.1，

SSRF安全指北

可以看到客户端向本地发送了一个client hello数据包，数据包中的session id就是恶意服务器设置的session id，从而攻击了客户端本地的memcache。

当然，这种攻击存在一定的局限性，除了依赖于发起请求的客户端外（客户端是否实现TLS缓存），由于TLS协议带有各种字符，例如x00，可能会导致一些应用解析失败，例如就无法通过该方式来攻击redis。以下是议题作者给出的受影响的HTTPS client列表以及可以攻击的应用：

SSRF安全指北

除此之外在复现过程中，笔者还发现了一些其他的限制条件，例如在某些curl版本中会无法复用session id，而且在tls1.3版本中，也会出现复现失败的问题。

整体来讲，虽然复现起来存在一些限制，但是并不妨碍这个议题的思路的独到之处，笔者认为这是2020年web端最厉害的议题。拆开来讲，发起请求的客户端如curl，tls协议都不存在任何问题，议题作者曾表示curl在判断同源时，只判断了协议，域名，端口，但是没有判断ip，这里在笔者看来并非是curl问题，由于负载均衡等问题，域名可能对应多个ip，这种修复方式应该是不会被采纳的;而session id/ticket更是tls为了提高性能而提出的机制，这个机制本身不存在问题，但是这两个组合起来加上ssrf就达到了意想不到的效果。

SSRF修复

SSRF的修复比较复杂，需要根据业务实际场景来采取不同的方案，例如前面说到的python中不同url库对url的解析就不一致，所以对于有条件的公司，建立一个代理集群是比较可靠的方案，将类似请求外部url的需求整理出来，分为纯外网集群和内网集群进行代理请求。

如果需要从代码层面来修复的话，需要注意一下几点：

去除url中的特殊字符

判断是否属于内网ip

如果是域名的话，将url中的域名改为ip

请求的url为3中返回的url

请求时设置host header为ip

不跟随30x跳转（跟随跳转需要从1开始重新检测）

其中第一步是为了防止利用url parse的特性造成url解析差异，第三步是为了防止dns rebinding，第5步是为了防止以ip请求时，某些网站无法访问的问题，第6步是为了防止30x跳转进行绕过。

结语

在笔者看来，安全问题从某种程度来讲，其实是攻击者与防御者对同一事物的认知问题，当攻击者的认知超出防御者时，就会找到新的绕过方式，而当防御者的认知跟上之后，又会促使攻击者寻找新的方式，这一点在ssrf漏洞上体现得淋漓尽致。安全上的攻防，其实就是人与人之间的博弈，这也是安全的魅力所在。