web-dev-qa-db-ja.com

ブラウザのこのオープンリダイレクトの脆弱性をどのように利用しますか？

私は問題があります。げっぷによるオープンリダイレクトの脆弱性を発見しました。サーバーによるリクエストは次のようになります。

GET /user/settings/ HTTP/1.1
Host: domain.com
User-Agent: etc

だから私はここにオープンリダイレクトを見つけることにしました、まず私はこれを試します：

GET /http://google.com HTTP/1.1
Host: domain.com
User-Agent: etc

残念ながら404エラー。だから私は http://google.com とビンゴの前にスラッシュをカットします：

GET http://google.com HTTP/1.1
Host: domain.com
User-Agent: etc 

Response:
HTTP/1.1 302 found

You are redirected to http://google.com

しかし、このバグは役に立たないので、ブラウザでこの脆弱性を悪用したいと思います。

次のようにスラッシュ「\」（404エラー）を使用できません：domain.com/ http://google.com

スラッシュ（domain.comhttp：//google.com）がないとアドレスを入力できません。アドレスが機能しないためです。

誰かがこれをブラウザで悪用するアイデアを持っていますか？

web-applicationweb-browserexploiturl-redirection
1
ititit

ブラウザからこの脆弱性を悪用することはできません。非プロキシー要求の場合、ブラウザーは常に絶対パスを要求に入れます。これは、スラッシュで始まることを意味します。

サイトに送信したリクエストは、実際にはHTTPプロキシリクエストです（理論的には、有効なHTTP/1.1非プロキシリクエストでもありますが、ブラウザはこのように送信しません）。ブラウザーでサイトがHTTPプロキシとして構成されている場合にのみ、ブラウザーはそのような要求をサイトに送信します。ただし、脆弱性のあるサイトdomain.comをプロキシとして使用するようにユーザーのブラウザーを何らかの方法で再構成できたとしても、ユーザーは実際のリンクhttp://google.comをクリックする必要があるため、オープンリダイレクトは機能しません。再びhttp://google.comにリダイレクトされ、ユーザーはプロキシを使い続けるので、最終的には無限のリダイレクトになります。

1
Steffen Ullrich

これは厳密には脆弱性ではなく、FacebookのHTMLを変更することも悪用であり、このコンテキストでの自己悪用です。これは、Webサイトにユーザーがいて、悪意のあるサイトにリダイレクトするために必要なスクリプトがある場合にのみ機能します。

さらに、被害者のコンピューターにプラグインをインストールできれば、フィッシングにこの「トリック」を使用でき、必要なスキルを備えたリクエストにjsonスクリプトを挿入できます。

1
THE YOGOVO