testing-mobile-api-authentication

モバイル API 認証のテスト

使用する場面

次のような場合に、このスキルを使用します。

• ペネトレーションテストで、モバイルアプリのバックエンド API 認証を評価する
• 一般的な脆弱性（none アルゴリズム、弱い署名）について、JWT トークンの実装をテストする
• リダイレクト、PKCE、スコープの問題について、モバイルアプリの OAuth 2.0 / OIDC フローを評価する
• API エンドポイントのオブジェクトレベル認可の不備（BOLA/IDOR）をテストする

明示的な許可がなく、レート制限への配慮もない状態で、本番 API に対してこのスキルを使用しないでください。

前提条件

• モバイルデバイスのプロキシとして設定した Burp Suite または mitmproxy
• 対象アプリケーションで SSL ピンニングが実装されている場合、その回避
• 対象アプリケーションの有効なテストアカウントの認証情報
• API リクエストの作成に使用する Postman または curl
• JWT の分析と操作に使用する jwt.io または PyJWT

ワークフロー

ステップ 1：認証エンドポイントを特定する

モバイルアプリの通信を傍受し、認証関連のエンドポイントを特定します。

POST /api/v1/auth/login          - Initial authentication
POST /api/v1/auth/register       - Account registration
POST /api/v1/auth/refresh        - Token refresh
POST /api/v1/auth/logout         - Session termination
POST /api/v1/auth/forgot-password - Password reset
POST /api/v1/auth/verify-otp     - OTP verification
GET  /api/v1/auth/me             - Authenticated user profile

ステップ 2：トークンの形式とセキュリティを分析する

JWT の分析：

# Decode JWT without verification
echo "eyJhbGciOiJIUzI1NiIs..." | cut -d. -f2 | base64 -d 2>/dev/null

# Check for common JWT vulnerabilities:
# 1. None algorithm attack
# Change header to: {"alg":"none","typ":"JWT"}
# Remove signature: header.payload.

# 2. Algorithm confusion (RS256 to HS256)
# If server uses RS256, try HS256 with public key as secret

# 3. Weak signing key
# Use hashcat or jwt-cracker to brute-force HMAC secret
hashcat -m 16500 jwt.txt wordlist.txt

# 4. Expiration bypass
# Modify "exp" claim to future timestamp

不透明トークンの分析：

- Test token length and entropy
- Check if tokens are sequential/predictable
- Test token reuse after logout
- Verify token invalidation on password change

ステップ 3：認証バイパスをテストする

# Test missing authentication
curl -X GET https://api.target.com/api/v1/users/profile

# Test with empty/null token
curl -X GET https://api.target.com/api/v1/users/profile \
  -H "Authorization: Bearer "

curl -X GET https://api.target.com/api/v1/users/profile \
  -H "Authorization: Bearer null"

# Test with expired token (should fail)
curl -X GET https://api.target.com/api/v1/users/profile \
  -H "Authorization: Bearer <expired_token>"

# Test token from different user
curl -X GET https://api.target.com/api/v1/users/123/profile \
  -H "Authorization: Bearer <user_456_token>"

ステップ 4：IDOR／オブジェクトレベル認可の不備をテストする

# Change user ID in request path
curl -X GET https://api.target.com/api/v1/users/123/orders \
  -H "Authorization: Bearer <user_456_token>"

# Change object ID in request body
curl -X PUT https://api.target.com/api/v1/orders/789 \
  -H "Authorization: Bearer <user_456_token>" \
  -d '{"status": "cancelled"}'

# Test horizontal privilege escalation
# Access admin endpoints with regular user token
curl -X GET https://api.target.com/api/v1/admin/users \
  -H "Authorization: Bearer <regular_user_token>"

ステップ 5：セッション管理をテストする

# Test concurrent sessions
# Login from multiple devices simultaneously - should both remain valid?

# Test session invalidation after logout
TOKEN=$(curl -s -X POST https://api.target.com/api/v1/auth/login \
  -d '{"email":"[email protected]","password":"pass"}' | jq -r '.token')

# Logout
curl -X POST https://api.target.com/api/v1/auth/logout \
  -H "Authorization: Bearer $TOKEN"

# Try using the same token (should fail)
curl -X GET https://api.target.com/api/v1/users/me \
  -H "Authorization: Bearer $TOKEN"

# Test session invalidation after password change
# Token obtained before password change should be invalidated

ステップ 6：OAuth 2.0 / OIDC のモバイルフローをテストする

# Test for authorization code interception
# Check if PKCE (Proof Key for Code Exchange) is enforced
# Test with missing code_verifier parameter

# Test redirect URI manipulation
# Try custom scheme hijacking: myapp://callback
# Test with modified redirect_uri parameter

# Test scope escalation
# Request higher privileges than granted

主な概念

用語	定義
BOLA/IDOR	オブジェクトレベル認可の不備。サーバー側の認可チェックを受けずに、識別子を変更してリソースにアクセスすること
JWT	JSON Web Token。ヘッダー、ペイロード、署名で構成される自己完結型の認証トークン
PKCE	Proof Key for Code Exchange。モバイルアプリでの認可コードの傍受を防ぐ OAuth 2.0 拡張機能
トークンの更新	長期間有効なリフレッシュトークンを使用して、再認証せずに新しいアクセストークンを取得する仕組み
セッション固定攻撃	攻撃者が被害者の認証前に既知のセッション ID を設定し、その後セッションを乗っ取る攻撃

ツールとシステム

• Burp Suite：認証リクエストを傍受、変更するための HTTP プロキシ
• jwt_tool：JWT の脆弱性（none アルゴリズム、鍵の混同、クレームの操作）をテストする Python ツール
• Postman：認証リクエストを作成する API テスト用クライアント
• hashcat：HMAC 署名鍵の強度テストに使用するパスワード／JWT シークレットの解析ツール
• Autorize：認可テストを自動化する Burp Suite 拡張機能

よくある落とし穴

• レート制限によって問題が見えにくくなる：API がテストリクエストをレート制限する場合があります。リクエストの間隔を空け、まずテスターに許可された視点からテストしてください。
• URL 内のトークン：モバイル API によっては、URL のクエリパラメーターでトークンを渡すことがあり、サーバーログやブラウザー履歴に露出します。認可が正しく機能していても、発見事項として報告してください。
• リフレッシュトークンのローテーション：使用ごとにリフレッシュトークンをローテーションする API があります。テストでリフレッシュトークンを無効にすると、テストアカウントがロックアウトされる可能性があります。
• モバイル固有の OAuth：モバイルアプリは OAuth リダイレクトにカスタム URI スキームを使用するため、同じスキームを登録した悪意のあるアプリに傍受される可能性があります。