9

新しいアプリケーションを開発しました。変更を移動する前に、checkmarx を使用してコードの静的スキャンを行いました。Cross Site History Manipulation という名前のコードには、中レベルの脆弱性があります。

これは、セッション値を検証している JSP ページで検出されます。

if(request.getSession().getAttribute("sesStrUID")!=null)

この脆弱性と、これを排除するために何をすべきかを理解するのを手伝ってもらえますか?

4

3 に答える 3

5

Checkmarxのチーフ ソフトウェア アーキテクトである Alex Roichman から得た回答は次のとおりです

。たとえば、多くのサイトでは、個人データを表示する前に、ユーザーが認証されているかどうかを確認しています。これは、次のコードで実行できます。

If (!IsAuthenticated())
          Redirect “login.jsp”

XSHM を使用すると、別のサイトから、ユーザーがそのサイトに対して現在認証されているかどうかを知ることができます。

次に、特定の行を探してみましょう。

if(request.getSession().getAttribute("sesStrUID")!=null)

この行は、ユーザーがセッションを持っているか、すでに認証されているかを確認しているようです。「if」ステートメント内に「リダイレクト」があるため、他のサイトがそれを認識しrequest.getSession().getAttribute("sesStrUID")!=nullたり、ユーザーがすでに認証されているかどうかを知ることができます。
したがって、この結果は真実であり、古いブラウザーや最新のブラウザーには何もありません。最新のブラウザーはすべて history.lengh へのアクセスを提供します。このプロパティは XSHM を介したプライバシー侵害につながる可能性があり、後方互換性の問題のために簡単な修正はありません。

X-Frame-Options: DENYは XSHM の IFrame バージョンから保護できますが、古いブラウザーはこのオプションをサポートしていません。

SilverlightFoxの回答後に編集

非常によく似た答えがあることに同意します。

それでも、懸念：

「最新のブラウザでは、3xx リダイレクトによって history.length の値が増加することはありません」

これは正しく、XSHM はまさにこれに基づいています。

次の攻撃シナリオを探します。

  1. IFrame で「Login.jsp」を開きます。履歴には、その上に「login.jsp」が含まれます。
  2. 「ShowSecretInfo.jsp」を開きます - サーバーが 3xx で「Login.jsp」にリダイレクトする場合、history.length は同じままです。サーバーが「ShowSecretInfo.jsp」を表示する場合、history.length は 1 増加します。

これは、攻撃されたユーザーが認証されたことを意味します – プライバシー違反.

于 2015-01-09T21:12:24.020 に答える
5

これは、2010 年以降の Internet Explorer の Web サイトの脆弱性というよりも、ブラウザの脆弱性です。

Checkmarx Research Labs は、ハッカーが Web アプリケーションを簡単に危険にさらす可能性がある Internet Explorer の新しい重大な脆弱性を特定しました (他のブラウザーもおそらく同じ方法で公開されます)。

これはブラウザーによる同一生成元ポリシーの違反であり、Web アプリケーションで修正する必要はありません。報告された脆弱性は、おそらくあなたが行っているリダイレクトを参照しています。

request.getSession().getAttribute("sesStrUID")!=null

調子。セッション値に基づいてサーバー側をリダイレクトしている場合、攻撃者は Web サイトを IFrame する可能性があり、リダイレクトしていることを検出すると、 nullsesStrUIDかどうかを推測できると言っています。sesStrUID

これは、ユーザーが壊れたブラウザーを使用している場合にのみ問題になります。ユーザーが最新のブラウザーを使用している場合、IMO を修正する価値はありません。安全性を高め、クリックジャッキング攻撃からも保護したい場合は、X-Frame-Options: DENYHTTP ヘッダーを出力してフレーミングを防ぐことができます。これは、IFrame バージョンの攻撃からのみ保護されることに注意してください。詳細に説明されているその他の攻撃ベクトルについては、この XSHM ペーパー を参照してください。

@adarの答えの後に編集：

Adar の回答は私のものと非常に似ており、ポスターがこれがまだ問題であると述べていることを除いて、ほとんど同じ情報を含んでいます。

locationただし、 HTTP ヘッダーを介してサーバー側をリダイレクトする場合、XSHM は問題になりません。HTTP 3xx最新のブラウザでは、リダイレクトによって の値history.lengthが増加することはないため、これを使用して、ユーザーが特定のサイトにログインしているかどうかを判断することはできません。

リダイレクト後に JavaScript コードを出力している場合

if(request.getSession().getAttribute("sesStrUID")!=null)

コードの場合、サーバー側をリダイレクトしている場合、XSHM が問題になります

<%
    String redirectURL = "http://example.com/myJSPFile.jsp";
    response.sendRedirect(redirectURL);
%>

そうすれば、あなたは無防備ではありません。

@adarの回答IIの後に編集：

@adar は正しいです: 次の攻撃シナリオを試した場合:

  1. Login.jspIFrame で開く- 履歴にはLogin.jsp.
  2. 開いている - サーバーが HTTP 3xx でShowSecretInfo.jspリダイレクトする場合、サーバーが示す場合は同じままです- 1 ずつ増加します。Login.jsphistory.lengthShowSecretInfo.jsphistory.length

したがって、history.length増加する場合は、ユーザーがログインしていると判断できます。Windows 7 で IE 11 と Firefox 33.1 を使用して上記を再現できました。

ユーザーがログインしていない場合、(クエリなしで)に/ShowSecretInfo.jspリダイレクトすると仮定します。/Login.jsp

  1. /ShowSecretInfo.jspIFrame で開く- 履歴には/ShowSecretInfo.jsp.
  2. IFrame src を/Login.jsp-に設定しhistory.lengthます。増加しない場合は、ユーザーがログインしていることがわかります。

srcがすでに現在の URL に設定されている場合、Chrome はリダイレクトを試行しないようです。これを IE と Firefox で再現することもできました。

于 2015-01-06T09:53:35.183 に答える
0

OWASPサイトより

Cross-Site History Manipulation (XSHM) は、SOP (Same Origin Policy) のセキュリティ違反です。SOP は、最新のブラウザーの最も重要なセキュリティ概念です。SOP は、設計上、異なるオリジンの Web ページが互いに通信できないことを意味します。クロスサイト履歴操作違反は、クライアント側のブラウザー履歴オブジェクトがサイトごとに適切に分割されていないという事実に基づいています。ブラウザーの履歴を操作すると、SOP が侵害され、双方向の CSRF や、ユーザーのプライバシー侵害、ログイン ステータスの検出、リソース マッピング、機密情報の推測、ユーザーのアクティビティの追跡、URL パラメーターの盗用などの悪用が可能になります。

ではrequest.getSession().getAttribute("sesStrUID")、ブラウザの履歴に行くことは何もしていないため、間違った検出のように見えます

于 2015-01-05T17:01:31.113 に答える