web-dev-qa-db-ja.com

Webアプリがディレクトリトラバーサル攻撃に対して脆弱である理由を理解できません

私はこのWebアプリで作業していたときに、誰かがそれをペンでテストし、私のアプリがディレクトリトラバーサル攻撃に対して脆弱であるという大量のレポートを送信しました。

これが1つのサンプルです。

_Testing Path: http://127.0.0.1:80/??/etc/issue <- VULNERABLE!
_

ブラウザに_http://127.0.0.1:80/??/etc/issue_を入れましたが、ホームページが表示されましたが、_/etc/issue_ファイルはまったく返されませんでした。

それから私はcurlを試してみましたが、それもホームページを返しました。

_/etc/issue_ファイルが返されない場合、誰かが私のアプリがどのように脆弱であるかを誰かに説明してもらえますか？.

アプリはPython 2.7でコード化されています。flaskがフレームワークで、Nginxがリバースプロキシです。

レポートからのさらに2つのサンプルと、対応する応答：-

  1. _Testing Path: http://127.0.0.1:80/??/etc/passwd <- VULNERABLE!_

    GETリクエスト-app: 0|req: 1587/1587] 127.0.0.1 () {34 vars in 488 bytes} [Tue Sep 6 15:47:13 2016] GET /??/etc/passwd => generated 982 bytes in 4 msecs (HTTP/1.1 200) 2 headers in 80 bytes1

  2. _Testing Path: http://127.0.0.1:80/??/??/etc/passwd <- VULNERABLE!_

    GETリクエスト-app: 0|req: 1591/1591] 127.0.0.1 () {34 vars in 493 bytes} [Tue Sep 6 15:47:14 2016] GET /??/??/etc/passwd => generated 982 bytes in 5 msecs (HTTP/1.1 200) 2 headers in 80 bytes

web-applicationpythondirectory-traversal
39
Batman

最近、同様の脆弱性に関するレポートを送信し、同様の応答を得ました。

ほとんどのブラウザとCLI httpクライアントはURLからパストラバーサルコンポーネントを削除します。

たとえば、FirefoxでURL http://example.com/../../../etc/passwd example.comに届くGETリクエストは次のようになります。

GET /etc/passwd HTTP/1.1
[Ommitted headers]

Wgetについても同様です。

Telnetやnetcatなどの低レベルのツールを試してください。

$ telnet example.com 80
GET /../../../etc/issue HTTP/1.1

HTTP/1.1 400 Bad Request
Content-Type: text/html
Content-Length: 349
Connection: close
Date: Wed, 07 Sep 2016 12:38:13 GMT
Server: ECSF (fll/078B)

繰り返しになりますが、それは誤検知であった可能性があります。監査人は/etc/issueレポートで。これはpasswdではなく、issueを使用するポイントのようなものです。

少なくとも監査人にフォローアップして、それが誤検知であるかどうかを確認する必要があります。それが不可能な場合は、新しいペンテストを準備するか、 dotdotpwn のようなパストラバーサルファザーを使用して独自に実行します。

絶対にあなたが安全だと仮定しない、あなたが安全であることを保証する特にそのような報告の後。

45
GnP

まず、誰もそれをペンテストしませんでした。彼らはスキャナーを走らせて結果を手渡しました。

ペンテスターは脆弱性を確認し、それを再作成する方法を説明したでしょう。

スキャナーが、これらのペイロードへの応答としてホームページを取得したという事実を肯定的な結果として誤って報告した可能性があります。

また、ジェシーのように、ディレクトリトラバーサルペイロードの一部として??を聞いたことがないため、二重の疑問符が実際のペイロードを隠していると思います。表示されているすべての場所で..を置き換えてみてください??

スキャナーは、従わないブラウザバージョンを使用している https://tools.ietf.org/html/rfc3986#section-5.2 これは、URL内のドットを削除/解決するための仕様です。

スキャナーが1つのペイロードのみを脆弱であるとフラグを立てたが、他の何十も脆弱ではなかった場合、私はもっと心配しますが、さまざまなペイロードで何十もの結果が得られたようですね？ @Gnpが言ったように、スキャナーに証拠を求めます（その??ペイロードについて尋ねます）。

30
mcgyver5

これはおそらく誤検知でした。

質問で以下の更新情報を確認した後

GETリクエスト-

app: 0|req: 1591/1591] 127.0.0.1 () {34 vars in 493 bytes} [Tue Sep  6 15:47:14 2016] GET /??/??/etc/passwd => generated 982 bytes in 5 msecs (HTTP/1.1 200) 2 headers in 80 bytes

それはいくつかの自動化されたスキャナーによって生成されたそのかなり明確です。

次に、スキャナーが脆弱性をどのように決定したかという質問が来ますか？

あなたが言ったように、

それから私はカールを試してみましたが、それもホームページに戻りました。

自動スキャナーは、サーバーの応答としてHTTP/1.1 200（OK）を取得したため、サーバー上でそのファイル/etc/passwdを読み取ることができたと想定しました。 Silly Automated Scanner。

自動化スキャナーは、そのページが脆弱でないことをHTTP/1.1 404（見つかりません）またはHTTP/1.1 302（URLリダイレクト）のようなものを期待しています。

2
Sravan