web-dev-qa-db-ja.com

フィッシングによる悪用からサイトを守る

Webサイトがあり、returnUrl URLパラメーターを使用して、ログイン後またはユーザー領域のレコードを編集した後のページにユーザーをリダイレクトするとします。 returnUrlがWebアプリケーションと同じサーバーにあるかどうかを確認する標準的な方法はありますか？

これまでのところ、攻撃者がユーザーを別の場所にリダイレクトする方法は2つあり、これらの攻撃を防ぐために次のアクションを実行できることがわかりました。

  1. 攻撃者はパラメータにURL全体を提供します（http://evil.com/）-ここでは、パラメータにhttp(s)://またはftp://が含まれているかどうかを確認できます。
  2. プロトコルが欠落している場合、ブラウザは自動的にプロトコルを追加するため、攻撃者は//evil.comや//numeric_ip_addressなどを提供でき、サーバーの外部にもユーザーをリダイレクトします。ここでも、URLが//で始まるかどうかを確認できます。

URLアドレスをエンコードする他の方法はありますか？前の2つのケースのみをチェックした場合、パラメーターが誤用されないことを確認できますか？

appsecweb-applicationpenetration-testurl-redirection
10
bretik

これにアプローチする1つの方法は、サーバーに保存されているキーを使用してユーザーに渡されるパラメーターを暗号化することです（保護を強化するために、 [〜＃〜] hmac [〜＃〜] を追加することを検討してください。 =）。次に、ユーザーがフォームを送信したら、パラメーターを復号化し（使用されている場合は、HMACを確認し）、それを使用してユーザーをリダイレクトします。

URLが難読化されている場合（base64エンコーディングなど）を見てきました。それは偶然の攻撃者を思いとどまらせるかもしれませんが、断固とした攻撃者が使用されたスキームを解決する可能性が高いので、私はそれに依存しません。

6
Rory McCune

WebサイトのプレフィックスをURLに追加して、次の場所に移動することができます。

example.com/login.php?returnurl=profiles/home.php

そして、ページで http://example.com/ に戻り、戻りURLを追加します。 （http://example.com/RETURNURLHERE）

4
James T

ユーザー/ブラウザを攻撃したり、URL /リダイレクトを難読化したりするには、多くの方法があります。クレイジーな方法はあなたの脳を傷つけ、なぜそれがうまくいくのかとあなたに尋ねさせます！ （参照： http://code.google.com/p/browsersec/ ）一般に、入力を検証するときは、データを修正しようとしないでください。必要なフォーマットを捨ててください。デフォルトの拒否を覚えておいてください。これはその別の例です。

他の場合と同様に、これをどのように実装するかは、要件によって異なります。また、HTTP応答の分割、ヘッダーインジェクションなど、さらに脆弱性を引き起こす可能性のあるリダイレクトを処理する場合は、実装の欠陥に注意する必要があります。

私は通常、宛先ホワイトリストとリクエスト署名（HMACを使用）の組み合わせをお勧めします、ロリーの提案に似ています）。リクエストの署名を行うときは、宛先をURIに表示するのが好きです。例えば：

http://yoursite.com/login.php?returnurl=welcome.php&hash=yourlonghashhere

これにより、ユーザーはリクエストの送信先を少し実行できるようになります。また、より知識のあるユーザーがフィッシングやその他の攻撃に自分で気付く可能性もあります。

リダイレクトが発生しようとしているとき：

  1. ハッシュに対して「returnurl」を確認します
  2. 'returnurl'がホワイトリストに登録されていることを確認します
  3. 次に、リダイレクトを実行します。

検証プロセスのいずれかのステップが失敗した場合は、デフォルト/ホームページにリダイレクトするか、リクエストを拒否します。

その他のリソースは次のとおりです。

2
Gerry
  1. URLから不要な情報をすべて削除します（例：http://、サイトの名前など）。複数のオプション（5つのサイトなど）がある場合は、それらのインデックスを使用します。
  2. サーバー側のシークレットソルトを使用して残っているもののハッシュを計算し、それをreturnUrlの前に追加します（またはその一部-短いほど、衝突攻撃が成功する危険性が高くなります）。
  3. returnUrlを受け取ったら、ハッシュが有効であることを確認します。そうでない場合は、拒否します。
  4. 不足しているすべての情報を追加し直して、リダイレクトします。

また、一部のリダイレクトは、一部のパラメーターをプラグインするだけでよい一般的なパターンに従う場合があります。この場合、ハッシュさえ必要ない場合があります。

例：代わりに

returnUrl=http://www.myfifthsite.com/common/webpage/profile?user=lserni

あなたは沸騰することができます

returnUrl=5-5-lserni

5番目のサイト、5番目に許可されたリダイレクトパターンを意味します。このパターンにはパラメーターが1つだけあり、その値はユーザー名です。

サイト：... 5 => ' http://www.myfifthsite.com '.。

サイト＃5のパターン（もちろん、認証はnotオーバーライドされます！）：5 => '/ common/webpage/profile？user = $ 1'6 = > '/ common/webpage/messages？user = $ 1'

攻撃者は許可されたすべてのサイト番号とパターン番号を列挙できますが、許可されたサイトの有効なURLのみを取得します。

したがって、ある意味では、この方法では何もチェックする必要はありません。 URLは常に自動的に有効になります（認証Cookieが必要な場合もあります）。

0
LSerni