Question

应用程序输出的日志在安全方面上也有很重要的意义，下面我们就看看应该如何去考虑日志的输出。

5.4.1　日志输出的目的

应用程序的日志之所以在安全方面有重要意义，原因有以下 3 点。

• 通过日志发现被攻击或者事故的先兆，可以防患未然
• 用于在遭受攻击或者发生事故后进行事后调查
• 用于进行应用程序的运维审查

在 5.1 节里我们已经对从日志里发现攻击预兆进行了说明。如果日志里记录的尝试登录或者登录失败的次数比平时多的话，则很可能是受到了外部攻击。如果想做类似的调查，那么日志里必须要记录尝试登录及登录结果的信息才行。

另一方面，如果 Web 应用受到攻击后发生损失，也需要对攻击的详细情况进行深入的调查，这时候日志文件也是不可或缺的。如果日志没保存下来，或者保存的信息不足，要想做更深入的调查就比较困难了。

5.4.2　日志种类

Web 应用里面涉及的日志大概有以下几种。

• Web 服务器（Apache、IIS 等）的日志
• 应用程序的日志
• 数据库的日志

这三种日志都是必不可少的，我们这里仅对应用程序的日志做详细说明。应用程序的日志也可以细分为下面几类。

• 错误日志
• 访问（Access）日志
• 调试（DeBug）日志

下面分别说明这 3 种类型的日志。

错误日志

错误日志，顾名思义，就是记录应用程序里出现的各种错误信息的日志。当 Web 应用程序内部发生错误的时候，除了在页面内显示给用户诸如“服务器忙，请稍候再试”等信息外，还要将错误的详细情况及原因等记录到日志里。之所以这么做，是因为将错误的详细信息显示给用户，除了使用户困惑以外毫无用处，而且还可能会给攻击者提供攻击线索。而记录到日志里，能为调查或者发现问题提供方便。

错误日志也可以用来检测攻击。比如攻击者在尝试 SQL 注入或者目录遍历攻击的时候，日志中应该存在很多 SQL 错误或者文件打开错误。这些错误正常情况下应该是很少发生的，如果持续发生这样的错误的话，就要怀疑系统是否正在遭受攻击。即使这些错误日志不是由于攻击造成的，考虑到提高应用程序的稳定性，也应该对此类错误进行详细调查并进行修改。

访问日志

访问日志是 Web 应用程序里记录用户访问某资源或者使用某功能的日志。和错误日志不同的是，不管是正常还是异常的访问，都需要记录到访问日志里。

Web 应用程序刚出现的时候（大概在 2004 年之前），多数应用程序中只记录错误日志，也就是说很多异常情况虽然都在应用程序日志里记录下来，但是正常情况的日志还都基本依赖于 Web 服务器记录。不过之后为了应对个人信息泄漏事件等，人们也开始逐渐重视起正常的访问日志来了。

为了达到前面 5.4.1 节里说的日志的 3 个目标的要求，记录正常的访问日志也是很重要的。

另外，很多法律、规范等也要求应用保存访问日志。比如在日本至少就有《个人信息保护法》、《金融商品交易法》以及《Payment Card Industry（PCI）数据安全法规（PCI-DSS）》等法律、法规等对个人信息、访问日志等做出了明确的规定。

调试日志

调式日志，顾名思义，是用来输出调试信息的日志。调试日志输出量太大的话，可能会影对系统的性能造成影响。而且，如果调试日志输出的内容过于详细甚至包括敏感信息的话，还可能带来个人信息泄露问题。调试日志一般只在开发或者测试环境中输出，在生产环境下则不应该输出调试日志。

5.4.3　有关日志输出的需求

这一节我们将对在设计时要考虑的日志相关的需求加以说明。

• 需要记录到日志里的所有事件
• 日志里应包括的信息和格式
• 日志文件保护
• 日志文件保存位置
• 日志文件保存期限
• 服务器的时间调整

需要记录到日志里的所有事件

需要记录到日志里的事件类型，既不能过多也不能太少，要根据日志的使用目的来决定都需要记录哪些事件。一般来说涉及下面列举得用户认证、账号管理等重要信息及操作，需要记录到日志里。

• 登录、退出（包括成功和失败两种情况）
• 账号冻结
• 用户注册、删除
• 修改密码
• 查看重要信息
• 重要操作（购买、转账支付、发送邮件等）

日志里应包括的信息和格式

日志里面需要记载的信息，根据 4W1H（When、Who、Where、What、How）的原则，应该包括下面列出的一些内容。

• 访问时间
• 远程 IP 地址
• 用户 ID
• 访问资源对象（URL、页面编号、脚本 ID 等）
• 操作类型（查看、修改、删除等）
• 操作对象（资源 ID 等）
• 操作结果（成功或者失败、处理记录数量等）

另外，系统监查可能需要查询很多种类型的日志，所以日志的格式最好统一，以方便日后查看。

日志文件保护

如果日志文件被篡改或者删除的话，那么其存在的意义也就没有了，所以对日志文件自身的安全也必须给以足够的重视并加以保护。除了文件被破坏以外，由于日志中还可能包含个人信息或者其他敏感信息等，也应该限制只有有相关权限的人才能查看日志。

为了保护日志文件，尽可能将其保存在 Web 服务器或者数据库服务器以外的地方，并且分配日志管理者这一角色，并将此角色和网站管理者分离。

日志文件保存位置

日志可以选择保存到文件里，也可以保存到数据库中，但是出于上一小节提到的日志保护的目的，最好把日志保存到单独的服务器上。也许这会导致运营成本上升，所以需要在设计阶段即开始讨论此问题。

日志文件保存期限

在最初的设计阶段，还要根据网站性质，决定各种日志文件的保存期限策略。但是考虑到为了方便对安全事件进行调查，也许很难设置一个合理的日志保存期限，所以也有人采用无期限保存日志的方法。

但是同时日志文件里有可能包含机密信息，如果保存期限变长，那有可能提高信息泄漏的危险，这就和上面所说的矛盾了。我们可以将日志定时地复制到 DVD 光盘，然后将这些媒体保存在物理上安全的地方等，这样即能延长日志保存期限又能保护日志安全。

服务器的时间调整

单一日志文件有时候意义不是很大，更多时候是同时从 Web 服务器、应用程序、数据库、邮件等各种日志同时展开调查。在从众多的日志中寻找线索的时候，就需要统一各个服务器的时间。

为了达到各个服务器时间统一，可以通过使用 NTP（Network Time Protocol）协议来进行服务器间时间的同步设置。

5.4.4　实现日志输出

日志的保存方法主要有保存到文件或者保存到数据库两种，我们选择哪种实现都可以。我们也可以选择使用专门针对日志而开发的第三方库。比较有代表性的第三方日志库包括为 Java 准备的 log4j。log4j 现在是 apache 基金会的一个项目，现在不仅是 Java，还有专供 PHP 使用的 log4php，以及供微软 .NET 使用的 log4net 等衍生产品 22 。

22 http://logging.apache.org/

使用 log4j 或者 log4php 的好处有如下几点。

• 可以通过简单设置来指定日志保存位置
• 根据日志使用目的不同，可以在不同的保存位置自由切换
• 可以通过配置文件配置日志格式（也称为 Layout）
• 可以指定输出日志的级别，并且可以不通过修改代码就能修改日志输出级别

log4j 自带的日志保存类型包括以下几种，我们甚至可以不修改代码就能实现按用途将日志分开保存到不同的地方。

• 文件
• 数据库
• 邮件
• syslog
• Windows 事件日志（NTEVENT）

log4j 提供的日志级别有以下几种，顺序为按严重程度从高到低。

• fatal（致命错误）
• error（错误）
• warn（警告）
• info（信息）
• debug（调试）
• trace（跟踪，输出比调试更详细的信息）

一般来说我们会在开发时将日志输出级别设置为 debug，然后在生产环境中指定为 info 级别，这样的话不用修改代码，也能获取重要程度在 info 以上的日志。

5.4.5　总结

在这一节我们主要针对日志的重要性及安全需求设计做了详细说明。

从系统安全的角度来看，日志不仅有助于在早期发现潜在的攻击事件，还能有助于发生安全事故后的详细调查。

要想记录有效的日志，我们应该遵循 4W1H（When、Who、Where、What、How）的原则采集日志，并且确保日志本身的安全。另外，为了同时能调查从多台服务器采集的日志，还需要通过 NTP 来统一服务器的时间设置。