应用安全系列之三十一：信息泄露

当攻击者攻击某个系统时，首先要做的就是收集目标系统的信息，然后，根据收集的信息再搜索可能存在的漏洞，对系统发起攻击。

当系统的实现或者配置不正确时，却正好可以提供攻击者想要的信息，下面就列出一些容易出现信息泄露的方面。

业务逻辑的提示信息

业务逻辑设计时会涉及到错去的情况如何处理，提示什么信息，提示的信息如果不注意处理，就可能会导致信息泄露。例如：登录时提示用户名是否有效，就可能被用于发起用户枚举攻击；当访问某个内部对象的时候，提示此对象不存在，就可以收集内部存在的对象信息等等。

针对此种情况，一般建议错误信息不要太具体，使用一些模糊的错误信息，因为有些时候出现这种错误时，就说明此操作有问题了。

服务器信息泄露

        在HTTP响应消息的Header中，有些字段会显示服务器的类型与版本，一般组件的默认配置都会显示，例如：Server、X-Powered-By，X-AspNet-Version等，示例如下：

 通过此新消息的头内容，可以知道服务器端使用了 Microsot-IIS/8.5 ASP.net的版本是4.0.30319等信息，再通过Vendor, Product and Version Search搜索指定的工具和版本，就可能搜索相关的版本是否有CVE，以及有哪些CVE，然后，根据这些CVE的PoC脚本，对系统发起攻击。

异常信息泄露

有些系统在处理异常的时候，直接调用exception.printStackTrace,这会导致异常信息被输出到页面，如下图：

根据异常的信息，可以知道使用了什么框架，根据具体出异常的文件名称和代码行号，又可以找到大概是什么版本，然后再去查询这个版本是否有什么CVE。

有的异常信息页面的底部会直接显示使用的组件和版本信息，就更加容易去查询CVE了。如下图：

有的甚至把异常信息直接放在JSON对象中返回，如下图：

从这异常信息中，可以看出使用的是MySQL数据库，一些字段的名称，可能你根据这个错误信息也就猜到了，这里有SQL异常信息，也就可能有SQL注入攻击。 

当系统出现异常时，一般都可能是输入的数据没有做正确的输入验证或者受到了攻击，遇到这种情况，异常信息可以保存到日志中，而不是输出到页面里。虽然输出到页面，使问题更加明显，容易调查，但是，同时它也会提供给攻击者一些可以用于下一步攻击的信息。

错误处理不当导致信息泄露

当系统遇到预料之外的输入时，有些系统没有统一的错误处理，就会将出错的信息和内容直接输出到页面，

 这些内部配置相关的信息，其实不应该直接回显到页面。 一旦程序出错，可以根据出错的原因编号，每个编号对应一个错误原因，这样可以根据页面的显示的编号来了解具体的原因，而不是通过显示很多内部信息，而且，还对问题的调研没有什么帮助。

访问控制不当导致信息泄露

当系统的访问控制不当时，会导致内部的信息泄露。水平越权，可以导致同一级别用户的信息泄露；垂直越权，则会导致整个系统的内部数据的泄露；具体可以参考：应用安全系列之二十二：授权问题_jimmyleeee的博客-CSDN博客

注入问题导致信息泄露

当系统存在SQL注入、LDAP注入或者XPath注入时，可能导致认证被绕过或者通过注入获取更多的内部数据，对系统内部的信息安全造成巨大的威胁；具体可以参考：应用安全系列之一：SQL注入_jimmyleeee的博客-CSDN博客

应用安全系列之四：XPATH注入_jimmyleeee的博客-CSDN博客

应用安全系列之五：LDAP注入_jimmyleeee的博客-CSDN博客_ldap注入

敏感信息写入日志

有的开发人员为了Debug方便，将敏感信息包括：邮件、地址以及电话等信息写入日志，由于日志的保护没有产品环境的数据保护的级别高，增加敏感数据泄露的风险。一般情况下，产品的研发环境和产品实际的部署环境是分开的，人员也是分开的，不同系统的数据也应该彻底分开，降低不必要的数据泄露的风险。如果将敏感数据写入日志，在调查产品线问题时，研发人员需要访问日志，这机会让更多的人看到产品线上的实际用户的数据，就打破了这种制度上的和物理上的隔离措施。

随着手机APP的流行，各个国家或者地区针对手机APP的合规要求也很严格，因此，如果移动APP将个人敏感信息写入日志，可能会在审计时收到挑战。

在做代码审计的过程中，有些代码也没有明确将一些敏感数据写入日志，但是却将SQL语句或者Spring框架中的DTO对象直接写入日志，一旦SQL语句或者DTO对象中含有用户名和密码，就会导致用户名和密码直接写入日志。所以，做代码审计时，不仅要关注直接写入敏感信息的代码，也需要关注间接写入敏感信息的代码。

要检测这种情况，最好的方法就是使用SAST工具，制定专门的扫描规则，可以有效地发现所有的问题并及时解决。

URL中的敏感信息

URL中的信息可能会被缓存在浏览器、代理服务器、Web 服务器，甚至会被写入web服务器的日志。一旦URL中含有敏感信息，例如：密码或者token等，这些信息就会被以明文保存到不同的地方，增加了这些数据泄露的风险。

一般建议使用POST方式，在Body中传递数据，并且启用安全协议，保护数据在传输中的安全。

API返回过多的PII数据

很多系统都采用微服务架构，每个服务都会提供一些API供外界调用。有些API会返回一些用户的PII数据，可能API的设计者为了省事和降低API数量，会设计一些API返回比较多的信息，这就会让一些功能可能只需要一部分数据，也通过这个API获取了比实际需要更多的数据。特别是和第三方合作时，如果返回比实际需要多的信息，而又没有办法保证第三方也提供同样级别的数据保护时，就会增加这些数据别泄露或者滥用的可能。

随着数据安全相关的法律不断地健全，个人数据的保护越来越重要，为了降低PII数据泄露的风险和承担一定的法律责任，最好不要将不必要的数据通过API返回，毕竟，数据保留在自己的系统内，自己才能够有效地控制和保护。

        综上所述，信息泄露涉及的方面是很多的，为了做好信息泄露需要做好一下几点：

• 做好系统保护，防止注入漏洞的发生；
• 设计好访问控制机制，避免水平和垂直越权；
• 设计错误信息时，不泄露内部数据是否有效的信息；
• 配置服务器时，需要过滤服务器的版本和使用的框架的版本；
• 错误处理时，需要一个统一的错误处理机制，返回有效的错误提示；
•  对敏感信息做好分类，在传输、使用和保存时，根据级别做好保护；
• 严禁将敏感信息写入日志；
• 设计API时，根据需求返回敏感数据，尽量避免返回过多的而且不需要的敏感数据；如果有不同需求，可以提供不同的API来满足需求
• 避免在URL中传递敏感信息，在消息体中或者Header中传递敏感信息；