Webアプリケーションのペンテスト結果には、使用または参照さえされていない禁止ディレクトリのファイルが含まれています
最近のWebアプリケーションのペンテストで見つかった問題の1つは「バックアップファイル」でした。これは、filename.js1の更新バージョンがアップロードされたときにfilename.jsに名前が変更されたJavaScriptファイルでした。
「バックアップファイル」は、禁止されたリストのあるディレクトリにあり、アプリケーションのどこでも参照または使用されません。
どのようにしてこのファイルを見つけましたか？
ブルートフォーススキャナー
多くの自動化スキャナーは、ファイルを「ブルートフォース」で検索することにより、禁止されているディレクトリリストを回避します。これは、存在するファイルに類似した名前の追加のファイルをチェックすることを意味します（つまり、filename.js1およびまったく参照されないファイル（別名secret.txt）。名前がブルートフォースリストにあり、アクセス可能なディレクトリにあるファイルがある場合、「ディレクトリリスト」が有効かどうかに関係なく、そのファイルが見つかります。
ハッカーがこれと同じことをすることを指摘する価値があるので、これは本当の問題です。一般に、パブリックにアクセス可能なディレクトリに何かがある場合、それが見つかると想定する必要があります。したがって、それをパブリックにしたくない場合は、パブリックディレクトリから除外する必要があります。ディレクトリのリストを無効にしても、セキュリティはほとんど得られません。
実際の脆弱性
最後に、これは大きな問題のようには見えないかもしれません（そして、おそらくそうではないかもしれません）が、javascriptファイルのバックアップをパブリックディレクトリに残すことは、実際には一般的に悪い考えです。 XSSに関しては、攻撃者が同じドメインでホストされているjavascriptファイルを悪用できる場合、攻撃者は一般的に最も成功します。これは、そうすることでCSPまたは他のセキュリティ「ファイアウォール」をバイパスする機会が与えられるためです。その結果、古いJavaScriptファイルにセキュリティ上の脆弱性があり、それが新しいバージョンで修正され、攻撃者がユーザーのブラウザに古いJavaScriptファイルを強制的にロードさせる方法を見つけた場合、攻撃者はその方法をより有害な脆弱性。これは遠くにあるように思われるかもしれませんが、多くの小さな脆弱性を1つの大きな脆弱性につなげることで、最悪の違反がいくつ発生するかがわかります。
tl/dr：ウェブサイトでホストされているものの、そこに存在する理由がない場合は、責任があります。偏見でそれを殺します。
ファイル名をブルートフォースにする多くのツールが利用可能です。これらのいくつかは他のものよりインテリジェントです。
たとえば、「ダム」ツールには、次のようなファイルとディレクトリの名前が含まれている可能性のある単語リストのみがある場合があります。
/admin/wp-admin.phplogin.php
よりインテリジェントなツールは、（たとえば、アプリケーションをクロールすることによって）すでに知っているファイルを見て、同じような名前のファイルを見つけようとする場合があります。あなたの場合、filename.jsという名前のファイルがあったため、TripeHoundがコメントで指摘したように、アプリケーションが名前を壊そうとしました：
filename.js1filename.js.bakfilename.bak.js.filename.js
これらのファイルに問題があるのはなぜですか？
参照されていないファイルはアプリケーションの一部ではないため、「安全」であると考えたくなるかもしれません。ただし、ファイルは引き続きアクセス可能であり、ファイルの内容によっては、攻撃者がさまざまなことを行う可能性があります。
- 攻撃者はURLフィルターを回避し、古いバージョンの脆弱性をまだ含んでいるJavaScriptファイルを含めることができる可能性があります。
- 参照されていないファイルは、展開から残されたアーカイブであり、まだソースコードが含まれている可能性があるため、攻撃者はそのファイルにアクセスできます。
- 参照されていないファイルには、資格情報またはその他の関連する構成データが含まれている可能性があります
一般に、参照されていないファイルがウェブルートに存在しないようにすることをお勧めします。名前が示すように、これらはアプリケーションでは使用されないため、問題の原因にすぎません。
ここでの本当の問題は、自動化されたソース管理および展開システムによって制御されない（したがって複製可能である）展開/実稼働環境があることです。
つまり、システムで新しいファイルを見つけた場合、それがルートキットによってドロップされたある種のバックドアなのか、同僚が残した無害な名前変更されたファイルなのかがわかりません。
一般的に、セキュリティ上の最善策は、サーバー上にある種のビルドアーティファクトのクローンを作成する自動化スクリプトによってそこに配置されるファイルのみを保持し、その自動化プロセスで、存在しないはずのファイルも削除することです。次に、「本番環境のファイルは、ビルドシステムがそうあるべきだと言うものですか？」の監査を実行できます。
また、「悪い展開方法は私のビジネスにとって生命にかかわる問題ではない可能性がある」と思われる場合は、グーグルの「ナイトキャピタルグループ」に招待してください。
攻撃者が行うのと同じように、推測によって。
だからこそ、ペンテスターがいます。あなたが考えていなかったものをテストするためです。
アプリケーションからバックアップファイルを削除して、アクセスできないようにします。
どのようにしてこのファイルを見つけましたか？
他の人がすでに述べたように、非常に単純な「力ずくの」推測。
Webサーバーのログで、これが発生したときにこれを確認できます。このファイルの要求と、行われた他の推測を確認できます。もちろん、テスターがログをリセットできるホールドを見つけることができなかった場合（テストレポートにリストされます）や、十分なログが有効になっていない場合を除きます。
しかし、予測が困難なリネーマーであることも、おそらく悪い考えではありません
古いファイルがアプリケーションディレクトリに存在しないようにすることをお勧めしますすべて。特に展開モデルが「ソースからのコピー」である場合は、ソースディレクトリでも。
参照またはその他の理由で古いバージョンのファイルを保持する代わりに、バージョン管理の仕組みによって提供される機能を利用してください。すべてのVCSで古いバージョンのファイルを取得できます。一部のVCSでは、適切にチェックインせずに中間バージョンを棚上げできます。ブランチを使用して実験作業を分離することもできます。