mcpField
S
sast-missingauth

sast-missingauth

github.com/utkusenセキュリティ1.3k69 回インストール5 日前に更新
リポジトリ

sast-missingauth について

sast-missingauthは、認証の欠如と機能レベル認可の不備を検出するコードセキュリティ評価スキルです。事前にアーキテクチャ概要を用意し、エンドポイントと権限設定の整理、バッチ検証、結果の統合を進めます。

主な機能

  1. 01エンドポイントと権限の整理
  2. 02認証漏れの検出
  3. 03ロール確認の検証
  4. 04エンドポイントのバッチ調査
  5. 05評価結果の統合

活用シーン

  1. 01ログイン確認のない機密エンドポイントの特定
  2. 02管理ルートのロール制御の確認
  3. 03ルートのミドルウェア適用範囲の確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/utkusen/sast-skills --skill sast-missingauth

インストール後、Claude Code で/sast-missingauthを入力して読み込まれたか確認します。

詳細

認証の欠如と関数レベル認可の不備の検出

コードベースにおける認証の欠如と関数レベル認可の不備の脆弱性を見つけるため、対象を絞ったセキュリティ評価を実施します。このスキルでは、サブエージェントを使用した3段階のアプローチを採用します。偵察(エンドポイントと権限システムの把握)、バッチ検証(エンドポイント3件ずつの並列バッチで認証と認可を確認)、統合(バッチの結果を最終レポートにまとめる)。

前提条件:sast/architecture.md が存在している必要があります。存在しない場合は、先に分析スキルを実行してください。


このスキルの対象範囲

認証の欠如

エンドポイントが機密性の高いアクションを実行するにもかかわらず、ログインが一切不要で、匿名のHTTPリクエストで誰でも実行できる状態です。

関数レベル認可の不備

エンドポイントで認証は必要(ユーザーがログインしている必要がある)ですが、認証済みユーザーにその関数を呼び出すための必要なロールまたは権限があるかどうかを確認していない状態です。典型例は、一般ユーザーが管理者専用APIを呼び出せることです。

このスキルの対象外

以下と混同しないでください。

  • IDOR/水平権限昇格:認証済みユーザーAがIDを変更してユーザーBのリソースにアクセスすることです。このスキルの対象は、垂直方向の権限昇格と未認証アクセスです。
  • JWTの脆弱性:トークンの署名や検証の不備です(sast-jwtの対象です)。
  • ビジネスロジックの不備:価格の改ざんやワークフローの回避などです。これらは別の問題です。

脆弱性の分類

クラス1:未認証でアクセス可能な機密エンドポイント

エンドポイントがデータを変更する、非公開情報を返す、または管理操作を実行するにもかかわらず、認証が不要な状態です。

GET /api/admin/users          → returns full user list, no token needed
DELETE /api/admin/users/5     → deletes a user, no token needed
POST /api/settings/smtp       → updates server config, no token needed
クラス2:認証済みだがロールチェックが欠如

エンドポイントで有効なセッションまたはトークンが必要ですが、ロールや権限のチェックがありません。ロールにかかわらず、認証済みユーザーであれば誰でも管理機能や特権機能を呼び出せます。

Regular user sends:
DELETE /api/admin/users/5
Authorization: Bearer <regular_user_token>
→ Server deletes the user without checking if the caller is an admin
クラス3:不完全または回避可能な認可

認可ロジックは存在しますが、回避できます。

  • GETハンドラーにはロールチェックがあるものの、対応するDELETE/POSTハンドラーにはない
  • 攻撃者が制御できるリクエストヘッダーまたはパラメーターを条件としたロールチェック
  • ミドルウェアは登録されているものの、適用前にルートがマウントされている

脆弱性を防ぐ認可パターン

以下のパターンが見られる場合、エンドポイントに脆弱性はないと考えられます。

1. ルートグループへの認証およびロールチェック用ミドルウェアの適用

// Express: all /admin routes protected
router.use('/admin', auth, requireRole('admin'));
router.delete('/admin/users/:id', deleteUser);   // protected by above

// Flask-Login + custom decorator
@app.route('/admin/users')
@login_required
@admin_required
def list_users(): ...

2. 宣言的なロールアノテーション(Java/Spring)

@PreAuthorize("hasRole('ADMIN')")
@DeleteMapping("/api/admin/users/{id}")
public ResponseEntity<?> deleteUser(@PathVariable Long id) { ... }

3. 機密性の高いアクションの前に行うハンドラー内のロールチェック

# Django
@login_required
def delete_user(request, user_id):
    if not request.user.is_staff:
        return HttpResponseForbidden()
    User.objects.filter(id=user_id).delete()
    return HttpResponse(status=204)

4. プレフィックス全体に適用されるミドルウェアによるゲート

// Chi router — admin group protected
r.Group(func(r chi.Router) {
    r.Use(AdminOnly)
    r.Delete("/admin/users/{id}", deleteUser)
})

5. ポリシー/ゲートオブジェクト

// Laravel Gate
Gate::define('admin-action', fn($user) => $user->role === 'admin');
// In controller
$this->authorize('admin-action');

脆弱な例と安全な例

Python — Django
# VULNERABLE: No authentication at all
def list_all_users(request):
    users = User.objects.values('id', 'email', 'is_staff')
    return JsonResponse(list(users), safe=False)

# VULNERABLE: Authenticated but no role check
@login_required
def delete_user(request, user_id):
    User.objects.filter(id=user_id).delete()
    return HttpResponse(status=204)

# SECURE
@login_required
def delete_user(request, user_id):
    if not request.user.is_staff:
        return HttpResponseForbidden()
    User.objects.filter(id=user_id).delete()
    return HttpResponse(status=204)
Python — Flask
# VULNERABLE: No auth decorator
@app.route('/admin/users')
def list_users():
    return jsonify([u.to_dict() for u in User.query.all()])

# VULNERABLE: Login required but no role check
@app.route('/admin/users/<int:user_id>', methods=['DELETE'])
@login_required
def delete_user(user_id):
    user = User.query.get_or_404(user_id)
    db.session.delete(user)
    db.session.commit()
    return '', 204

# SECURE
@app.route('/admin/users/<int:user_id>', methods=['DELETE'])
@login_required
def delete_user(user_id):
    if current_user.role != 'admin':
        abort(403)
    user = User.query.get_or_404(user_id)
    db.session.delete(user)
    db.session.commit()
    return '', 204
Node.js — Express
// VULNERABLE: No auth middleware
router.get('/api/admin/users', async (req, res) => {
    const users = await User.find({});
    res.json(users);
});

// VULNERABLE: Auth middleware present but no role check
router.delete('/api/admin/users/:id', auth, async (req, res) => {
    await User.findByIdAndDelete(req.params.id);
    res.sendStatus(204);
});

// SECURE
const requireAdmin = (req, res, next) => {
    if (req.user.role !== 'admin') return res.sendStatus(403);
    next();
};
router.delete('/api/admin/users/:id', auth, requireAdmin, async (req, res) => {
    await User.findByIdAndDelete(req.params.id);
    res.sendStatus(204);
});
Ruby on Rails
# VULNERABLE: No before_action
def destroy
    User.find(params[:id]).destroy
    head :no_content
end

# VULNERABLE: Authenticated but no admin check
before_action :authenticate_user!
def destroy
    User.find(params[:id]).destroy
    head :no_content
end

# SECURE
before_action :authenticate_user!
before_action :require_admin

def destroy
    User.find(params[:id]).destroy
    head :no_content
end

private

def require_admin
    head :forbidden unless current_user.admin?
end
Java — Spring Boot
// VULNERABLE: No security annotation
@DeleteMapping("/api/admin/users/{id}")
public ResponseEntity<?> deleteUser(@PathVariable Long id) {
    userRepo.deleteById(id);
    return ResponseEntity.noContent().build();
}

// VULNERABLE: Authenticated but wrong role
@DeleteMapping("/api/admin/users/{id}")
@Secured("ROLE_USER")  // any user can call this
public ResponseEntity<?> deleteUser(@PathVariable Long id) {
    userRepo.deleteById(id);
    return ResponseEntity.noContent().build();
}

// SECURE
@DeleteMapping("/api/admin/users/{id}")
@PreAuthorize("hasRole('ADMIN')")
public ResponseEntity<?> deleteUser(@PathVariable Long id) {
    userRepo.deleteById(id);
    return ResponseEntity.noContent().build();
}
Go
// VULNERABLE: No auth middleware on route
r.Delete("/admin/users/{id}", deleteUser)

// VULNERABLE: Auth middleware but no role check in handler
r.With(AuthMiddleware).Delete("/admin/users/{id}", deleteUser)

func deleteUser(w http.ResponseWriter, r *http.Request) {
    id := chi.URLParam(r, "id")
    db.DeleteUser(id)  // no role check
    w.WriteHeader(http.StatusNoContent)
}

// SECURE
r.Group(func(r chi.Router) {
    r.Use(AuthMiddleware)
    r.Use(AdminOnlyMiddleware)
    r.Delete("/admin/users/{id}", deleteUser)
})
PHP — Laravel
// VULNERABLE: No auth middleware
Route::delete('/admin/users/{id}', [AdminController::class, 'destroy']);

// VULNERABLE: Auth but no role gate
Route::middleware('auth')->delete('/admin/users/{id}', [AdminController::class, 'destroy']);

// SECURE
Route::middleware(['auth', 'role:admin'])->delete('/admin/users/{id}', [AdminController::class, 'destroy']);

// SECURE (using Gate in controller)
public function destroy($id) {
    Gate::authorize('admin-action');
    User::findOrFail($id)->delete();
    return response()->noContent();
}
C# — ASP.NET Core
// VULNERABLE: No authorization attribute
[HttpDelete("api/admin/users/{id}")]
public async Task<IActionResult> DeleteUser(int id) {
    await _userService.DeleteAsync(id);
    return NoContent();
}

// VULNERABLE: [Authorize] but no role
[Authorize]
[HttpDelete("api/admin/users/{id}")]
public async Task<IActionResult> DeleteUser(int id) {
    await _userService.DeleteAsync(id);
    return NoContent();
}

// SECURE
[Authorize(Roles = "Admin")]
[HttpDelete("api/admin/users/{id}")]
public async Task<IActionResult> DeleteUser(int id) {
    await _userService.DeleteAsync(id);
    return NoContent();
}

実行

このスキルは、サブエージェントを使用して3段階で実行されます。sast/architecture.md の内容をコンテキストとしてすべてのサブエージェントに渡してください。

フェーズ 1:調査 — エンドポイントと権限システムをマッピングする

以下の指示を使ってサブエージェントを起動します。

目標:(1) すべてのアプリケーションのエンドポイント/ルートと、現在の認証・認可の状態、および (2) ロール/権限システムを完全にマッピングします。結果は sast/missingauth-recon.md に書き込みます。

コンテキスト:プロジェクトのアーキテクチャ概要が提供されます。これを使って、技術スタック、フレームワーク、ルート定義、認証/認可の方針を把握してください。

調査する項目:

  1. すべてのルート/エンドポイント定義 — すべての HTTP ハンドラー、REST エンドポイント、GraphQL のミューテーション/クエリ、RPC メソッド、WebSocket ハンドラーを収集します。
    • Express/Koa:router.get/post/put/delete/patch/use
    • Django:urlpatterns、path()、re_path()
    • Flask:@app.route、@blueprint.route
    • Rails:routes.rb — get、post、resources、namespace
    • Spring:@GetMapping、@PostMapping、@RequestMapping、@DeleteMapping、@PutMapping
    • Go/Chi:r.Get、r.Post、r.Delete、r.Handle
    • Laravel:Route::get/post/put/delete
    • FastAPI:@router.get/post/put/delete
    • ASP.NET:[HttpGet]、[HttpPost]、[HttpDelete]、[HttpPut]
  2. 現在適用されている認証ミドルウェアとデコレーター:
    • 使用されているパターンを特定します:@login_required、auth ミドルウェア、[Authorize]、authenticate_user!、JWT 検証ミドルウェア、セッションチェック
    • 適用されているルートまたはルートグループを記録します
    • 認証から明示的に除外されているルートがあれば記録します(例:except: [:index, :show])
  3. ロール/権限システム — ロールの定義方法とチェック方法を特定します。
    • ロール定数/列挙型:ROLE_ADMIN、'admin'、UserRole.ADMIN、is_staff、is_superuser
    • 権限デコレーター:@admin_required、@roles_required、@PreAuthorize、requireRole()
    • ミドルウェア:AdminOnly、requireAdmin、role:admin
    • ポリシー/ゲート/アビリティオブジェクト:Gate::define、Policy、CanCanCan、Pundit
    • ハンドラー内のチェック:if user.role != 'admin'、if not current_user.is_admin
  4. 要注意の機密/特権エンドポイント — 以下に該当するエンドポイントを特定します。
    • パスのプレフィックスに /admin、/management、/internal、/api/admin、/superadmin、/system、/ops がある
    • ユーザー管理を行う:ユーザーの作成/更新/削除、ロールの変更、他のユーザーのパスワードのリセット
    • アプリケーション設定を管理する:設定、機能フラグ、SMTP、シークレット、環境変数
    • 金融/請求データにアクセスする:すべてのユーザーの請求書、支払い、サブスクリプション
    • システム操作を実行する:全ユーザーへのメール送信、バックグラウンドジョブの実行、キャッシュの消去
    • 集計データまたは機密データを返す:すべてのユーザー、すべての注文、監査ログ、エラーログ
  5. 各エンドポイントについて記録する項目:
    • 認証ミドルウェア/デコレーターの有無
    • ロール/権限チェックの有無
    • 対応する HTTP メソッド
    • データの読み取り、書き込み、削除のいずれを行うか

調査対象から除外する項目:

  • 公開を想定したエンドポイント:ログイン、登録、パスワードリセットのリクエスト、公開コンテンツ(ブログ記事、商品一覧)
  • 静的アセットの配信、ヘルスチェックのエンドポイント(/health、/ping、/status)

出力形式 — sast/missingauth-recon.md に書き込みます。

# 認証不備の調査:[プロジェクト名]

## 権限システムの概要
- 特定されたロール:[ロールの一覧。例:admin、moderator、user]
- 認証方式:[JWT / session / API key / OAuth]
- 認証デコレーター/ミドルウェア:[名前の一覧。例:@login_required、auth、requireAdmin]

## エンドポイント一覧

### 1. [エンドポイント名/説明]
- **ファイル**:`path/to/file.ext`(行 X-Y)
- **エンドポイント**:`METHOD /path`
- **操作**:[read / write / delete / admin-action]
- **認証あり**:[yes / no]
- **ロールチェックあり**:[yes / no / partial]
- **コードスニペット**:

[ルート登録 + ハンドラーのシグネチャ]


[各エンドポイントについて繰り返す]
Phase 2: 検証 — 認証と認可を確認する(バッチ処理)

Phase 1 が完了したら、sast/missingauth-recon.md を読み、エンドポイント一覧を最大 3 件ずつのバッチに分割します(各エンドポイントは Endpoint Inventory の下に ### N. として番号付きで記載されています)。バッチごとにサブエージェントを 1 つ起動し、並行して作業させます。各サブエージェントは、割り当てられたエンドポイントのみを検証し、結果を専用のバッチファイルに書き込みます。

バッチ分割の手順(サブエージェントではなく、あなたがオーケストレーターとして実行します):

  1. sast/missingauth-recon.md を読み、Endpoint Inventory の下にある番号付きエンドポイントのセクション(### 1., ### 2. など)の数を数えます。
  2. 最大 3 件ずつのバッチに分割します。例:エンドポイントが 8 件の場合、3 つのバッチ(1~3、4~6、7~8)に分割します。
  3. 各バッチについて、recon ファイルから該当するエンドポイントセクションの全文を抜き出します。
  4. すべてのバッチサブエージェントを並行して起動し、それぞれに割り当てられたエンドポイントのみを渡します。
  5. 各サブエージェントは sast/missingauth-batch-N.md に書き込みます。N は 1 から始まるバッチ番号です。
  6. sast/architecture.md からプロジェクトの主要な言語/フレームワークを特定し、上記の「脆弱な例と安全な例」セクションから該当する例のみを選択します。たとえば、プロジェクトで Python/Django が使用されている場合は、「Python — Django」の例のみ(必要に応じて Flask の例も)を含めます。以下の [TECH-STACK EXAMPLES] で示す箇所に、選択した例を各サブエージェントへの指示に含めます。

各バッチサブエージェントに、以下の指示を与えます(バッチごとの値に置き換えてください):

目標:以下のエンドポイントについて、認証の欠如と関数レベルの認可不備の脆弱性がないか確認してください。結果は sast/missingauth-batch-[N].md に記録してください。

担当するエンドポイント(偵察フェーズで割り当てられたもの):

[元の番号を維持したまま、割り当てられたエンドポイントのセクション全体をここに貼り付けてください]

コンテキスト:プロジェクトのアーキテクチャ概要が提供されます。これを使用して、ミドルウェアの実行順序、ロールの定義、認証パターンを把握してください。

認証の欠如/関数レベルの認可不備 — 確認する項目:

  • 認証の欠如:ログイン/セッション/トークンが不要な機密操作。
  • 関数レベルの認可不備:認証は必要だが、特権エンドポイントでロール/権限が確認されていない(垂直権限昇格)。

このスキルの対象外 — ここでは次の項目を報告しないでください:

  • IDOR/水平権限昇格:ユーザー A が ID を変更してユーザー B のリソースにアクセスすること → IDOR スキルの対象です。
  • JWT の暗号化/検証の不具合 → sast-jwt の対象です。

問題を防ぐ認可パターン — 次のパターンがあれば、エンドポイントは安全である可能性が高いです:

  1. ルートグループへの認証+ロール確認ミドルウェアの適用(例:router.use('/admin', auth, requireRole('admin')))
  2. 宣言的なロールアノテーション(例:@PreAuthorize("hasRole('ADMIN')"))
  3. 機密操作の前にハンドラー内でロールを確認
  4. プレフィックス全体に対するミドルウェアのゲート(例:AdminOnly を適用した Chi の r.Group)
  5. 特権操作を強制するポリシー/Gate オブジェクト

このプロジェクトの技術スタックにおける脆弱な例と安全な例:

[TECH-STACK EXAMPLES]

割り当てられた各エンドポイントについて、次の点を評価してください:

  1. 認証の確認 — 有効なログイン/セッション/トークンが必要ですか?
    • このルートまたは親グループに、認証ミドルウェア、デコレーター、またはガードが適用されていますか?
    • ミドルウェアチェーンを追跡し、認証ミドルウェアがハンドラーの後ではなく前に実行されることを確認してください。
    • ルートが誤って認証保護グループの外にマウントされていないか確認してください。
  2. ロール/権限の確認 — エンドポイントが特権操作を行う場合、ロールまたは権限が検証されていますか?
    • 次を確認してください:is_admin、is_staff、role == 'admin'、hasRole('ADMIN')、@PreAuthorize、requireRole、can?(:manage, ...)、Gate::allows、authorize('admin-action')
    • すべての HTTP メソッドでチェックが実行されることを確認してください。GET が保護されていても、DELETE が保護されていない場合があります。
    • ロールの比較が逆になっていたり、簡単に回避できたりしないことを確認してください。
  3. エッジケース:
    • チェックが、ユーザー制御可能なヘッダー、パラメーター、またはクエリー文字列に条件付きで依存していませんか?
    • 認証ゲートはルートグループに適用されていても、特定のルートが except リストによって除外されていませんか?
    • 同じ機能に対する、認証されていない別の経路(例:内部 API のエイリアス)がありませんか?
    • ミドルウェアは一部の環境でのみ適用されますか(例:テストモードではスキップされる)?
  4. 特権の識別:
    • エンドポイントのパスから、管理者向け/特権エンドポイント(/admin/、/manage/、/internal/)だと判断できますか?
    • この操作は、他のユーザーのデータ、システム設定、または集約レコードに影響しますか?
    • どちらかに該当する場合、ロール/権限のチェックが必要です。

分類:

  • 脆弱:認証が不要、または認証は必要だが、特権エンドポイントでロールチェックが完全に欠如している。
  • 脆弱の可能性あり:認証および/またはロールチェックは存在するが、不完全、回避可能、または誤って適用されているように見える(例:ロールの誤り、HTTP メソッドの誤り、条件付きのスキップ)。
  • 脆弱ではない:適切な認証とロール/権限チェックが実施されている。
  • 手動レビューが必要:確信を持って判断できない(例:複雑なミドルウェアチェーン、動的なロールの読み込み、サービスレイヤーへの認可の委譲)。

出力形式 — sast/missingauth-batch-[N].md に記録してください:

# 認証欠如バッチ [N] の結果

## 検出結果

### [脆弱] エンドポイント名
- **ファイル**:`path/to/file.ext`(行 X-Y)
- **エンドポイント**:`METHOD /path`
- **問題**:[認証の欠如/特権操作に対するロールチェックの欠如]
- **影響**:[未認証または低権限の攻撃者が実行できること]
- **証拠**:[ルート定義とハンドラーを示し、チェックが欠けている箇所を明示する]
- **修正方法**:[認証ミドルウェアの追加、ロールデコレーターの追加など、具体的な修正]
- **動的テスト**:

[ライブアプリで確認するための curl コマンドまたは手順。 認証欠如の場合:トークンなしのリクエストが成功することを示す。 ロール欠如の場合:一般ユーザーのトークンで管理者用エンドポイントへのリクエストが成功することを示す。 <REGULAR_USER_TOKEN>、<ADMIN_ENDPOINT> などのプレースホルダーを使用する。]


### [脆弱の可能性あり] エンドポイント名
- **ファイル**:`path/to/file.ext`(行 X-Y)
- **エンドポイント**:`METHOD /path`
- **問題**:[チェックが不完全な点]
- **懸念事項**:[悪用される可能性が残る理由]
- **証拠**:[弱い/部分的なチェックを含むコードパスを示す]
- **修正方法**:[具体的な修正]
- **動的テスト**:

[ライブアプリでこの検出結果を確認するための curl コマンドまたは手順。]


### [脆弱ではない] エンドポイント名
- **ファイル**:`path/to/file.ext`(行 X-Y)
- **エンドポイント**:`METHOD /path`
- **保護**:[認証ミドルウェア+ロールデコレーター、@PreAuthorize、Gate など、保護方法]

### [手動レビューが必要] エンドポイント名
- **ファイル**:`path/to/file.ext`(行 X-Y)
- **エンドポイント**:`METHOD /path`
- **不確実性**:[自動分析で状態を判断できなかった理由]
- **提案**:[手動で確認する項目]
フェーズ 3:マージ — バッチ結果の統合

すべてのフェーズ 2 のバッチサブエージェントが完了したら、すべての sast/missingauth-batch-*.md ファイルを読み込み、内容を 1 つの sast/missingauth-results.md に統合します。これはオーケストレーターであるあなたが直接行います。サブエージェントは必要ありません。

マージ手順:

  1. sast/missingauth-batch-1.md、sast/missingauth-batch-2.md、... のすべてのファイルを読み込みます。
  2. 各バッチファイルの検出結果をすべて収集し、元の分類とすべての詳細フィールドを維持したまま、1 つのリストにまとめます。
  3. エグゼクティブサマリー用に、すべてのバッチの合計数を集計します。
  4. 次の形式を使用して、統合レポートを sast/missingauth-results.md に書き込みます。
# Missing Auth/Authz Analysis Results: [Project Name]

## Executive Summary
- Endpoints analyzed: [total across all batches]
- Vulnerable: [N]
- Likely Vulnerable: [N]
- Not Vulnerable: [N]
- Needs Manual Review: [N]

## Findings

[All findings from all batches, grouped by classification:
 VULNERABLE first, then LIKELY VULNERABLE, then NEEDS MANUAL REVIEW, then NOT VULNERABLE.
 Preserve every field from the batch results exactly as written.]
  1. sast/missingauth-results.md の書き込み後、すべての中間ファイルを削除します:sast/missingauth-recon.md および sast/missingauth-batch-*.md。

重要な注意事項

  • sast/architecture.md を読み込み、その内容をすべてのサブエージェントにコンテキストとして渡します。
  • フェーズ 2 はフェーズ 1 の完了後に実行する必要があります。フェーズ 2 は偵察結果に依存します。
  • フェーズ 3 はすべてのフェーズ 2 のバッチ完了後に実行する必要があります。フェーズ 3 はすべてのバッチ出力に依存します。
  • バッチサイズはサブエージェント 1 つあたりエンドポイント 3 件です。エンドポイントの合計が 1~3 件の場合は、サブエージェントを 1 つ使用します。10 件の場合は、サブエージェントを 4 つ使用します(3+3+3+1)。
  • すべてのバッチサブエージェントを並列で起動します。順番に実行しないでください。
  • 各バッチサブエージェントに渡すのは、偵察ファイル全体ではなく、割り当てられたエンドポイントのテキストのみです。これにより、各サブエージェントのコンテキストを小さく、焦点を絞ったものにできます。
  • 垂直権限昇格(ユーザー → 管理者)と未認証アクセスに焦点を当てます。水平権限昇格(ユーザー A がユーザー B のリソースにアクセスすること)は、IDOR スキルで扱います。
  • 認証(自分が名乗る本人であること)と認可(その操作を許可されていること)は別の問題です。両方を確認してください。
  • ミドルウェアの順序は重要です。ルートハンドラーの後に登録されたミドルウェアは、そのルートを保護しません。
  • ある HTTP メソッド(例:DELETE)に認証またはロールチェックがなく、GET が保護されている場合でも、それは完全な脆弱性です。
  • 判断に迷った場合は、「脆弱性なし」ではなく「手動レビューが必要」に分類してください。セキュリティ評価では、偽陰性は偽陽性より深刻です。
  • ルートグループに注意してください。use('/admin', adminRouter) パターンは adminRouter 内のすべてのルートを保護しますが、そのグループの外にマウントされたルートは保護されません。
  • 中間ファイルをクリーンアップします。最終的な sast/missingauth-results.md の書き込み後に、sast/missingauth-recon.md とすべての sast/missingauth-batch-*.md ファイルを削除します。

コメント