应用安全系列之三十三：配置管理

        安全配置错误可能发生在应用栈的任何一层，包括平台、Web服务器、应用服务器、框架和自定义的代码中，在任何一层都需要一定的流程或者措施进行检查，以防在安全的产品中留下一个不安全的“后门”。开发应用服务的人和配置管理应用服务的人通常不是一批，他们对整个系统的理解可能会有些不同，就需要双方共同协作才能确保一个站点的安全。因此，最近比较流行的DevOps流程就是加强开发和系统维护人员之间的沟通，降低配置错误。

        以Tomcat为例，安装了Manager组件的Tomcat，可以通过8080端口访问管理界面，Tomcat提供了默认的用户名和密码（admin/pass），如果这个密码没有被修改，直接部署在产品的服务器上，会有什么后果？一旦攻击者探测到这个弱点，攻击者就可以上载自己的war包，在Tomcat上部署自己的程序，程序所做的事情也完全由实现者决定，可以增加、删除文件，可以执行系统命令，甚至可以格式化硬盘。攻击者还可以通过默认的用户、废弃不使用的页面、未保护的文件或者文件夹来获得系统的一些内部信息，进而可以在未授权的情况下访问一些资源和使用一些功能。安全配置错误经常会导致系统的一些数据或者功能可以在未授权的情况下被访问。偶尔，也可能导致整个系统被攻击者控制，系统的所有数据都会被偷窃或者被修改，而且，修复的代价可能会较高。安全配置引起的错误可能以前没有被重视，包括产品生产者和攻击者，近几年关于配置错误引起的攻击也越来越多，也导致了一些比较重大的攻击，例如：索尼的数据泄漏事件，被认为是最严重的数据泄漏攻击。在2010年OWASP的最严重的Web应用安全风险分析排名中，安全配置错误在从来没有进入前十的情况下，一跃成为第六。可见，其危害性越来越大，应当受到更多的关注，特别是在产品的开发、部署和维护的过程中，需要时刻关注可能产生问题的配置，及时更新配置，使风险降到最低。

        安全配置错误由很多原因造成，本章将介绍几个比较典型的配置错误，以及这些配置错误的检测和预防方法。

        系统配置

        一般的系统都会默认自带一些服务，如果产品中不需要这些服务，最好将这些服务禁用，以防由于这些服务存在的漏洞，使得攻击者可以控制整个机器。每个服务都会使用一些端口，所以，可以通过端口号来识别服务。目前，流行的Nmap工具可以很好地检测。

        Web应用服务器的配置

        Web服务器或者应用程序服务器的配置对整个网站的保护起着重要作用。根据网站提供的功能和需求的不同，对配置的要求也不一样，必须仔细检查，避免将常规错误引入到配置。大多数情况下都应该遵守一定的配置方针进行配置，以确保服务器的安全。

        无论流行的Apache、Tomcat、Nginx以及IIS，还是其他的Web服务器应用程序，都需要注意一下几点：

• 确保已经安装了最新的安全补丁 ，以防使用了含有严重漏洞的版本，即使关注相应开源组件的漏洞发布情况，即使升级；
• 只启动应用程序需要的服务模块，对于不需要的模块，最好的办法就是不要启用它，可以减少攻击面；
• 在配置响应消息的有关信息时，尽量使用模糊的字段，以防信息泄露【应用安全系列之三十一：信息泄露_jimmyleeee的博客-CSDN博客】，例如：HTTP Header的Server 头，这个字段会显示当前服务器的类型和版本，Apache在安装的时候，默认的是显示正在运行的Apache版本以及操作系统的版本，甚至，会显示哪些模块被安装在服务器上。 默认的错误页面也会泄露内部的版本信息，需要定制统一的应用程序的自己的错误处理页面。
• 确保运行在正确的用户和组下，一些Apache安装之后，默认以用户nobody运行。如果其他的服务业（邮件服务）以nobody用户运行，一个用户可以通过Apache攻破邮件服务。可以通过修改配置文件，设置Apache运行的用户和组。
• 重新设置Web应用的根路径，使用默认的路径，攻击者就很容易根据默认的路径进行猜测与攻击，特别是路径遍历漏洞【应用安全系列之十一：路径遍历_jimmyleeee的博客-CSDN博客】，很容易泄露内部应用的敏感文件的内容；
• 根据需求设置可能导致DOS攻击的项目，例如：timeout的设置；消息体的大小的限制；并发连接数量的限制。
• 产品不能运行在Debug模式；
• 删除不必要的开源软件的实例或者文档等文件，对于一些不必要的配置文件，也可以一并删除；

数据库的配置问题

• 默认的用户名和密码或者非常简答的密码，经常在一些代码审计时发现配置文件中竟然使用了MySQL的root和pass来登录；
• 应用程序使用的数据的账号的权限问题，对于绝大多数应用系统而言，不需要使用数据库的管理员角色，有些人为了省事，直接使用root账号访问数据库，一旦应用程序有SQL注入攻击，攻击者就很容易发起删除操作进而造成DOS攻击。一般建议每个APP根据需要创建一个适当的角色，根据最小权限原则赋予权限。曾经遇到一个系统，在设计时允许用户自己组装SQL来查询数据库中的数据，构建自己需要的报表，但是，此应用使用的访问数据的用户root,一旦某个用户在组装SQL语句出现纰漏或者故意做一些破坏，随时会很严重，最后，建议创建一个只读的账号专门；

日志的配置

       首先需要提到的就是日志保存的位置。通常情况下，服务器会对各项操作和错误产生一些日志信息，并且存储在本地，如果服务器有漏洞，攻击者就可以修改日志或者清空日志，这样攻击的现场信息就被毁掉。这样即使知道服务器受到过攻击，系统管理员也无法查找到任何关于攻击的痕迹和证据。所以，比较明智的做法就是将日志保存在一个独立的位置，而不是在Web服务器上。这样攻击者就不能很容易地操作日志，同时，在审计日志的时候也不会影响服务器的运行。

        其次，就是日志的存储，因为随着时间的积累，用户数量的增加，日志的信息量会越来越大。如果控制不当，可能引起拒绝服务攻击的发生。之所以可能发生拒绝服务攻击，是因为如果服务器的日志没有正确配置，日志文件可能会存储在与应用程序软件相同的磁盘分区，如果日志是持续积累的，那么，当磁盘空间被占满时，系统会因为无法写硬盘而拒绝服务，特别是对于数据库所在的服务器。对于UNIX系统，可以将日志保存路径设为路径/var或者/opt，这样可以确保日志的目录在单独的分区。Apache Web服务器的日志一般存在/var/log/apache，最好也放在一个单独的分区。

        循环日志有风险，可以通过适当的备份日志来减少风险，但是，备份的存储空间也是有限的。为了提高空间利用率可以采用压缩技术，目前市场上流行的压缩技术中，有的对文本文件的压缩可以达到3:1，因为日志文件都是纯文本文件，而且相对来说重复的内容较多，所以压缩率会更高，这样可以充分利用有限的空间存储更多的日志。

协议的配置

        关于协议最重要的一点就是，默认不传输没有加密的数据。在配置环境的时候，可以强迫系统使用安全的协议（SSL或者TLS）。一般的用户通过IE访问站点时，都不会主动使用HTTPS协议，用户会输入www.example.com，浏览器默认使用HTTP协议，也就是http://www.example.com，而不是https://www.example.com，这时，可以采用重定向将针对这个不安全协议的访问重定向到https://www.example.com，方法是返回HTTP的状态码302，响应页面中的location设置为https://www.example.com。其他的方法可以参考第17章。

        凡是跨网络的链接都要求使用安全的协议（SSL或者TLS），尤其是和第三方集成的时候，在进行传输之前，认证第三方的身份很重要，SSL和TLS协议都提供了这些功能。如果在一个网络内部连接，通过外网不能访问，这样的环境可以根据具体对安全的需求，决定是否使用安全的连接。安全级别高的环境，建议还是使用安全协议，这样可以提高环境的安全性。最好在系统的管理界面，提供选择使用安全连接和非安全连接的选项，这样可以在需要的时候动态切换，而不需要进行二次开发。

         安全的协议也需要客户端与服务器端配合才能安全地运行，对于浏览器，一般都会按照标准来实现，但是，对于自开发的客户端，需要严格验证证书的有效性，包括确定证书有效期、检查认证机构（CA）是否是值得信赖的、检查该证书目前是否是有效的、检查网站的名称是否与证书中的名称相符、检查证书的用途是否相符等。

编译器的配置

              一般的大型网站的后台都会有一些后台服务，而这些后台服务往往都是使用C/C++实现的。谈到C/C++可能有些读者会想到缓冲区溢出的问题，因为缓冲区溢出这个问题对于C/C++来说是最严重的问题，轻则使服务暂停工作，重则让攻击者执行Shell脚本控制后台服务器。对于开发人员来说，如何有效地预防缓冲区溢出问题也是一个挑战。

        程序有缓冲区溢出问题之后，可能改变程序的运行逻辑使程序以奇怪的方式运行；如果破坏了堆栈，还可能引起程序崩溃，导致DOS攻击；严重的更可以导致攻击者注入恶意代码，通过恶意代码控制机器。

        随着缓冲区溢出问题的泛滥和危害的日益加重，不少编译器厂商尝试在编译器环节添加一些编译选项来预防缓冲区溢出问题的发生。目前采用的主要措施有以下3种：第一种，堆栈不可执行；第二种，检测堆栈溢出，终止程序；第三种，动态地址载入。

        总之，只要编译器提供了安全的编译选项，如果没有什么特殊需求，尽量都打开使用。

容器的配置

        随着容器的流行，容器的安全也越来越重要，幸运的是这些容器的配置是可以使用工具根据指定的基线进行检测的，例如Docker，从网站上下载的默认的Docker也不一定就是安全和服务企业内部需求的，下载之后，可以使用docker-bench-security（https://github.com/docker/docker-bench-security）对其进行检查。

        企业内部可以定制一套符合自己安全和应用需求的安全基线，然后在企业内部统一推行，可以是的各种开源组件、操作系统以及数据等可以有效地统一管理。有了统一的基线，结合当前流行的IaC工具也可以指定规则对企业内部的所有的配置信息进行扫描，发现有安全风险的配置选项，可以及时发现，及时修复。

关于配置需要记住以下三点： 

1. 即要保证应用程序自身的正确性，也要保证应用程序所使用的程序或者框架的正确性；
2. 既要保证应用程序自身配置的安全性，也要保证应用程序所使用的程序或者框架的配置的安全性；
3. 既要保证应用程序自身系统的安全性，也要保证应用程序运行所依赖的系统的配置的安全性。