前言
风险管理，顾名思义即针对安全风险进行的各种管理动作，在我的理解里包括：如何理解风险、如何发现风险、如何有效规避风险等。今后一段时间我打算用一系列文章和大家分享我对风险管理的一些认识和体会，其中包括我对一些安全问题的理解以及相关的具体技术点，本篇文章是风险管理-资产发现系列的第一篇文章。
风险管理-资产发现系列之公网Web资产发现
针对Web应用的攻击与防御早已成为安全对抗的一个重要细分领域，除了因为Web服务是当今互联网各类业务最主要的服务提供形式之外，还有以下技术方面的原因导致其特别为攻击者所青睐：
（1） 易挖掘
和二进制漏洞相比，Web应用漏洞的挖掘难度相对较低，且在没有源码的情况下也可以纯黑盒挖掘，而二进制漏洞的挖掘则必须至少有对应的可执行程序。
（2） 易利用
同样，Web应用漏洞的利用一般对应用所在环境没有太多要求，而且一般的漏洞都可以在不同环境下达到稳定利用，在这一点上二进制漏洞的利用对目标环境要求较高，且在如今各种由编译器、操作系统提供的安全机制保护下，能够稳定利用的漏洞也是可遇不可求。
（3） 贴合业务
如前所述，Web服务是互联网上主要的服务提供形式，针对Web应用进行攻击通常可以直接在相应业务层面获利。
所以，对于攻击者来说，Web应用是攻击的主要目标之一；同样，对于企业的安全人员来说， Web应用也是其应重点保护的资产。因此，无论是作为攻击者，还是作为企业的安全人员，都需要对Web服务和Web应用保持高度关心。而保持关心的前提，当然是尽可能全面地发现企业拥有的Web资产。下文从外部攻击者的视角出发，提出一些发现目标Web资产的思路和方法。
第一步，找出目标企业注册的所有域名。
Web服务通常通过域名进行提供，所以尽可能全面地获取域名信息对收集Web应用很有帮助。企业注册的域名可以通过域名备案信息查询得到，http://icp.chinaz.com等网站提供了查询的接口，可以根据公司名称或者域名来进行查询。效果如下：
这就是目标所有的一级域名了吗？好像不是。因为我们可以通过企查查等网站，看到目标企业主体还有与其相关联的企业：
通过对其关联企业进行注册域名查询，还可以收集更多的一级域名信息：
第二步，根据第一步中收集到的一级域名信息进行子域名收集。
子域名通常直接对应Web应用，收集子域名的必要性不言而喻。网上有很多收集子域名的方法以及工具实现，这里不再赘述。
第三步，收集目标企业拥有的公网IP信息。
目标Web应用一部分会部署在企业自有的公网IP段内，还有一部分可能会部署在第三方云平台上。所以，尽量准确地找出这两部分IP地址信息也很关键。
分配给企业的公网IP段通常是连续的，基于此这里提供两个寻找目标企业公网IP信息的思路：
一个思路是通过前面收集的子域名的IP地址整理出IP段，一般整理出所在C段即够用。在整理的过程中有几个细节需要注意：
「1」 判断下这个子域名的IP是否为内网IP，如果是则不能用于公网IP段整理（但可以保留结果作为内网域名及内网IP段信息来收集）；
「2」 判断下这个子域名的IP地址是否是第三方云服务器提供商的IP，如果是则不能使用它进行IP段整理（但可以另外收集整理出第三方云主机IP地址列表）。可以通过https://ip.cn/等站点查询IP信息来判断该IP是否属于某个云服务器提供商；
「3」 判断下这个子域名是否使用了第三方CDN服务，其IP是否是CDN服务提供商的IP，如果是则同样不能使用它进行IP段整理。如何判断这个子域名是否使用了CDN呢？一个比较简单的方法是查看这个子域名是否存在CNAME记录，同时判断这些CNAME记录的一级域名是否属于目标企业。如果存在CNAME记录且其一级域名不属于目标企业，则可判断为使用了第三方CDN。
基于上述思路收集目标IP段信息效果如下：
另一个思路适用于比较大型的目标。如果目标企业的网络规模比较大而且有多个出口，则通常会申请AS号（参考RFC1930），这样我们就可以通过查询BGP自治域信息来获取其公网IP段信息。如在https://bgp.he.net 查询alibaba的公网IP段信息（部分）如下：
第四步，在收集到的目标公网IP段内寻找Web服务。
在这一步中，我们通常会指定一些Web服务的常见端口（全端口也可以考虑）去进行Web服务查找。在查找过程中同样存在一些细节：
「1」 针对每个IP的某个端口进行探测时，可以分别使用http和https进行访问，这样可以覆盖到一些只支持http或只支持https的Web服务；
「2」 一个常见的情况是，目标站点不允许直接通过IP访问，只有通过对应域名才能正常访问，在这种情况下我们前面收集的所有子域名就可以派上用场了。针对每一次探测都可以尝试将Host头设置为不同的子域名，这样可以探测出更多的Web应用；
「3」 通过将Host头设置为不同的子域名进行访问，我们还可以应对目标IP是一个反向代理的情况，即该代理会根据请求中的Host头来决定将请求转发到后端哪个具体的Web服务。这里存在一个比较有趣的场景：假如一个公网的反向代理代理了一个本应只能在内网访问的Web应用，那么我们只需在向这个公网IP发起HTTP请求的时候，将Host头设置为该内网Web应用对应的域名，即可成功访问到这个应用（这也是之前收集内网域名的作用），具体原理大概是这样：
至此，通过以上四个步骤，我们可以比较全面地收集到一个企业暴露在公网上的Web服务。那么在发现目标的公网Web服务之后，针对这些Web资产，从风险管理（亦或攻击）的角度出发，接下来应该发掘哪些内容呢？我会在这个系列后面的文章中和大家分享。
