web-dev-qa-db-ja.com

このパストラバーサルのセキュリティ問題の使用

Zapを使用して自分のWebサイトの1つをスキャンしたところ、パストラバーサルの問題が見つかりました。

これらは情報です:

Attack: c:/

URL: www.example.com/example.php

Parameter: mail

私はブラウザとCMDでcurlをいじくり回して、ルートにアクセスしようとしましたが、何も動作しません。誤検知の可能性はありますか?

私は今、たくさんのテストを行いましたが、これらがいくつかの結果をもたらすべきではありません:

www.example.com/example.php?mail=../../
www.example.com/example.php?mail=..%u2216..%u2216
www.example.com/example.php?mail=..%c0%af..%c0%af (I tried even more encodings)
www.example.com/example.php?mail=c:/

次にcURLの例を示します。

curl --path-as-is -X POST --data "mail=..%c0%af..%c0%af" https://www.example.com/example.php

ZAPがどの要求が行われたかを表示する場所を見つけました。

mail=c%3A%2F

しかし、応答は正しいように見えます。そのHTMLサイト。

編集:

このcURLを実行すると、空の応答が返されますが、何もありません。

curl --path-as-is -X POST --data "mail=c%3A%2F" --url
"https://www.example.com/example.php"

編集:

ブラウザーを介して同じ要求を行い、応答を確認すると、次のようになります。

Failed to load response data

編集:

うわー...それは偽陽性でした。だからここに何が起こったかです。次のようなインラインhtmlコメントがありました。

<!-- enemies, boulders, etc. -->

Zapが単語etcをマーク(灰色)していることに気づきました。それは通常、重要なファイルシステムパスの一部だからです。

これをパストラバーサルに接続する方法を知る手掛かりはありませんが、コメントを削除した後、この問題は警告されなくなりました。

2
Roman

それは偽陽性でした。だからここに何が起こったかです。次のようなインラインHTMLコメントがありました。

<!-- enemies, boulders, etc. -->

Zapが単語etcをマーク(灰色)していることに気づきました。それは通常、UNIXベースのシステムでは重要なファイルシステムパスの一部だからです。

Word etcを削除した後、レポートにパストラバーサルの問題はなくなりました。

2
Roman