0

セッションの肥大化を最小限に抑えるために、主にViewScoped Beanを使用しているwebprojektに取り組んでいます。しかし、その後、Bean 間で (データベースなどにアクセスするために) クライアントのユーザー名とパスワードを転送する必要があるという問題に直面します。

次のように、フラッシュ オブジェクトを使用して Bean 間でユーザー名とパスワードを転送するシステムを作成しました。

public String gotoNextView() {
    ExternalContext external = FacesContext.getCurrentInstance().getExternalContext();
    external.getFlash().put("user_name", (String) FacesContext.getCurrentInstance().getExternalContext().getFlash().get("user_name"));
    external.getFlash().put("password", (String) FacesContext.getCurrentInstance().getExternalContext().getFlash().get("password"));

    return "/../../next_view.xhtml";
}

しかし、ハッカーが何らかの方法でクライアントを操作し、それによってサーバーをだましてフラッシュ オブジェクトを公開することができるのではないかと心配しています。

私が考えている別の解決策は、Web アプリケーションのすべての JSESSIONID を、ユーザー名とパスワードを値としてマップにキーとして格納することです。これを機能させるには、ユーザー セッションが終了または期限切れになったときにコールバック メソッドを呼び出して、関連する JSESSIONID をマップから削除できるようにする必要があると思います。しかし、その解決策の問題は、コールバックを実装する最善の方法が何であるかについて疑問があることです。これにより、サーバーによって新しい同様の JSESSIONID が作成される前に Map エントリが削除されることを 100% 確信できます (たとえ私がこのような短い時間で発生する可能性は非常に低いことを知っておいてください)。

この問題について深い洞察を持っている人が、ベスト プラクティスとこれに対する 100% 安全な方法について書いてくれることを願っています (また、JSF Web アプリケーション サーバーで作業しているほとんどの人がこの問題に遭遇していると思います。問題の最善の解決策を知っている)。ありがとう。

4

1 に答える 1

1

私はあなたがここで誤解していると思います。変数が 1 つのマネージド Bean に存在し、別のマネージド Bean に「渡される」という事実は、物理メディア全体で実際に移動することを意味しません。すべてのビュースコープ Bean は同じストレージ領域に実装されます (UIViewRootオブジェクトだと思います)。このレベルでは、これらのエンティティ間に暗黙的な信頼の境界があり、2 つの Bean 間でユーザーがアクセスできる移動 (おそらくクライアント側の変数、URL パラメーター、またはその他の HTTP アーティファクト) がない限り、リスクは見られません。

これが意味することは、変数が置かれている特定@ViewScopedの Bean に関係なく、それらはすべて同じ脆​​弱性 (存在する場合) にさらされているということです。Bean 間で変数を「受け渡し」しても、新しいリスクは発生しません。ユーザーに対して値をどこにでも (おそらく URL または非表示の HTML フォーム要素で) 表示しない限り、オブジェクト自体によって新たなリスクが生じることはありません@ViewScoped(スコープの不適切な使用は別の問題です)。

最終的に、まだ心配している場合は、変数を別のエンティティに渡す前に、自分のものを暗号化してください (オーバーヘッドを考慮してください)。

于 2014-09-04T18:31:57.900 に答える