java - 必须管理安全编码合规性评估 session 状态

Question

一项新的安全编码公司政策最近生效。初步审计评估标记我存在以下缺陷:

Session state must be managed such that a session will withstand replay-attacks.

我不太清楚这句话的意思或者为什么我在这方面有缺陷。我正在开发一个 Java Web 应用程序并设置一个 session ，如下所示:
session.setMaxInactiveInterval(36000);

Answer 1

Session state must be managed such that a session will withstand replay-attacks.

这个说法太困惑了。重新措辞会产生:

The session management framework must protect the application against replay of session IDs.

它不那么令人困惑(希望)，并且继续具有与前者相同的含义(再次，希望)。

通常，如果要实现一个自行开发的 session 管理框架，而不是依赖于容器提供的框架，那么应用程序的 session 管理功能很可能容易受到重放攻击.

session 重放攻击涉及在 session 过期后在请求中重放 session ID 的情况。编写良好的 session 管理框架会识别出提供的 session ID 不是有效的 session ID。然而，在某些情况下，易受攻击的 session 管理框架接受了现已过期的 session ID，并重新创建了 session 内容。在更糟糕的情况下， session 管理框架在 session 到期时根本不会销毁 session ，从而导致 session ID 重放导致请求被处理的情况。

必须记住，即使应用程序的普通用户如果能够在不登录的情况下浏览到应用程序中 protected 页面，也可能会无意中执行 session 重放攻击。这表明身份验证和 session 失败。应用程序的 session 管理功能，因为应用程序理想情况下应允许用户仅在成功身份验证后才能浏览 protected 页面，这将生成一个 token ( session ID)，可在一定时间内使用该 token 来访问站点，而无需进一步身份验证。如果您使用持久 cookie 进行身份验证，则可能无意中引入了漏洞。

根据上述内容，可以通过以下方式保护任何应用程序免受 session 重放攻击:

• 确保您正在使用容器提供的 session 管理功能。从 session.setMaxInactiveInterval 的使用来看，我假设你就是这样。但是，可以肯定的是，请验证您是否使用其他方式创建 session ID，或者就此而言，请验证您是否使用与 session ID 等效的标识符。简而言之，确保您的应用程序仅依赖 JSESSIONID cookie 的值(或容器中配置的等效值)来将 session ID 传递给浏览器。另外，验证是否正在使用持久 cookie(请参阅上面发布的场景)。
• 在一定的空闲时间后使 session 失效。如果不使 session 失效，那么攻击者就有更长的时间窗口来暴力破解 session ID。从 session 重放攻击的角度来看，情况更糟，因为攻击者可以在任何时间点重放受损的 session ID，但仍然可以访问有效的用户 session 。您还需要重新访问 session.setMaxInactiveInterval 中指定的持续时间，当前使用的值为 10 小时。我认为这是没有安全感的。大多数应用程序不需要超过 30 分钟的 session 到期滚动窗口，对于高值(value)应用程序建议使用 10 分钟。
• 在到期时销毁服务器端 session 及其内容。在 Servlet 容器中，这通常是通过在注销页面/链接中调用 session.invalidate() 来完成的。确保您首先向用户提供了从应用程序注销的链接，以便可以使用前面提到的 API 调用来处理注销请求以使 session 无效。如果您不执行此 Activity ，服务器端 session 对象将仅在 session 到期时被销毁(这将在用户不活动 10 小时后发生；现在您知道为什么 10 小时是一个坏主意了)。