API での認証

多くの API では、次のステップは認証のセット アップです。結局のところ、正常に認証できなければ、Mayhem は非常に表面的な問題しかテストできません。ファザーにターゲット API で認証する方法を指示すると、より多くのエンドポイントを実行し、カバレッジを最大化できます。

Mayhem はデフォルトでベーシック認証、ヘッダーベースの認証 (ベアラー トークンなど)、Cookie ベースの認証をサポートしています。これらでは十分ではない場合、書き換えプラグイン システムによって、固有の認証スキームに必要な任意の仕組みを実装するという強力なオプションがあります。これらのオプションについては、下のセクションで説明します。しかしまず、共通事項について説明します。

認証情報の意図しない無効化

ファジングに使用する認証情報がログアウト エンドポイントによって無効化される可能性がある場合、ほぼ確実に、次のように mapi run に --ignore-endpoint を指定して、ファザーが該当エンドポイントにリクエストを発行しないようにする必要があるでしょう。

mapi run [...] --ignore-endpoint "/api/logout"

Info

このフラグや、ファズ対象を選択するためのその他の仕組みについては、「選択的ルート テスト」を参照してください。

ベーシック認証

ベーシック アクセス認証は、Web リソースに対してアクセス制御を適用するためのシンプルな技術であり、ほとんどの Web サーバーでサポートされています。mapi run を使用してターゲットをファジングする際、ベーシック認証情報を指定するには、次のコマンドライン オプション

mapi run --basic-auth "username:password" <target> <duration> <specification>

または環境変数を使用します。

export MAPI_BASIC_AUTH="username:password"
mapi run <target> <duration> <spec>

ベーシック認証は、それ自体はユーザー名およびパスワードを保護しないことに注意してください。伝送時に base64 エンコーディングされるだけで、暗号化やハッシュ化は行われません。認証情報を保護するため、ベーシック認証と HTTPS を組み合わせて使用するか、信頼されたネットワークで使用するべきです。

ヘッダー認証 (ベアラー トークンなど)

ベアラー認証 (トークン認証とも呼ばれます) は、ベアラー トークンと呼ばれるセキュリティトークンを利用した HTTP 認証スキームです。クライアントは、保護されたリソースへのリクエストを行う際、Authorization ヘッダーにトークンを含めて送信する必要があります。

mapi run --header-auth "Authorization: bearer <token>" <target> <duration> <spec>

Mayhem では、同じ仕組みを任意のヘッダーベースの認証に汎用的に利用できます。例:

mapi run --header-auth "X-Custom: auth <token>" <target> <duration> <spec>

環境変数を使用してヘッダーに渡すこともできます。

export MAPI_HEADER_AUTH="Authorization: bearer <token>"
mapi run <target> <duration> <spec>

認証ヘッダーは、それ自体はトークンを保護しないことに注意してください。サーバーにトークンを送信する前に暗号化やハッシュ化は行われません。ベーシック認証の場合と同様に、認証情報を保護するため、ヘッダー認証と HTTPS を組み合わせて使用するか、信頼されたネットワークで使用するべきです。

Info

認証情報を含まないカスタム ヘッダーを指定するには、--header-auth ではなく --header を使用します。Mayhem は、問題を探索する際や潜在的な機密データを編集する際、--header-auth を特別に扱います。

Cookie 認証

Cookie 認証は、HTTP Cookie を使用してクライアント リクエストを認証し、セッション情報を維持します。一般的に、Cookie はログインが成功した後にサーバーから返され、後続のリクエストでクライアントから送信されます。mapi run を使用してターゲットをファジングする際、Cookie を指定するには、次のコマンドライン オプション

mapi run --cookie-auth "PHPSESSID=abe67cd" <target> <duration> <spec>

または環境変数を使用します。

export MAPI_COOKIE_AUTH="PHPSESSID=abe67cd"
mapi run <target> <duration> <spec>

Cookie はサーバーに送信される前に暗号化またはハッシュ化されないことに注意してください。ベーシック認証およびヘッダー認証の場合と同様に、認証情報を保護するためCookie 認証と HTTPS を組み合わせて使用するか、信頼されたネットワークで使用するべきです。

書き換えプラグインを使用した認証

上記の方法では対応できない場合 (API テスト ジョブの過程で動的に認証される場合など)、書き換えプラグイン システムを使用して独自にコーディングを行うことができます。

書き換えプラグインは認証専用ではなく、ドキュメントにあるように、多くの機能を備えています。

Postman 認証

指定された仕様が Postman コレクション ID である場合、Postman コレクションの認証が使用されます。

現時点でサポートされている認証方法は次のとおりです。

• API キー
• ベアラー トークン
• ベーシック認証
• OAuth 2.0 (トークンは synced である必要があります)

現時点では、フォルダーまたはリクエストに対する認証はサポートされていません。Mayhem への引数で認証情報を指定すると、Postman の認証構成がオーバーライドされます。

双方向 TLS

デフォルトでは、mapi はサーバーだけが証明書を共有する従来の「1 方向」 TLS を自動的にサポートします。

双方向 TLS (mTLS) では、クライアントとサーバーの両方が証明書を提示し、信頼された認証局 (CA) に基づいて互いを信頼します。

mapi CLI は、ターゲット API との通信において 1 方向の TLS と双方向の mTLS の両方をサポートしています。

サンプル - RSA, SEC1 Elliptic Curve または PKCS#8

• --ca-cert (任意) サーバーの証明書に署名した CA に所属する CA 証明書です (OS の信頼された証明書にまだ含まれていない場合)
• --cert クライアント証明書です
• --key クライアントの秘密鍵です

mapi run [...] --ca-cert ca.crt --cert client.crt --key client.key

クライアント証明書と鍵を 1 つの .pem ファイルに統合した場合、--cert 引数ではなくそれを使用することができます。

mapi run [...] --cert client.pem

サンプル - PKCS #12 (p12/pfx)

• --ca-cert (任意) サーバーの証明書に署名した CA に所属する CA 証明書です (OS の信頼された証明書にまだ含まれていない場合)
• --p12cert PKCS #12 アーカイブ ファイルです
• --p12password アーカイブ証明書を復号化するためのパスワードです

mapi run [...] --ca-cert ca.crt --p12cert client.p12 --p12password "SECRET"

p12password を環境変数として挿入することもできることに注意してください。

export P12_PASSWORD=SECRET
mapi run [...] --p12cert client.p12

ヘッダー シークレットの抑制

何らかの理由で、テスト対象のサービスによって生成されたヘッダーに機密性があり、レポートから削除したりサニタイズしたりする必要がある場合、--redact-header オプションを利用できます。 このオプションを使用すると、CLI はヘッダーのすべての値を <REDACTED> に置き換えます。

たとえば、--redact-header "x-my-proxy-token" を渡すと、x-my-proxy-token という名前のすべてのリクエストまたはレスポンス ヘッダーの値が <REDACTED> に変えられます。 リクエストに x-my-proxy-token: Foo-42 というヘッダーがある場合、ヘッダーのレポートは x-my-proxy-token: <REDACTED> となります。

追加予定

近いうちにより多くの認証方法のサポートが予定されており、ユーザーからの意見を求めています。Discord または E-mail support@forallsecure.com で追加希望についてお知らせください。

---

これで、Mayhem は API の認証付きエンドポイントも実行できるようになったはずです。すばらしい!

Info

API ですでに問題が発見されている場合、先に結果の詳細について扱っているバグのあるエンドポイントの識別を参照するとよいでしょう。

しかし、まだ完了ではありません。多くの現実の API には、認証以外に、特殊すぎてランダム ファジングだけでは確実に発見するのが難しい入力要件があります。 次のセクションでは、Mayhem に API 全体を検証させる理由と方法について説明します。