当社のAIエンジンNeutronが、UCバークレーのCyberGymベンチマークで96.75%のスコアを記録しました。 詳細を見る

セキュリティ

セキュリティ

403 Forbiddenを回避する方法：ヘッダー、メソッド、パス

ホストヘッダーやプロキシヘッダー、HTTPメソッド、パラメーター、URLパスの変更、あるいはWayback Machineで古いファイルを確認することによって、403 Forbiddenレスポンスを回避します。

Othmane Hachim Nour Eddine Masdoufi Youssef Badaoui Saad Mazouzi. 更新

はじめに

もし403エラーの回避によって隠れた脆弱性を明らかにできるとしたらどうでしょうか。本記事では、これらのエラーを回避し、潜在的なセキュリティ上の欠陥を浮かび上がらせるための高度な手法を解説します。サーバーの設定ミスを明らかにし得るリクエストヘッダーのファジング、さまざまなリクエストの種類を試すためのHTTPメソッドの変更、制限を回避するためのリクエストパラメーターの操作、以前はアクセスできたファイルを見つけるためのWayback Machineの活用など、多くの手法を掘り下げます。これらの手法は、ペネトレーションテストやセキュリティ評価にとって重要な知見をもたらします。

403エラーを回避するために実装された手法

この目的を達成するために、多くの手法を利用できます。設定ミスを調べるためのホストヘッダーの変更、別のアクセス経路を見つけるためのさまざまなユーザーエージェントのリクエストの作成、脆弱性を見つけるためのリクエストパラメーターの調整、アクセス制御を回避するためのファジングされたリクエストパスの生成、そして以前はアクセスできたコンテンツを発見するためのWayback Machineの活用などです。これらの手法をはじめとする各手法は、403エラーを出し抜き、隠れたセキュリティ上の欠陥を明らかにするうえで重要な役割を果たします。

ホストヘッダーの変更

HTTPヘッダーを操作すると、脆弱性が明らかになったり、制限を回避できたりすることがよくあります。

元のリクエスト／レスポンス：

GET /admin HTTP/1.1  
Host: redacted.com

HTTP/1.1 403 Forbidden  
Access Denied

ホストヘッダー変更前
change_host_header_before

変更後のリクエスト／レスポンス（回避）：

GET /admin HTTP/1.1  
Host: google.com

HTTP/1.1 200 Ok  
Admin Panel Login Page(Source Code)

ホストヘッダーの削除

ホストヘッダーを除外し、ホストが指定されていない場合のサーバーのレスポンスをテストします。これにより、デフォルトの挙動や設定ミスが引き起こされることがあります。

元のリクエスト／レスポンス：

GET /reach%2fsip.svc HTTP/1.1
Host: lyncdiscover.microsoft.com
User-Agent: curl/7.79.1
Accept: */*
Connection: close


HTTP/1.1 403 Forbidden
Cache-Control: no-cache
Content-Type: text/html
X-MS-Correlation-Id: fd2fe958-0683-4bb6-8ac6-36637ce86b81
X-Content-Type-Options: nosniff
Date: Thu, 08 Sep 2022 07:25:58 GMT
Connection: close
Content-Length: 1233

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">

    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
            <title> 
                403 - Forbidden: Access is denied. 
            </title>
            <style type="text/css">
...

変更後のリクエスト／レスポンス（回避）：

GET /reach%2fsip.svc HTTP/1.0
<deleted_host_header>


HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/html; charset=UTF-8
X-MS-Correlation-Id: c989aa79-e7d7-4855-9937-67a51a548435
x-ms-client-request-id: c30a03fa-dce8-4a8c-b34f-c5f6a11d47d0
X-Content-Type-Options: nosniff
Date: Thu, 08 Sep 2022 07:45:40 GMT
Connection: close
Content-Length: 3058

さまざまなユーザーエージェントのリクエストの作成

さまざまなユーザーエージェント固有のブロックを利用してリクエストの特徴を変え、ユーザーエージェント固有のブロックを回避します。

  • たとえば、異なるブラウザーや端末のユーザーエージェントを使うと、異なるレスポンスが得られることがあります。
  • ユーザーエージェントの広範なリストは、このリンクで確認できます。

さまざまなプロキシヘッダーのリクエストの作成

プロキシヘッダーを追加し、サーバーが認識するクライアントIPによって挙動が変わるかどうかを確認します。

  • たとえば、次のようなヘッダーを使います。
X-Originating-IP,
X-Forwarded-For,
X-Forwarded,
Forwarded-For,
X-Remote-IP,
X-Remote-Addr,
X-ProxyUser-Ip,
X-Original-URL,
Client-IP,
True-Client-IP,
Cluster-Client-IP
  • 次のような値を指定します。
10.0.0.0 
10.0.0.1
127.0.0.1
127.0.0.1:443
127.0.0.1:80
172.16.0.0
localhost

ポートヘッダーの追加

X-Forwarded-Portヘッダーにポート番号を付加し、サーバーにポート固有のルールがあるかどうかをテストします。 - 例： - X-Forwarded-Port: 443 - X-Forwarded-Port: 80

スキーマヘッダーの追加

リクエストがHTTPかHTTPSかを示すなど、スキーム固有のヘッダーを含めてリクエストを変更します。 - 例： - X-Forwarded-Proto: http - X-Forwarded-Proto: https

HTTPメソッドの変更

GET、POST、PUT、DELETEなどのメソッドを切り替え、異なるメソッドが一貫性のない形で処理されるかどうかを確認します。

HTTPメソッドの変更
change_http_method

HTTPメソッドの大文字・小文字の変更

GETとgetのようなバリエーションをテストし、サーバーが大文字・小文字を区別するかどうかを確認します。 - たとえば、get /admin HTTP/1.1を使います。

ヘッダーを使ったHTTPメソッドの変更

X-HTTP-Method-Overrideのようなヘッダーを使い、メソッドの制限を回避します。 - たとえば、POSTリクエストでX-HTTP-Method-Override: PUTを設定します。 - その他のメソッド： - X-Original-Method - X-Method-Override

パラメーターを編集したリクエストの作成

リクエスト内の既存のパラメーターを変更し、さまざまな入力のシナリオをテストします。

元のリクエスト／レスポンス：

POST /api/admin HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

id=9999&access=restricted

HTTP/1.1 403 Forbidden 
Content-Type: application/json 

{ 
    "error": "Access denied" 
}

変更後のリクエスト／レスポンス（回避）：

POST /api/admin HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

id=1&access=granted

HTTP/1.1 200 OK
Content-Type: application/json

{
    "message": "Access granted",
    "data": {
        "id": 1,
        "role": "admin"
    }
}

留意点：

この手法は、サーバーのレスポンスがコンテキストに依存する場合や、変更したパラメーターが想定どおりに処理されない場合に、誤検知を生むことがあります。加える変更が、テスト対象の具体的なアクセス制御や条件に関連していることを確認してください。標準的でないサーバーの挙動によってレスポンスを誤って解釈すると、脆弱性の有無について誤った結論に至る可能性があります。

パラメーター値のインクリメント

パラメーター値を少しずつ増やし、オフバイワンエラーや境界条件をテストします。 - たとえば、id=1、id=2、id=3のようにします。

留意点：

境界条件をテストするためのパラメーターのインクリメントは、特にアプリケーションがパラメーターを標準的でない方法で処理している場合や、広範な検証ロジックを備えている場合に、誤検知を招くことがあります。結果は想定される挙動の文脈の中で分析するようにし、潜在的な問題を正確に特定するために、さまざまな範囲の値でテストすることを検討してください。アプリケーションの設計やデータの制約によってレスポンスを誤って解釈すると、誤解を招く結論につながる可能性があります。

パラメーターの追加

リクエストにパラメーターを追加し、サーバーがそれらを誤って処理するかどうかを確認します。

  • たとえば、isAdmin=trueを追加します。
  • その他の例：
- ("isAdmin", "true")
- ("order", "desc")
- ("sort_by", "date")
- ("limit", "100")
- ("debug", "true")
- ("admin", "true")
- ("verbose", "true")
- ("user_id", "10")
- ("mode", "admin")
- ("user", "admin")
- ("role", "admin")

パラメーターの削除

パラメーターを削除し、デフォルトの挙動や、必須パラメーターが強制されているかどうかをテストします。たとえば、リクエストからトークンを削除します。

パラメーターの順序の反転

リクエスト内のパラメーターの順序を変えると、サーバーがパラメーターを特定の順序で処理していたり、順序に依存するロジックを持っていたりする場合に、403 Forbiddenエラーの回避に役立つことがあります。たとえば、サーバーがアクセス制御や検証のためにパラメーターを一定の順序で確認している場合、パラメーターの順序を反転させることで、サーバーをだましてアクセスを許可させられることがあります。この手法は、サーバーのバックエンドロジックがパラメーターの順序を固定と想定している場合に特に有効で、この順序を変えることで隠れた脆弱性を明らかにできることがあります。

たとえば、id=1&name=Johnをname=John&id=1に変更します。

エッジケースのパラメーターの追加

エッジケースのパラメーターを追加すると、サーバーの入力処理の限界を試すことで脆弱性を特定しやすくなります。極端に大きな値、特殊文字、想定外の入力形式は、意図しない挙動を引き起こしたり、弱点を明らかにしたりすることがあります。この手法は、サーバーが入力を適切に検証・サニタイズしているかどうか、また403エラーを含むセキュリティ制限の回避につながり得るエッジケースに対して脆弱かどうかをテストするために使えます。

たとえば、id=0やname=-99999999999999999999999999999のようにします。

パラメーターに対するSQLインジェクション

SQLインジェクション攻撃を試み、脆弱性をテストします。

元のリクエスト／レスポンス：

SQLインジェクションによる403回避の前
sqli_to_bypass_403_before

変更後のリクエスト／レスポンス（回避）：

SQLインジェクションによる403回避の後
sqli_to_bypass_403_after

空のパラメーター

空のパラメーター値を使い、サーバーがデータの欠損をどう処理するかを確認します。

  • たとえば、id=とします。

値の反転

パラメーター値の反転とは、パラメーターの値を入れ替えて、サーバーがその内容に応じて異なる処理をするかどうかをテストすることです。この手法は、データの処理方法における脆弱性や不整合を明らかにするために使えます。

仕組み

一部のアプリケーションは、パラメーター値を特定の方法で処理したり、特定の形式に従うことを前提としていたりします。これらの値を反転または変更することで、アプリケーションの入力検証や処理の仕組みが堅牢かどうかをテストできます。

例
  • 数値：「1」を「0」に、または「0」を「1」に変更する
  • 真偽値：「true」を「false」に、「false」を「true」に切り替える
  • 文字列：「yes」を「no」に、「no」を「yes」に、または「Yes」を「No」に、「No」を「Yes」に変更する

パラメーター汚染（パラメーターポリューション）

パラメーター汚染とは、重複する、あるいは矛盾するパラメーターをHTTPリクエストに持ち込むことで、サーバーが入力をどう処理するかを乱したり操作したりする手法を指します。これにより、サーバーを混乱させ、意図しない挙動を引き起こしたり、脆弱性を露出させたりできる可能性があります。

仕組みは次のとおりです。

  1. パラメーターの重複：id=1&id=2のように、同じパラメーターを異なる値で複数回含めることで、サーバーがそのような入力をどう処理するかをテストできます。サーバーはこれらの重複をさまざまな方法で処理する可能性があります。
    • 最初の出現：一部のサーバーは、パラメーターの最初のインスタンスだけを考慮し、それ以降を無視することがあります。
    • 最後の出現：最後に指定された値を使い、それ以前の値を破棄するサーバーもあります。
    • マージ：重複したパラメーターを結合またはマージしようとするサーバーもあり、これが予期しない結果につながることがあります。
  2. 矛盾の処理：サーバーは矛盾するパラメーターを異なる形で処理することがあります。たとえば、リクエストにsort=asc&sort=descが含まれている場合、サーバーがこの矛盾をどう解決するかによって、不整合や弱点が明らかになることがあります。
  3. 制限の回避：パラメーター汚染によって、セキュリティ制限や検証チェックを回避できることがあります。たとえば、あるパラメーターに厳格な検証ルールが設けられていても、そのパラメーターのインスタンスを複数持ち込むことで回避されてしまう場合があります。

パスの大文字・小文字の変更

パス内の文字の大文字・小文字を変更し、大文字・小文字の区別をテストします。 - たとえば、/adminを/Adminに変更します。

パスへの拡張子の付加

パスに拡張子を追加し、異なるファイル形式が異なる扱いを受けるかどうかを確認します。 - たとえば、/adminを/admin.phpに変更します。

パスのバリエーション

さまざまなパスのエンコーディングとバリエーションを試します。 - /path（ブロックされる）→ /%2e/path、/%252e/path - Unicodeによる回避：/%ef%bc%8fpath - 大文字・小文字のバリエーションと末尾のスラッシュ：/secret、/SECRET、/secret/、/secret/.、//secret//、/./secret/. - 追加の文字：;/secret、/.;/secret、//;//secret

元のリクエスト／レスポンス：

パスのバリエーションの前
path_variation_before

変更後のリクエスト／レスポンス（回避）：

パスのバリエーションの後
path_variation_after

APIバージョンの変更

異なるAPIバージョンを切り替え、バージョン固有の脆弱性をテストします。 - たとえば、/v1/usersを/v2/usersに変更します。

パスの先頭文字のURLエンコード

パスの先頭文字をURLエンコードし、エンコードされた文字の不適切な処理をテストします。 - たとえば、/adminを/%61dminに変更します。

Wayback Machineの確認

Wayback Machineの活用は、現在は制限されているものの以前はアクセスできたリソースを明らかにするうえで、セキュリティ評価における戦略的なアプローチになり得ます。対象URLの過去のスナップショットを照会することで、あるページやエンドポイントがさまざまな時点でどのように表示されていたかを把握できます。これは特に次の点で有用です。

  1. 過去のURLの特定：過去の記録から、以前は公開されていたものの現在は制限・削除されているURLやリソースパスが明らかになることがあります。これは、いまだ脆弱かもしれない非推奨のエンドポイントを発見するのに役立ちます。
  2. 隠れたリソースの発見：サイトの以前のバージョンで露出していたディレクトリ、ファイル、APIなどのリソースが、現在は隠されていることがあります。Wayback Machineはこれらのリソースの特定に役立ち、特定の条件下でもアクセス可能かどうかを判断するためのさらなるテストを可能にします。
  3. コンテンツの変化の分析：ページの過去のバージョンを確認することで、アクセス制御やアプリケーションロジックの変化が浮かび上がります。これにより、アプリケーションのセキュリティ態勢がどのように変化してきたか、また新たな脆弱性が持ち込まれていないかについての知見が得られます。

たとえば、現在は403 Forbiddenエラーを返すページが以前のスナップショットではアクセス可能だった場合、Wayback Machineはその以前の構造とコンテンツを示すことができます。この過去の文脈から、現在のバージョンでは見えなくなっている潜在的なアクセス経路や脆弱性が明らかになることがあります。

プロトコルバージョンの変更

HTTP/1.1、HTTP/1.0、HTTP/2.0、HTTP/3.0など、異なるHTTPプロトコルバージョンをテストする際には、すべてのサーバーやスタックがすべてのバージョンに対応しているわけではない点に注意が必要です。一部のサーバーは新しいプロトコルへの対応が限定的だったり一貫性がなかったりするため、リクエストの処理のされ方に影響が及ぶことがあります。たとえば、あるサーバーはHTTP/2.0のリクエストをHTTP/1.1とは異なる形で処理するかもしれませんし、HTTP/3.0にはまったく対応していないかもしれません。この不整合によって予期しない挙動が生じ、特定のリクエストが制限を回避できたり、デフォルトのプロトコルバージョンでは明らかにならない脆弱性が露出したりすることがあります。したがって、異なるバージョンにわたってテストすることは有用ですが、結果に影響を与えかねないスタックの対応上の制約に留意してください。

例：HTTP/1.1をHTTP/1.0に変更する

元のリクエスト／レスポンス：

HTTPのダウングレードの前
downgrade_http_before

変更後のリクエスト／レスポンス（回避）：

HTTPのダウングレードの後
downgrade_http_after

おわりに

リクエストヘッダーのファジング、HTTPメソッドの試行、リクエストパラメーターの変更、リクエストパスの改変といった手法を用いることで、403エラーの背後に隠れた潜在的な脆弱性を明らかにできます。さらに、Wayback Machineでアーカイブされたコンテンツを確認したり、異なるHTTPプロトコルバージョンをテストしたりすることで、見過ごされていたセキュリティ上の欠陥が明らかになることもあります。これらの手法は総合的に、403エラーの回避と、Webアプリケーションにおける重大な弱点の特定に役立ちます。

タグ：

fuzzing, security