OneAPM大讲堂 | Java 异常日志记录最佳实践

【编者按】本文作者是 Casey Dunham。Casey 是一位具有 10 多年经验的专业软件开发人员，以其独特的方式应对应用安全问题而闻名。本文系国内 ITOM 管理平台 OneAPM 工程师编译整理。

作为安全顾问，我对各种应用程序进行评估。 在我测试过的所有应用程序中，我发现它们通常会遇到一些对异常问题的处理和日志记录不足。日志记录和监控往往是被忽视的领域，并且由于对 Web 应用程序的威胁日益增加，它们已被添加到 OWASP Top 10 的十大问题之一，名为“Insufficient Logging and Monitoring(没有足够的日志记录及监测)”。

这会带来什么问题？让我们来看看。

日志?谁需要日志?

首先，为什么我们要使用日志？重点是什么？

正确的日志记录不仅适用于调试应用程序，而且对取证和事件响应也有许多的益处。您如何知道某人是否正在针对您的应用程序运行漏洞扫描程序？或者正在进行强力攻击程序试图访问用户帐户？能知道这些当然最好，但还有其他更微妙的事情。

大多数成功的攻击都是从攻击应用程序并寻找其弱点。攻击者对应用程序进行调查的次数越多，攻击者可以找到并成功利用该应用程序弱点的可能性就越大。攻击者之所以能够保持攻击是因为其攻击被忽视了，并且由于违规检测平均周期 191 天，日志通常是我们能看到攻击正在发生的唯一方式了。没有日志信息的话，我们将很难评估谁在什么时候访问以及访问的深度。

创建并遵循日志记录策略

我很少见到一个具有实际日志记录策略的应用程序。 大多数情况下，我们实施日志记录已经是问题出现后的做法了。 我想这可能也算一种策略，但我们能做得更好吗? 我想我们可以。

当您将日志记录添加到应用程序中时，最好有一个总体一致的策略。 尽可能在所有应用程序中使用相同的日志记录框架。 这样就可以实现轻松地共享配置，如消息格式，并采用一致的日志记录模式。什么情况下需要记录出现警告/错误以及要使用哪些日志记录级别需要有一致的准则。 在记录任何东西时，消息格式应至少包含时间戳，当前线程标识符，调用者标识和源代码信息。 所有现代日志记录框架都支持这种类型的信息。

将所有这些作为开发人员文档的一部分，这将是在所有业务应用程序中创建和维护日志记录的绝佳方式。

记录完整的堆栈跟踪

在我所做的许多安全代码预览中，我经常看到的一个错误是：不记录整个堆栈跟踪以用于查找异常。 以这个假设为例，这是我多次看到的一个典型错误模式：

这个例子有好几个问题，我们只关注处理 SQLException 的部分。 比方说，在生产中看日志时，我们看到了这个：

这并没有告诉你很多信息。 什么导致了 SQLGrammarException？记录器会把所有包含抛出对象的异常进行归类，并且写出堆栈踪迹。 通过稍微改变代码，我们就能更清楚地了解发生了什么：

用这个代码我们就能完整的记录堆栈跟踪了，记录清楚地显示了一些邪恶的活动正在悄悄进行。

现在，只要查看日志，我们可以立即看到问题所在。 有人试图用 Acme’来查找客户，并打破了我们的 SQL 语句。 这个异常明确显示了 SQL 注入，如果我们分析日志时只能看到原始消息，这就很容易被忽略。 我们很可能没有深入考虑这个问题并转向了其他问题，导致没有发现这个严重的缺陷。

记录所有异常

“吞噬”异常是我看到的另一个很常见的问题：在应用程序的某个地方抛出一个异常，开发人员打算用 catch 块来处理，但由于某种原因，开发人员忘记了它或者认定它不重要。 以下示例说明了此问题：

据我的经验，这种做法非常普遍并且值得一提。 记录异常，重新抛出异常，或者根本不处理异常，在日志中都不会显示应用程序出现了任何问题。 我们没有理由不记录异常。“吞噬”这样的异常会导致隐藏在底层的问题被忽视，最终导致业务逻辑或安全漏洞问题。

不要将异常返回给用户

在执行任何类型的安全评估时，每一条有关应用程序或其环境的信息都可能有用。 看似无害的错误信息可能正是顾问(或攻击者)所需要的。 顾问们可能找到您的系统的一个漏洞-对系统进行攻击或者大大减少有效负荷，如果错误信息揭示相关漏洞正在使用的数据库系统的信息，那么我们需要对这个漏洞进行 SQL 注入测试。

通过某种错误处理简单地向用户返回异常消息也是一种常见的做法。 在测试身份验证系统时，我遇到了很多问题，如以下屏幕截图所示：

 

 

处理这个问题的代码可能会这么做：

稍后，异常会被抛出并被捕获。 开发人员用异常信息编写传达给用户的报错信息，这导致用户能够看到系统原始的异常信息。

就异常处理而言，这不仅是不好的做法，而且还会打开用户帐户验证的应用程序。 根据您正在处理的应用程序的类型，这本身可能就存在风险。

切勿将异常对象的内容返回给用户。 捕获异常，记录它并返回一个通用响应。 随着代码的进化，您永远不会知道异常消息可能包含哪些信息，并且异常消息本身是否会在将来发生变化。

不要记录敏感信息

我提到日志不仅可用于调试，还可用于合规性，审计和取证。 由于日志有很多用途，并且我们倾向于“记录所有内容”，它们可以成为惊人的信息来源。 如果日志包含用户名，密码，会话令牌或其他敏感信息，它确实减少了攻击者的工作量。 日志将揭示应用程序的内部工作和失败，攻击者可以使用这些进一步攻击应用程序。 因此，我们需要谨慎的对待日志并将其安全保存起来。 不应被记录信息如下：

• 信用卡号码

• 社保号码

• 密码

但以下类型的信息也不应被写入日志中：

• 会话标识符

• 授权令牌

• 个人姓名

• 电话号码

• 用户选择退出的信息(例如，不跟踪)

还有一个问题：一些司法管辖区不允许跟踪某些信息，这样做违反了法律。 了解应用程序的合规性要求及其处理的数据非常重要。

别让自己身处黑暗之中

虽然日志记录不是一项复杂的任务，但在正确使用日志方面有很多微妙之处和平衡点。 太少的信息没有太大价值，但是如果处理不当，太多的信息有可能变成负担。

记录应用程序日志不是选择题， 没有足够的日志，你将身在黑暗之中。

OneAPM Li 智能日志分析平台可以实时收集数据中心基础架构及应用的海量日志，实时搜索，实时分析，洞悉日志价值。想阅读更多技术文章，请访问 OneAPM 官方技术博客。

原文地址：https://blog.scalyr.com/2018/03/java-exceptions-log/