只要您不将任何您不信任的内容放入 HttpSession 中，您就不需要验证 HttpSession 中的数据。HttpSession 是为您的 web 应用程序创建的，当您要求它时，它应该只包含您在您的 servlet 或 JSP 之一中添加到它的东西 - 尽管如果您使用一些额外的框架可能是间接的。
我个人会确保我永远不会在 HttpSession 中放入任何稍后我将其取出时必须再次验证的内容。在一个简单的 servlet 容器环境中，它只会是您自己的代码来更新会话（除非容器自动删除它，如果它超时）。
除非您使用的框架会自动将内容添加到 HttpSession 中，并且这些内容可能直接来自用户而没有经过清理，否则您应该没问题。如果您自己的代码当前正在将您不信任的内容放入 HttpSession 中，我会将其更改为不这样做。
请注意，JSP 在这方面没有任何区别；JSP在编译后就是servlet。如果您信任您的 servlet 放入 HttpSession 中的内容，那么您应该也能够信任您的 JSP 对它所做的事情。（毕竟，它们是您的JSP。）
重新“是因为实现是未知的，并且不能保证会话的内容不是从 HTTP 请求中的数据（除了会话 ID）以某种方式构造的，因此会被篡改吗？”。servlet 规范中没有任何内容可以强制或允许这种情况发生。所以不，这不是原因。
重新“或者是因为信任会话的内容意味着隐式信任会话 ID，这可能会受到损害并指向错误的会话？” 我不确定“错误的会话”。但是，一旦某人（除了预期用户）拥有会话 ID（JSESSIONID），他们本质上就是预期用户，并且可以做任何用户可以做的事情（在相关 webapp 的能力范围内）。无论被破坏的数据是来自会话、数据库还是其他什么，都是如此。
一个常见的 servlet/MVC/JSP 方法是让用户登录（通过任何方式），然后为用户创建一个包含该用户的最小表示的 HttpSession（例如，一个包含用户 ID、名称等的 UserLogin POJO， ETC）。从那时起，webapp 相信此信息是有效的并使用它来识别用户 - 例如，带有 JSESSIONID 的 HTTP 请求到达，它映射到 HttpSession，后者映射到会话中的某些数据（UserLogin POJO），然后识别请求用户在从 webapp 内部调用底层系统时（例如进行数据库调用）。没有 HttpSession 和 UserLogin 会话数据则表明用户没有登录。这在 webapps 中很常见，并且取决于能够信任 JSESSIONID 和它映射到的 HttpSession。
顺便说一句（因为上面有人提到了 JSP）我不会编写一个 JSP 接触会话的 web 应用程序——我会限制 JSP 呈现由基于 MVC 的 servlet 提供给它们的数据。
（如果可以选择的话，我也根本不会使用 JSP：JSP 相当笨重，语法难看，还有许多其他限制 - 尝试使用 JSP 来模板电子邮件，而不是 HTML 页面，例如, 没有跳过一堆箍。考虑使用 Velocity 或类似的。）