HttpSession に信頼できないものを何も入れない限り、HttpSession のデータを検証する必要はありません。HttpSession は、要求時に webapp 用に作成され、サーブレットまたは JSP のいずれかに追加したもののみを含める必要がありますが、追加のフレームワークを使用している場合は間接的である可能性があります。
個人的には、取り出したときに後で再度検証する必要があるものを HttpSession に入れないようにします。単純なサーブレット コンテナー環境では、セッションを更新するのは独自のコードだけになります (タイムアウトした場合にコンテナーがセッションを自動的に削除する場合を除く)。
自動的に HttpSession に何かを追加するフレームワークを使用しており、それらがサニタイズされずにユーザーから直接提供された可能性がある場合を除き、問題はありません。あなた自身のコードが現在、信頼できないものを HttpSession に入れている場合は、それを行わないように変更します。
この点に関して、JSP は違いがないことに注意してください。JSPは、コンパイルされるとサーブレットになります。サーブレットが HttpSession に入れるものを信頼するなら、JSP がそれを使って行うことも信頼できるはずです。(結局のところ、それらはあなたのJSP です。)
Re 「実装が不明であり、セッションの内容が (セッション ID を除いて) HTTP 要求内のデータから何らかの方法で構築されていないため、改ざんの対象となることを保証できないためですか?」. サーブレット仕様には、これを強制または許可するものは何もありません。いいえ、これは理由ではありません。
「それとも、セッションの内容を信頼するということは、セッション ID を暗黙的に信頼することを意味するためでしょうか。これは侵害され、間違ったセッションを指している可能性があります。」「間違ったセッション」についてはわかりません。ただし、(意図したユーザー以外の) 誰かがセッション ID (JSESSIONID) を取得すると、そのユーザーは本質的に意図したユーザーになり、ユーザーが実行できることはすべて (問題の Web アプリケーションの機能内で) 実行できます。これは、侵害されたデータがセッション、データベースなどから来ているかどうかに関係なく当てはまります。
一般的なサーブレット/MVC/JSP アプローチは、ユーザーを (何らかの手段で) ログインし、その時点で、そのユーザーの最小限の表現を含む HttpSession をユーザーに作成することです (たとえば、ユーザー ID、名前などを含む UserLogin POJO、等）。それ以降、webapp はこの情報が有効であることを信頼し、それを使用してユーザーを識別します。たとえば、HTTP 要求が JSESSIONID とともに到着し、HttpSession にマップされ、セッション内のデータ (UserLogin POJO) にマップされ、要求元を識別します。 webapp 内から基礎となるシステムへの呼び出し (データベース呼び出しなど) を行うときのユーザー。HttpSession および UserLogin セッション データがない場合、ユーザーがログインしていないことを示します。これは Web アプリケーションでは非常に一般的であり、JSESSIONID とそれがマップする HttpSession を信頼できるかどうかに依存します。
ところで (誰かが上記の JSP について言及したので) 私は JSP がセッションに触れる webapp を書きません - MVC ベースのサーブレットによって提供されたデータをレンダリングするように JSP を制限します。
(選択肢があれば、JSP をまったく使用しません。JSP はかなり扱いにくく、構文が見苦しく、他にも多くの制限があります。たとえば、JSP を使用して、HTML ページではなく電子メールのテンプレートを作成してみてください。 、たくさんのフープを飛び越えることなく。Velocity などの使用を検討してください。)