LoginSignup
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@leor89917(BNR-Nam)in株式会社BinaryTech | 既存システムにAIを、未来の標準に。

非機能テストのすべて [第5回]: OWASP Top 10とは？

Posted at

OWASP Top 10を活用した実践的セキュリティテスト：クラウドネイティブ時代の脆弱性対策

1. はじめに：忘れられないセキュリティインシデント

昨年、私たちが開発したWebアプリケーションに深刻なセキュリティインシデントが発生しました。とある脆弱性を悪用され、顧客データが流出するという重大な事故です。幸い、早期に発見し、迅速な対応で大事には至りませんでしたが、根本的な原因を調査した結果、以下の事実が判明しました。

  • 開発チームが「OWASP Top 10」の存在を知っていたが、具体的な対策方法を理解していなかった
  • 自動化されたセキュリティテストがCI/CDパイプラインに組み込まれていなかった
  • クラウド環境の設定ミス（S3バケットの公開設定など）が脆弱性につながっていた

この経験は、セキュリティ対策が「知識」だけでなく「実践的なテストと継続的な確認」によって初めて成立することを痛感させられました。本記事では、Webアプリケーションの脆弱性に関する権威あるガイドである「OWASP Top 10」を解説し、具体的なテスト方法と対策をコードとともに紹介します。

2. OWASP Top 10とは？ なぜ重要なのか？

OWASP（Open Web Application Security Project）は、Webアプリケーションのセキュリティに関するオープンソースコミュニティです。その中で最も有名なのが「OWASP Top 10」です。これは、現代のWebアプリケーションにおいて発生頻度が高く、影響度の大きい10種類の重大な脆弱性をランキング形式でまとめたものです。

なぜOWASP Top 10が重要なのか？

  • 共通言語: 開発者、テスト担当者、経営者間でセキュリティリスクについて話し合うための共通の土壌を提供します。
  • 優先順位: 無数にある脆弱性の中から、まず何に対処すべきかの優先順位を決定するのに役立ちます。
  • 教育ツール: セキュリティ意識を高め、安全なコーディング practicesを学ぶための優れた教材となります。

OWASP Top 10 2021の概要

最新版（2021）のトップ5は以下の通りです。

  1. Broken Access Control (アクセス制御の不備)
  2. Cryptographic Failures (暗号化の失敗) - 旧：Sensitive Data Exposure
  3. Injection (インジェクション)
  4. Insecure Design (不安全な設計) - 新カテゴリ
  5. Security Misconfiguration (セキュリティ設定の誤り)

3. 実践：主要な脆弱性のテストと対策方法

ここからは、特に頻出する脆弱性に焦点を当て、具体的なテストシナリオと対策コードを見ていきましょう。

3-1. A01:2021 - Broken Access Control (アクセス制御の不備)

問題: 一般ユーザーが管理者機能にアクセスできる、または他のユーザーのデータを閲覧できてしまう。

テスト例 (Python + pytestでテスト自動化)
管理者ページに一般ユーザー権限でアクセスし、アクセスが拒否されるかをテストします。

# test_access_control.py
import requests

def test_admin_access_with_user_role():
    # テスト用の一般ユーザーでログインし、セッションを取得
    login_url = "https://api.binary-shop.com/auth/login"
    user_credentials = {"email": "user@example.com", "password": "user_pass"}
    response = requests.post(login_url, json=user_credentials)
    user_session_cookie = response.cookies.get('session_id')

    # 取得したセッションを使って管理者APIにアクセス試行
    admin_url = "https://api.binary-shop.com/admin/users"
    cookies = {'session_id': user_session_cookie}
    admin_response = requests.get(admin_url, cookies=cookies)

    # アクセスが拒否されることを確認 (ステータスコード 403 Forbidden)
    assert admin_response.status_code == 403, f"一般ユーザーが管理者機能にアクセス可能です。ステータスコード: {admin_response.status_code}"

# 実行コマンド: pytest test_access_control.py -v

対策 (バックエンドでの認可チェック)

  • 根本対策: フロントエンドのUI制御だけでなく、バックエンドAPIのエンドポイント毎に必ずロールベースのアクセス制御（RBAC）を実装する。

  • 例: Node.js (Express) middleware

    // middleware/authz.js
const authorize = (allowedRoles = []) => {
    return (req, res, next) => {
        const userRole = req.user.role; // 認証ミドルウェアから付与されたロール
        if (!allowedRoles.includes(userRole)) {
            return res.status(403).json({ error: 'アクセス権限がありません' });
        }
        next();
    };
};

module.exports = authorize;

    // routes/admin.js
const express = require('express');
const authorize = require('../middleware/authz');
const router = express.Router();

// 'admin'ロールのみがアクセス可能なエンドポイント
router.get('/users', authorize(['admin']), (req, res) => {
    // 管理者ロジック...
    res.json({ users: [] });
});

module.exports = router;

3-2. A03:2021 - Injection (インジェクション)

問題: ユーザー入力がコードやコマンドとして解釈・実行されてしまう（SQLインジェクションなど）。

テスト例 (SQLインジェクションの検出)
手動またはツール（sqlmap）で以下のような入力を試します。
https://api.binary-shop.com/products?category=Gadgets' OR '1'='1

対策 (プリペアドステートメントの利用)

  • 根本対策: ユーザー入力をSQL文の文字列連結に絶対に使わない。必ずプリペアドステートメントまたはパラメータ化されたクエリを使用する。

  • 例: Python (SQLAlchemy)

    # ❌ 悪い例: 文字列連結は危険
query = f"SELECT * FROM users WHERE email = '{email}';"

# ✅ 良い例: プリペアドステートメントを使用
from sqlalchemy import text
stmt = text("SELECT * FROM users WHERE email = :email")
result = db.session.execute(stmt, {'email': email}) # パラメータは安全にエスケープされる

  • 例: Node.js (Prisma ORM)

    // ✅ Prismaはデフォルトでプリペアドステートメントを使用する
const user = await prisma.user.findUnique({
    where: {
        email: email, // ユーザー入力は自動的にエスケープされる
    },
});

3-3. A05:2021 - Security Misconfiguration (セキュリティ設定の誤り)

問題: デフォルトのパスワードや設定のまま、不要なポートやサービスが公開されているなど。

テストと対策 (Docker/Helmでの環境設定)
本番環境と開発環境で異なる設定ファイルを使用し、デフォルトを安全な状態にします。

  • 例: Dockerfile

    # ❌ 悪い例: ルートユーザーでアプリを実行する
CMD ["node", "app.js"]

# ✅ 良い例: 非特権ユーザーを作成して切り替える
RUN addgroup -g 1001 -S appgroup && adduser -u 1001 -S appuser -G appgroup
USER appuser # ここでユーザーを切り替える
CMD ["node", "app.js"]

  • 例: Helm Chart (values.production.yaml)

    # 本番環境用の厳格な設定
securityContext:
  runAsNonRoot: true
  runAsUser: 1001
  allowPrivilegeEscalation: false
  capabilities:
    drop:
      - ALL
service:
  type: ClusterIP # LoadBalancerではなく、内部向けのServiceにする
ingress:
  enabled: true
  # TLS証明書の設定を必ず行う
  tls:
    - hosts:
        - binary-shop.com
      secretName: binary-shop-tls

4. 実践Tipsとよくある落とし穴

  • Tip 1: ツールを活用した自動スキャンの導入

    • 静的アプリケーションセキュリティテスト (SAST): ソースコードを静的に解析し、脆弱性のパターンを検出する（例: SonarQube, GitHub Code Scanning）。
    • 動的アプリケーションセキュリティテスト (DAST): 動作しているアプリケーションに対して外部からテストを実行し、脆弱性を検出する（例: OWASP ZAP, trivy）。
    • 落とし穴: ツールの結果を盲信する。ツールはあくまで補助であり、最終的には人の目での確認が必要。

  • Tip 2: 「Shift-Left」で早期にテストを行う

    • 落とし穴: リリース直前のステージでしかセキュリティテストを行わない。
    • 対策: 開発者のローカル環境やCIパイプラインの早い段階で簡単なセキュリティテスト（例: npm audit, trivy fs .）を実行し、問題を早期発見する。

  • Tip 3: 依存パッケージの脆弱性管理を徹底する

    • 落とし穴: 使用しているライブラリのバージョンが古く、既知の脆弱性を含んでいる。
    • 対策: dependabot (GitHub) や renovatebot などを用いて、依存パッケージを自動的に最新かつ安全なバージョンに更新する。

5. 応用：CI/CDパイプラインへの組込みと継続的セキュリティ

理想は、セキュリティテストを開発プロセスに完全に統合し、DevSecOpsを実践することです。

# .github/workflows/ci.yml (抜粋)
name: CI Pipeline
on: [push, pull_request]

jobs:
  security-scan:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: SAST with SonarCloud
        uses: SonarSource/sonarcloud-github-action@master
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}

      - name: SCA (Software Composition Analysis) scan
        run: npm audit --audit-level=high

      - name: Container scan
        uses: aquasecurity/trivy-action@master
        with:
          image-type: 'dockerfile'
          image-ref: 'Dockerfile'
          format: 'sarif'
          output: 'trivy-results.sarif'

      - name: Upload Trivy scan results to GitHub
        uses: github/codeql-action/upload-sarif@v2
        with:
          sarif_file: 'trivy-results.sarif'

6. まとめ：セキュリティはプロセスである

OWASP Top 10は、セキュリティ対策の「チェックリスト」ではなく、安全なソフトウェアを構築するための「考え方のフレームワーク」です。

  • メリット

    • セキュリティリスクに対する認識を高め、組織的な対策を促進する。
    • 具体的な脆弱性とその対策方法を学ぶことができる。
    • 開発ライフサイクル全体を通じてセキュリティを「左寄せ（Shift-Left）」できる。

  • デメリット/課題

    • 全ての項目に対応するには時間とコストがかかる。
    • ツールや知識の導入には学習コストが伴う。
    • OWASP Top 10以外にも考慮すべき脆弱性は無数に存在する。

「完璧」を最初から目指す必要はありません。まずは自社のアプリケーションで最もリスクの高い項目（例えば、アクセス制御とインジェクション）から対策とテストを始めてみてください。その一歩が、より強固で信頼できるアプリケーションへの第一歩となります。

本記事が、皆さんのセキュリティテスト実践の一助となれば幸いです。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?