Broken User Authentication

Broken User Authenticationとは？

Broken User Authenticationは、いくつかの問題として現れます。認証を扱うAPIエンドポイントは、アプリ内の動線や表示されるデータを左右するため、特に注意する必要があります。次のいずれかの状態であれば、Broken User Authenticationといえます。

• もし貴社のAPIがクレデンシャルスタッフィングを許している場合。これは、ハッカーが他サイトで漏洩した既知のアカウント名とパスワードのリストを使い、ブルートフォース攻撃を試みる手法です。人は古いユーザー名とパスワードを再利用する傾向があるため、一度資格情報が漏れると多くのアカウントが狙われます。攻撃者はこれらの情報を急速に試し、WallarmのAPIエンドポイントで有効か確認します。レート制限を設ける必要があります。
• もしAPIエンドポイントが必要な場合にキャプチャでリクエスト確認を行わない場合。
• アプリが弱いパスワードを許容する場合。パスワードではなくパスフレーズを使うのが望ましいですが、いかなる場合も弱いパスワードよりは優れています。
• エンドポイントがURL内のGETパラメータを利用して、パスワードやトークンなどの機密情報を送信する場合。これにより、中間者攻撃のリスクが生じます。
• エンドポイントがJWTなどのトークンを発行するものの、検証を行わない場合。
• JWTを利用する際、署名なしや弱い署名のトークンを受け付けるべきではありません。
• エンドポイントがセッショントークンやJWTなどの認証トークンの有効期限を検証しない場合。
• エンドポイントがパスワードの暗号化やハッシュ化を行わず、または弱い暗号化アルゴリズムを使用する場合。
• 推測しやすい暗号鍵（例：誕生日）や、解析が容易なもの（例：md5）を使用する場合。

攻撃シナリオの例

パスワードリカバリー

攻撃者は、/api/v1/reset-passwordエンドポイントを起動して、パスワードリセットの流れを開始する可能性があります。

POST /api/v1/reset-password
{
    userID=123
}

これにより、ユーザー「rat」のパスワードリセットが実行され、4桁の数字のリセットトークンがメールで送信されます。エンドポイントにレート制限がないため、攻撃者は全ての4桁の組み合わせを高速に試し、ブルートフォース攻撃を行うことが可能です。

POST /api/v1/reset-password-token
{
    userID=123.
    tokenID=xxxx
    newPass=test
}

その後、攻撃者はトークンを推測し、ユーザーのパスワードをリセットできます。

JWT検証エンドポイントが「None」アルゴリズムを受け入れる場合

JWTエンドポイントは必ず、適切なアルゴリズムでトークンを検証する必要があります。多くのJWTフレームワークではNoneアルゴリズムがデフォルトで有効になっており、これは非常に問題です。まずはJWTの動作を確認してください。

JWTトークンとはJson Web Tokenの略で、ユーザー情報などを含むトークンです。容易にデコードして内容を確認できるのが特徴ですが、内容変更にはアルゴリズムによる署名が必要です。

以下はJWTトークンの例で、デコードすると次のようになります：

{
    "alg": "HS256",
    "typ": "JWT"
}
{
    "userID": "123",
    "sub": "1234567890",
    "name": "John Doe",
    "iat": 1516239022
}

このJWTトークンを編集するには、HS256の鍵が必要です。

JWTの仕組みが分かれば、検証機構がNoneアルゴリズムを受け入れるのがいかに問題か理解いただけると思います。JWT内の内容を変更し、アルゴリズムをNoneに変えて再エンコードすることが可能です。

{
    "alg": "None",
    "typ": "JWT"
}
{
    "userID": "567",
    "sub": "1234567890",
    "name": "John Doe",
    "iat": 1516239022
}

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjU2NyIsInN1YiI6IjEyMzQ1Njc4OTAiLCJuYW1lIjoiSm9obiBEb2UiLCJpYXQiOjE1MTYyMzkwMjJ9.NhHRUCQw5Wtuc7Jn2ImmC8URY0UmcuEkukmNA9Frccs

リクエスト時にヘッダ内のこのトークンを差し替えると、通常は無効なトークンとしてエラーが返るはずです。しかし、サーバーがNoneアルゴリズムで署名されたリクエストを許容している場合、Broken User Authenticationの脆弱性にさらされます。

‍

Broken User Authenticationに対する予防策

• APIにおける認証に関連する全ての流れ（モバイル、ディープリンク、ワンクリックログイン等）を洗い出すことが非常に重要です。

• 認証メカニズムがどのように機能しているかを正確に把握し、OAuth2などを安易に実装しないこと。
• 独自の認証仕組みを実装せず、広く知られている認証ソリューションを利用すること。
• 全ての認証エンドポイント（パスワード忘れも含む）は、レート制限とロックアウト機構で保護し、他のエンドポイントよりも厳格に設定すること。
• OWASP Authentication Cheatsheetは、認証実装の参考資料として優れている。
• 可能であれば、SMSや認証アプリなどの多要素認証の導入を検討すること。
• レート制限・ロックアウト機構に加え、キャプチャ機構を実装し、攻撃者によるブルートフォース攻撃を防ぐこと。
• 認証にAPIキーを用いず、クライアント／アプリの認証に使用すること。

‍

‍

結論

認証エンドポイントを扱う際は、通常のエンドポイントよりも厳格なセキュリティ対策が求められます。レート制限、ロックアウト、キャプチャ機構を適切に実装し、攻撃者によるブルートフォース攻撃やクレデンシャルスタッフィングを防止してください。安全な認証仕組みの実装に不安がある場合は、OWASP Authentication Cheatsheet、またはOWASP Top 10 vulnerabilitiesの記事を参照するか、WallarmのAPIセキュリティプラットフォームの利用を検討してください。