大讲堂 | Java 异常日志记录最佳实践（大讲堂的目的和意义）

大讲堂 | Java 异常日志记录最佳实践（大讲堂的目的和意义）

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

日志?谁需要日志?

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

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

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

创建并遵循日志记录策略

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

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

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

记录完整的堆栈跟踪

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

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

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

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

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

记录所有异常

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

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

不要将异常返回给用户

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

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

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

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

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

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

不要记录敏感信息

信用卡号码社保号码密码

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

会话标识符授权令牌个人姓名电话号码用户选择退出的信息(例如，不跟踪)

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

别让自己身处黑暗之中

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

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