统计jar使用的逻辑

作为我目前项目的一部分(定“在野外”调查审计线索的使用情况。

我没有详细地写过我的这个项目(不像)。主要是因为它是商业的，我不想用我的博客作为一个直接的推广渠道(虽然我正在这样做，讽刺的是)。但这篇文章的目的是为了说明审计跟踪是如何使用的。

调查题基本上是：您当前的项目是否具有审计跟踪功能，如果有，是否保护其免受篡改。如果没有-你认为你应该有这样的功能。

调查结果很有意思(尽管只有大约50个受访者)

 

因此，超过一半的系统(被调查者正在工作)没有审计跟踪。虽然审计跟踪是由信息安全和相关标准推荐的，但它可能在软件项目的“繁忙日程”中找不到位置，尽管提供一个琐碎的实现相当容易。

在许多情况下，一个简单的实现可能会做到，但如果审计日志是关键的(例如：执行财务操作等)，那么仅仅依靠一个微不足道的实现可能是不够的。换句话说，如果sysadmin可以访问数据库并删除或修改审计跟踪，那么它就没有多大用处。因此，下一个问题--如何保护审计跟踪不被篡改：

 

显然，从不到50%的审计跟踪项目中，大约50%的项目没有技术保证，无法篡改审计跟踪。我的猜测是更多，因为人们对什么技术措施是足够的有不同的理解。例如，有人可能认为对日志文件(或日志记录)进行数字签名就足够了，但实际上并非如此，因为没有办法检测到整个文件(或记录)可以被删除(或完全替

https://movie.douban.com/people/246110479/

最后的答案--你认为审计跟踪对你正在工作的系统很重要吗--得到了50%以上的“是的，非常重要的”和大约25%的“是的，可取的”。因此，总体理解是，它确实是必要的，但它正确实现所需的时间可能是将其置于待办事项的最底层的一个因素。

我写过他们的两种口味-事件来源和审计线索。事件日志可以有效地被视为审计跟踪，但是您需要额外的安全性来避免上面提到的问题。

那么，让我们看看审计日志的不同级别的安全性和有用性是什么样子的。关于这个题目有很多论文。，它们经常深入到如何实现日志记录的复杂细节中。我将试着概述一下这些方法：

https://www.imdb.com/list/ls501311252/

• 常规日志-依赖于生产日志中的常规信息日志语句来寻找发生了什么的提示。这可能是可以的，但很难找到证据(因为这些日志文件中也有不可审计的数据)，而且它不是很安全--通常会收集日志(例如：灰日志)而无论谁能够访问日志收集器的数据库(在Graylog的情况下是搜索引擎)，都可以操纵数据而不被捕获。
• 指定的审计跟踪--无论它存储在数据库中还是日志文件中。它具有适当的业务事件级粒度，但同样不能防止或检测篡改。风险较低的系统，这可能是完全没有问题的。
• 时间戳日志--无论是日志文件还是(更难实现的)数据库记录。时间戳是很好的，但如果不是外部服务，恶意行为者可以访问本地时间戳服务，并向被篡改的文件或插入假旧事件发出假时间戳。即使时间戳没有泄露，也可以删除整个条目。有时可以根据其他因素(例如轮调时间)推断出它们丢失的事实，但定期核实这是额外的努力，可能并不总是可行的。
• 哈希链--每个条目(或日志文件序列)都可以被链接(就像块链事务一样)--下一个条目具有上一项的哈希。这是一个很好的解决方案(无论是本地的、外部的还是第三方的)，但它有可能有人修改或删除记录，获取整个链并重新哈希它。所有的检查都会通过，但是数据是不正确的。
• 带有锚定的哈希链--链的头(最后一个条目/块的哈希)可以“锚定”到一个外部服务，该服务超出了恶意参与者的能力。理想的情况是，公共区块链，或者纸张、公共服务(Twitter)、电子邮件等等。这样，恶意行为者就不能仅仅重敲整个链，因为任何针对外部服务的检查都会失败。
• 蠕虫存储期策略。但是，必须支持自己的蠕虫存储是昂贵的。最终将日志发送到蠕虫存储是个好主意，但是“新的”审计跟踪不应该被“归档”，这样就可以搜索并从中获得一些可操作的洞察力。
• “以防万一”对每个项目来说都是不必要的，但这正是我在LogSentinel上决定要做的。业务-事件粒度与时间戳，哈希链，锚定，并最终放入蠕虫存储-我认为这提供了安全保障和灵活性。

https://www.douban.com/note/812043730/

我希望概览是有用的，调查结果也说明了这方面的信息安全是如何被低估的。

用户身份验证是每个Web应用程序共享的功能。我们应该在很久以前就完善这一点，因为它已经实施了这么多次。然而，有这么多的错误，一直在犯。

部分原因是，可能出错的事情清单很长。您可能会错误地存储密码，您可能具有易受攻击的密码重置功能，您可以将您的会话暴露于CSRF攻击，您的会话可能被劫持，等等。因此，我将尝试编译有关用户身份验证的最佳实践年都是你应该读的东西。但这可能还不够。

那么，我们开始吧。我将尽量简明扼要，但我将尽可能地包含尽可能多的相关缺陷--例如，用户会话在登录后可能出现什么问题：

• 用没有MD5或SHA，因为它们不适合存储密码。长盐(每个用户)是强制性的(上述算法都内置了它)。如果您不这样做，并且有人掌握了您的数据库，他们将能够提取您所有用户的密码。然后在其他网站上尝试这些密码。
• 使用HTTPS。期间。(否则，用户凭据可能通过不受保护的网络泄漏)。如果用户打开纯文本版本，则强制HTTPS。并确保您只使用最新的协议(TLS 1.2目前；TLS 1.1似乎没有漏洞，因此也可以支持)。你所支持的协议版本是否正常，请执行以下操作。
• 将饼干标记偷饼干更难。
• 使用csrf保护(例如，csrf与每个请求一起验证的一次性令牌)。框架具有这种内置的功能。
• 不允许框架否则，你的网站可能被包含在另一个网站隐藏的iframe和“滥用”通过javascript。
•  
• 注销-通过删除所有cookie并使会话无效，让用户