Nikto スキャンにカスタムヘッダーを追加する

Kali LinuxBeginner
オンラインで実践に進む

はじめに

Nikto は、人気のあるオープンソースのウェブサーバー スキャナーであり、6,700 を超える潜在的に危険なファイル/プログラム、1,250 を超えるサーバーの古いバージョン、および 270 を超えるサーバーのバージョン固有の問題を含む、複数の項目に対してウェブサーバーに対して包括的なテストを実行します。

ウェブアプリケーションによっては、リクエストに特定の HTTP ヘッダーが存在する必要がある場合があります。これは、認証(API キーやセッション トークンなど)、アプリケーションの特定のバージョンへのルーティング、またはデバッグ モードの有効化のためである可能性があります。標準の Nikto スキャンでは、必要なヘッダーが欠落しているため、これらのシナリオでは失敗するか、不完全になります。

この実験では、Nikto の -addheaders オプションを使用して、スキャンにカスタム ヘッダーを含める方法を学びます。これにより、特定のヘッダー要件を持つアプリケーションをテストし、より徹底的で正確なセキュリティ評価を確保できます。

アプリケーションで必要とされるカスタム HTTP ヘッダーの特定

このステップでは、カスタムヘッダーが必要となる理由を理解するために、シンプルなウェブアプリケーションと対話します。ポート 8000 で実行されているウェブサーバーがあり、アクセスには X-LabEx-Auth という特定のヘッダーが必要です。

まず、curl コマンドを使用して、カスタムヘッダーなしでウェブアプリケーションにアクセスしてみましょう。

curl http://127.0.0.1:8000

必要なヘッダーが欠落しているため、「Access Denied」というメッセージが表示されます。

Access Denied

次に、リクエストを再度送信しますが、今回は curl-H オプションを使用して、必要なカスタムヘッダーを含めます。ヘッダーは X-LabEx-Auth で、値は SecretToken です。

curl -H "X-LabEx-Auth: SecretToken" http://127.0.0.1:8000

今回は、サーバーがアクセスを許可し、ウェルカムメッセージを返します。これにより、アプリケーションがこの特定のヘッダーをチェックしていることが確認できます。

Welcome, authorized user! The server is Apache/2.4.1 (Unix).

このプロセスは、セキュリティスキャンを実行する前に、カスタムヘッダーの必要性を特定し、確認する方法を示しています。

-addheaders オプションを使用してヘッダーと値を指定する

このステップでは、Nikto のスキャンにカスタムヘッダーを追加するために使用されるオプションについて学びます。

カスタムヘッダーが必要であることがわかったので、Nikto にすべての HTTP リクエストにそれを含めるように指示する必要があります。Nikto はこの目的のために -addheaders オプションを提供します。

構文は非常に簡単です。

-addheaders "HeaderName:HeaderValue"

HeaderName をヘッダーの名前に(例:X-LabEx-Auth)、HeaderValue を対応する値に(例:SecretToken)置き換えます。

複数のカスタムヘッダーを追加する必要がある場合は、改行文字 (\n) で区切ることができます。たとえば、次のようになります。

-addheaders "Header1:Value1\nHeader2:Value2"

現在のシナリオでは、ターゲットアプリケーションをスキャンするための完全な Nikto コマンド構造は次のようになります。このステップではコマンドを実行していません。構文を理解するために構築しているだけです。

nikto -h http://127.0.0.1:8000 -addheaders "X-LabEx-Auth: SecretToken"

このコマンドは、http://127.0.0.1:8000 のホストをターゲットにし、スキャン中に送信されるすべてのリクエストに X-LabEx-Auth: SecretToken ヘッダーを追加するように Nikto に指示します。

カスタムヘッダーを含めてスキャンを実行する

このステップでは、先ほど学習した -addheaders オプションを使用して Nikto スキャンを実行します。

正しいコマンドが構築されたので、スキャンを実行する時間です。これにより、Nikto は認証されていないユーザーには見えない脆弱性を明らかにする可能性のある、正規のユーザーとしてアプリケーションと対話できるようになります。

ターミナルで次のコマンドを実行します。

nikto -h http://127.0.0.1:8000 -addheaders "X-LabEx-Auth: SecretToken"

Nikto はスキャンを開始します。すべてのリクエストに X-LabEx-Auth: SecretToken ヘッダーが含まれているため、ウェブアプリケーションはそれらを正常に処理します。Nikto の出力を観察してください。サーバーを特定し、さまざまな脆弱性のテストを開始します。

- Nikto v2.5.0
---------------------------------------------------------------------------
+ Target IP:          127.0.0.1
+ Target Hostname:    127.0.0.1
+ Target Port:        8000
+ Start Time:         ...
---------------------------------------------------------------------------
+ Server: Werkzeug/2.0.1 Python/3.10.6
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
+ No CGI directories found (use '-C all' to force check all possible dirs)
+ "Allowed HTTP Methods: HEAD, OPTIONS, GET"
+ OSVDB-3233: /: Found a default page.
...
+ 15 requests: 0 error(s) and 5 item(s) reported on remote host
+ End Time:           ...
---------------------------------------------------------------------------
+ 1 host(s) tested

重要な点は、スキャンが正常に実行されることです。一方、ヘッダーなしのスキャンはアプリケーションによってブロックされます。

プロキシツールを使用してヘッダーが送信されていることを確認する

このステップでは、Nikto が実際にカスタムヘッダーをリクエストと共に送信していることを確認します。通常、Burp Suite や OWASP ZAP のようなプロフェッショナルなツールが使用されますが、ここでは単純な netcat (nc) リスナーでプロキシをシミュレートできます。

まず、2 つ目のターミナルを開く必要があります。これは、ターミナルパネルのタブバーにある "+" アイコンをクリックすることで行えます。

新しいターミナルタブで、ポート(例:8888)で netcat リスナーを開始します。このリスナーは、受信したデータを単純に出力します。

nc -l -p 8888

次に、元のターミナルタブに戻ります。今回は、実際のウェブサーバーではなく、netcat リスナーにポイントして、再度 Nikto スキャンを実行します。これにより、Nikto は HTTP リクエストを netcat に送信し、それを検査できるようになります。

nikto -h http://127.0.0.1:8888 -addheaders "X-LabEx-Auth: SecretToken"

コマンドを実行した後、netcat が実行されている2 つ目のターミナルタブにすぐに切り替えます。Nikto によって送信された生の HTTP リクエストが表示されます。出力で X-LabEx-Auth: SecretToken ヘッダーを探してください。

GET / HTTP/1.1
Host: 127.0.0.1:8888
User-Agent: Mozilla/5.00 (Nikto/2.5.0) (Evasions:None) (Test:000001)
X-LabEx-Auth: SecretToken
Accept-Encoding: gzip,deflate
Connection: close

ご覧のとおり、カスタムヘッダーがリクエストに含まれています。これにより、-addheaders オプションが期待どおりに機能していることが確認できます。

これで、2 つ目のターミナルタブで Ctrl+C を押して netcat リスナーを停止し、タブを閉じることができます。

特定ヘッダーを必要とする脆弱性のテスト

このステップでは、ヘッダーありとなしのスキャンを比較することで、カスタムヘッダーを使用することの実際的なセキュリティ上の影響を理解します。

不安全な直接オブジェクト参照(IDOR)や権限昇格の脆弱性など、多くの脆弱性は、アプリケーションの認証済みセクションにのみ存在します。適切な認証ヘッダーを提供しないスキャンでは、これらの問題は完全に無視されます。

これを説明するために、まずカスタムヘッダー なし でウェブサーバーに対して Nikto スキャンを実行します。これは、認証されていない攻撃者によるスキャンをシミュレートします。

nikto -h http://127.0.0.1:8000

Nikto は実行されますが、送信されるすべてのリクエストは「アクセス拒否」という応答で返されます。スキャナーは、最初の承認チェックを通過できないため、アプリケーションを適切に分析できません。このようなスキャンの結果は限定的です。

- Nikto v2.5.0
---------------------------------------------------------------------------
+ Target IP:          127.0.0.1
+ Target Hostname:    127.0.0.1
+ Target Port:        8000
+ Start Time:         ...
---------------------------------------------------------------------------
+ Server: Werkzeug/2.0.1 Python/3.10.6
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
+ "Allowed HTTP Methods: GET, HEAD, OPTIONS"
+ OSVDB-3233: /: The site returned a 403 Forbidden, this may indicate that it's a default file.
...

これをステップ 3 で実行した(ヘッダーを使用した)成功したスキャンと比較することで、その違いを確認できます。カスタムヘッダーを使用したスキャンは、アプリケーションのコアロジック(curl で見た「Welcome」メッセージで示されたように)と対話でき、意味のあるテストを実行できました。ヘッダーを使用しないスキャンは、入り口で停止しました。

これは、脆弱性スキャンを可能な限り包括的にするために、カスタムヘッダーを使用することの重要性を強調しています。

まとめ

この実験では、Nikto を使用して効果的なウェブアプリケーションのセキュリティ評価を実行するための重要なテクニックを学びました。

以下のことを成功させました。

  • curl を使用して、アプリケーションがカスタム HTTP ヘッダーを必要としていることを特定しました。
  • Nikto の -addheaders オプションの構文を学びました。
  • カスタムヘッダーを含めた Nikto スキャンを実行し、正規のアクセス権を取得しました。
  • netcat リスナーを使用して、カスタムヘッダーが正しく送信されていることを確認しました。
  • カスタムヘッダーを使用したスキャンが、それ以外では見逃される脆弱性をどのように発見できるかを理解しました。

このスキルは、認証、状態管理、その他の機能のためにヘッダーに依存する、現代的で複雑なウェブアプリケーションのより徹底的なテストを可能にするため、あらゆるセキュリティ専門家にとって不可欠です。