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
をマーク(灰色)していることに気づきました。それは通常、重要なファイルシステムパスの一部だからです。
これをパストラバーサルに接続する方法を知る手掛かりはありませんが、コメントを削除した後、この問題は警告されなくなりました。
それは偽陽性でした。だからここに何が起こったかです。次のようなインラインHTMLコメントがありました。
<!-- enemies, boulders, etc. -->
Zapが単語etc
をマーク(灰色)していることに気づきました。それは通常、UNIXベースのシステムでは重要なファイルシステムパスの一部だからです。
Word etc
を削除した後、レポートにパストラバーサルの問題はなくなりました。