QQ泡沫乐园 · 免费提供游戏辅助,破解软件,活动资讯,喜欢记得收藏哦!
综合软件_线报活动_游戏辅助_最新电影_最优质的的辅助分享平台

这会10的十大问题之一(没有)带来什么问题

泡沫乐园 2022-05-24 02:05

作为一名安全顾问,我评估各种应用程序。在我测试过的所有应用程序中,我发现它们通常缺乏对异常问题的处理和记录。日志和监控往往是被忽视的领域,并且由于对 Web 应用程序的威胁越来越大,它们已被添加到 OWASP 十大问题之一,标题为“日志和监控不足”。监视器)”。

有什么问题?让我们看看。

首先,我们为什么要使用日志?有什么意义?

正确的日志记录不仅有利于调试应用程序,而且有利于取证和事件响应。您如何知道是否有人正在针对您的应用程序运行漏洞扫描程序?或者是一个暴力攻击程序试图获得对用户帐户的访问权限?最好知道这些事情,但还有其他更微妙的事情。

大多数成功的攻击都是从攻击应用程序并寻找其弱点开始的。攻击者对应用程序的调查越多,攻击者就越有可能找到并成功利用该应用程序中的弱点。攻击者继续攻击是因为他们的攻击被忽略了,而且平均违规检测周期为 191 天,日志通常是我们看到攻击正在发生的唯一方法。如果没有日志信息,就很难评估谁在何时访问了何种深度。

创建并遵循日志记录策略

我很少看到具有实际日志记录策略的应用程序。大多数时候,我们在问题发生后实施日志记录。我认为这也可以算作一种策略,但我们能做得更好吗?我想我们可以。

向应用程序添加日志记录时,最好采用整体一致的策略。尽可能在所有应用程序中使用相同的日志框架。这允许轻松共享配置,例如消息格式和一致的日志记录模式。对于何时需要记录警告/错误以及使用何种记录级别,需要有一致的指导方针。记录任何内容时,消息格式应至少包含时间戳、当前线程标识符、调用者 ID 和源代码信息。所有现代日志框架都支持此类信息。

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

记录完整的堆栈跟踪

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

OneAPM大讲堂 | Java 异常日志记录最佳实践 技术分享 第1张

这个例子有几个问题,我们只关注处理 SQLException 部分。假设,在查看生产中的日志时,我们会看到:

这并不能告诉你太多。是什么导致了 SQLGrammarException?记录器对包含抛出对象的所有异常进行分类并写入堆栈跟踪。通过稍微更改代码,我们可以更清楚地了解正在发生的事情:

OneAPM大讲堂 | Java 异常日志记录最佳实践 技术分享 第3张

使用这段代码,我们可以完整地记录堆栈跟踪,并清楚地记录下来。事实表明,一些邪恶的活动正在悄悄地进行。

OneAPM大讲堂 | Java 异常日志记录最佳实践 技术分享 第4张

现在,只需查看日志,我们就可以立即发现问题所在。有人试图使用 Acme' 来寻找客户并破坏了我们的 SQL 语句。这个异常清楚地显示了 SQL 注入,如果我们在分析日志时只看到原始消息,很容易被忽略。很可能是我们没有深入思考这个问题,转而研究其他问题,导致这个严重的缺陷没有被发现。

记录所有异常

“吞咽”异常是我看到的另一个非常常见的问题:在应用程序的某处抛出异常,开发人员打算用块捕获它,但由于某种原因,开发人员忘记了它或认为它不重要。下面的例子说明了这个问题:

OneAPM大讲堂 | Java 异常日志记录最佳实践 技术分享 第5张

根据我的经验,这种做法非常普遍,值得一提。记录异常、重新抛出异常或根本不处理异常,都不会在日志中显示应用程序的任何问题。我们没有理由不记录异常。 “吞下”此类异常可能会导致潜在问题被忽视,最终导致业务逻辑或安全漏洞问题。

不向用户返回异常

在执行任何类型的安全评估时,有关应用程序或其环境的每条信息都可能很有用。看似无害的错误信息可能正是顾问(或攻击者)所需要的。顾问可能会在您的系统中发现漏洞 - 攻击系统或显着减少负载,如果错误消息揭示了相关漏洞正在使用的数据库系统的信息,那么我们需要对该漏洞进行 SQL 注入测试。

通常的做法是简单地向用户返回异常消息并进行某种错误处理。在测试认证系统时,我遇到了很多问题,如下截图所示:

处理此问题的代码可能会这样做:

OneAPM大讲堂 | Java 异常日志记录最佳实践 技术分享 第7张

稍后,异常将被抛出并被捕获。开发者使用异常信息编写错误信息,传达给用户,让用户看到系统的原始异常信息。

OneAPM大讲堂 | Java 异常日志记录最佳实践 技术分享 第8张

这不仅在异常处理方面是不好的做法,而且还会打开用于用户帐户验证的应用程序。根据您正在处理的应用程序的类型,这可能具有固有的风险。

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

不要记录敏感信息

我提到日志记录不仅对调试有用记录日志的时候不要抛出异常,而且对合规性、审计和取证也有用。由于日志有如此多的用途记录日志的时候不要抛出异常,而且我们倾向于“记录一切”,它们可以成为一个惊人的信息来源。如果日志包含用户名、密码、会话令牌或其他敏感信息,它确实减少了攻击者的工作量。日志将揭示应用程序的内部工作和故障,攻击者可以利用这些信息进一步攻击应用程序。因此,我们需要谨慎对待日志并安全存储。不应记录以下信息:

但也不应记录以下类型的信息:

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

不要把自己置于黑暗中

虽然日志记录不是一项复杂的任务,但在正确使用它时有许多微妙之处和平衡点。信息太少没有价值,但如果处理不当,信息太多就会成为负担。

记录应用程序日志不是一个选择题,没有足够的日志你会一头雾水。

OneAPM Li智能日志分析平台可以实时采集数据中心基础设施和应用的海量日志,实时搜索,实时分析,洞察日志价值。如需阅读更多技术文章,请访问 OneAPM 官方技术博客。

上一篇:登录门户--Juku很棒学习模式-3.多种 下一篇:没有了