おい、みんな。今日も一日お疲れさん。セキュリティチーフの俺だ。

最近、OWASP Top 10の2021年版で「Insecure Design」（安全でない設計）が新たにランクインしたのを知ってるか？「設計」という言葉が入っているところがミソだ。これは単なる実装バグじゃなくて、もっと根深い、システムの思想に関わる問題なんだ。

今回は、この「Insecure Design」に真正面から切り込んでいく。実装前の設計段階でどうやって脆弱性の芽を摘むか、そして攻撃者がどうやってビジネスロジックの欠陥を突いてくるか。現場で泥水をすすってきた俺の知見と、具体的なコードを交えて、とことん実践的に解説するぜ。

—

Insecure Designはなぜ生まれたのか？その盲点と本質

「脆弱性」と聞いて、お前らの頭に浮かぶのはなんだ？ SQLインジェクション、XSS、CSRF、ファイルアップロードの不備……そう、これらは確かに実装段階で発生する「バグ」だ。そして、静的・動的解析ツールやWAF、定期的な脆弱性診断でそれなりに検出・対処ができる。

でもな、Insecure Designはそういう次元の話じゃない。

例えば、

「プレミアム会員限定機能」なのに、URLパラメータをちょっと弄るだけで一般会員でも使えちゃった。
「管理者のみ実行可能」なAPIなのに、認証さえ通れば一般ユーザーでも叩けちゃった。
「本人確認のための多段階認証」なのに、途中のステップをスキップできちゃった。

こういうケースは、コード上のちょっとしたミスで起こることももちろんある。だが、根本的な原因は「この機能がどう使われるべきか」という設計思想、つまりビジネスロジックそのものにセキュリティの観点が欠けていたことにあるんだ。

CI/CDパイプラインで自動脆弱性スキャンを回しても、こんな「設計の甘さ」はまず見つからない。なぜなら、ツールは「実装されたコードがセキュリティベストプラクティスに沿っているか」はチェックできても、「そもそもこの機能自体が危険な設計になっていないか」までは判断できないからだ。

攻撃者は、この「設計の盲点」を突いてくる。彼らはシステムのエラーメッセージや挙動、APIのレスポンスを注意深く観察し、ビジネスロジックの裏をかく方法を探る。これが、Insecure Designの本質なんだ。

脅威モデリングの真髄：設計段階で攻撃者の視点を持つ

じゃあ、どうすればいいか？答えはシンプルだ。「実装に入る前に、攻撃者の視点に立ってシステムの設計を評価する」。これが「脅威モデリング」だ。

「そんな面倒なこと、開発サイクルに組み込めないよ！」って声が聞こえてきそうだな。だが、開発の初期段階でセキュリティの欠陥を見つけることが、後になって何十倍ものコストをかけて修正するよりもはるかに効率的だ。

脅威モデリングは「ホワイトボードとペン」から始まる

脅威モデリングには色々な手法があるが、俺が現場で一番頼りにしているのは「STRIDE」だ。これはマイクロソフトが提唱したフレームワークで、以下の6つのカテゴリから脅威を洗い出す。

Spoofing (なりすまし)
Tampering (改ざん)
Repudiation (否認)
Information Disclosure (情報漏洩)
Denial of Service (サービス妨害)
Elevation of Privilege (権限昇格)

このSTRIDEを、システムの設計図やデータフローダイアグラム（DFD）と突き合わせながら、チームで徹底的に議論するんだ。

実務での脅威モデリングプロセス

1. システムスコープとコンポーネントの特定: どんなシステムか、どんな機能があるか、どのコンポーネント（Webサーバー、DB、API、外部サービスなど）で構成されているかを明確にする。
2. データフローの洗い出し: ユーザーがどんなデータを入力し、それがシステム内部でどう流れ、どこに保存され、どう処理されるかを絵に描く。これが一番重要だ。
3. 信頼境界線の定義: どこからどこまでが「信頼できる領域」で、どこからが「信頼できない領域」か？ユーザー入力、外部API、異なるマイクロサービス間など、データの受け渡し地点には必ず境界線がある。
4. STRIDEによる脅威の特定: 各コンポーネント、各データフロー、各信頼境界線に対して「ここでSTRIDEのどの脅威が発生しうるか？」を議論する。

「このユーザー入力は改ざんされたらどうなる？」(Tampering)
「この通信は盗聴されたらどうなる？」(Information Disclosure)
「このAPIは不正なユーザーから叩かれたら？」(Spoofing, Elevation of Privilege)
「この処理は大量のリクエストで停止しないか？」(Denial of Service)
「このログは誰がいつ何をしたか、後で追跡できるか？」(Repudiation)

5. 脅威の優先順位付けと緩和策の検討: 特定した脅威に対して、発生可能性と影響度を評価し、優先順位をつける。そして、具体的な防御策（認証・認可の強化、入力値検証、暗号化、ログ記録など）を設計に落とし込む。

脅威モデリングは、決して形式的なドキュメント作成作業じゃない。ホワイトボードを囲んで「もし俺が悪意のあるハッカーだったら、ここをどう攻めるか？」って、みんなでワイワイ、ガヤガヤ議論することに意味がある。その泥臭いプロセスの中で、隠れた設計の甘さが炙り出されるんだ。

ビジネスロジックの欠陥を狙う攻撃と防御

ここからは、具体的な攻撃シナリオと、それを完全に防御するための実用的なコード例や設定を交えて解説していく。どれも俺が現場で見てきた、あるいは防いできた生々しい事例だ。

シナリオ1: 認可ロジックの不備（水平・垂直権限昇格）

これはInsecure Designの代表格だ。「あるユーザーだけがアクセスできるべき情報」や「管理者だけが実行できるべき操作」が、ちょっとした手間で突破されてしまうケースだ。

攻撃例 (PoC): ユーザーIDの書き換え

例えば、`https://example.com/profile?id=123` のようにURLパラメータでユーザーIDを渡すような設計になっているとする。攻撃者は `id=124` に書き換えて、他人のプロフィール情報を閲覧しようと試みる。あるいは、APIで `{“user_id”: 123}` のようなJSONを送り、`user_id` を書き換えて他人のデータを更新しようとする。

もっと巧妙なケースでは、`GET /api/v1/admin/users/all` のような管理者専用APIに、一般ユーザーが直接アクセスしてみる。

防御策: アクセスリソースごとに厳格な認可チェック

「ログインしているから大丈夫」じゃない。「ログインしているこのユーザーが、このリソースにアクセスする権限があるか」を、アクセスするたびに、すべてのリソースと操作に対して確認するんだ。

Python (Flask) での例:

from flask import Flask, request, jsonify, abort, session

app = Flask(__name__)
app.secret_key = ‘your_super_secret_key’ # 本番環境では環境変数などから取得

ダミーデータ
USERS = {
1: {‘username’: ‘alice’, ‘role’: ‘user’},
2: {‘username’: ‘bob’, ‘role’: ‘user’},
3: {‘username’: ‘admin’, ‘role’: ‘admin’}
}
USER_PROFILES = {
1: {‘name’: ‘Alice Smith’, ‘email’: ‘alice@example.com’},
2: {‘name’: ‘Bob Johnson’, ‘email’: ‘bob@example.com’},
3: {‘name’: ‘Admin User’, ‘email’: ‘admin@example.com’}
}

ログインダミー
@app.route(‘/login’, methods=[‘POST’])
def login():
username = request.json.get(‘username’)
password = request.json.get(‘password’) # パスワードは実際にはハッシュ化して比較

for user_id, user_info in USERS.items():
if user_info[‘username’] == username:
session[‘user_id’] = user_id
session[‘role’] = user_info[‘role’]
return jsonify({‘message’: ‘Logged in successfully’, ‘user_id’: user_id}), 200
return jsonify({‘message’: ‘Invalid credentials’}), 401

ログアウトダミー
@app.route(‘/logout’)
def logout():
session.pop(‘user_id’, None)
session.pop(‘role’, None)
return jsonify({‘message’: ‘Logged out successfully’}), 200

ユーザープロフィール取得エンドポイント
@app.route(‘/profile/‘, methods=[‘GET’])
def get_profile(user_id):
# 1. 認証チェック: ログインしているか？
if ‘user_id’ not in session:
abort(401, description=”Authentication required”) # 未認証

# 2. 認可チェック: ログインユーザーがこのプロフィールにアクセスする権限があるか？
# 水平権限昇格の防御
if session[‘user_id’] != user_id and session[‘role’] != ‘admin’:
abort(403, description=”Unauthorized access to this profile”) # 権限なし

profile = USER_PROFILES.get(user_id)
if not profile:
abort(404, description=”Profile not found”)

return jsonify(profile), 200

管理者のみアクセス可能なエンドポイント
@app.route(‘/admin/users’, methods=[‘GET’])
def list_all_users():
# 1. 認証チェック
if ‘user_id’ not in session:
abort(401, description=”Authentication required”)

# 2. 認可チェック: 管理者ロールか？
# 垂直権限昇格の防御
if session[‘role’] != ‘admin’:
abort(403, description=”Administrator access required”)

return jsonify(USERS), 200

if __name__ == ‘__main__’:
app.run(debug=True)

PHP での例 (擬似コード):

[‘name’ => ‘Alice Smith’, ‘email’ => ‘alice@example.com’],
2 => [‘name’ => ‘Bob Johnson’, ‘email’ => ‘bob@example.com’],
3 => [‘name’ => ‘Admin User’, ‘email’ => ‘admin@example.com’]
];
$profile = $profiles[$targetUserId] ?? null;

if ($profile) {
echo json_encode($profile);
} else {
header(‘HTTP/1.1 404 Not Found’);
echo ‘Profile not found.’;
}
}

// 管理者専用機能
if (isset($_GET[‘path’]) && $_GET[‘path’] === ‘admin_users’) {
// 認可チェックを呼び出し: 管理者ロールが必要
authorize(0, ‘admin’); // ユーザーIDは関係ないので0、ロールは’admin’を指定

// ここから管理者のみが閲覧できるユーザー一覧を取得するロジック
$users = [
1 => [‘username’ => ‘alice’, ‘role’ => ‘user’],
2 => [‘username’ => ‘bob’, ‘role’ => ‘user’],
3 => [‘username’ => ‘admin’, ‘role’ => ‘admin’]
];
echo json_encode($users);
}

// その他のエンドポイントやログイン・ログアウト処理…
?>

ポイント:

常に認可チェック: URLパラメータやPOSTデータで渡されたIDを鵜呑みにせず、現在ログインしているユーザーがそのリソースにアクセスする権限を持っているかを必ず確認する。
フレームワークの活用: LaravelのGates/Policies、DjangoのPermissions、Spring Securityなど、現代的なフレームワークには強力な認可機能が備わっている。これらを正しく理解し、活用することが重要だ。
最小権限の原則: ユーザーにはその役割を遂行する上で必要最小限の権限のみを与える。

シナリオ2: ワークフローの迂回 / 多段階プロセスのスキップ

オンラインストアでの購入フローや、アカウント登録時のメール認証など、複数のステップを経て完了するプロセスにおいて、攻撃者が途中のステップを飛ばして最終段階に直接アクセスしようとするケースだ。

攻撃例 (PoC): 決済処理のスキップ

ECサイトで商品をカートに入れ、「配送先入力」→「支払い情報入力」→「最終確認」→「注文完了」というフローがあるとする。攻撃者は、「配送先入力」と「支払い情報入力」を済ませず、直接「注文完了」のAPIを叩こうとする。

もっと厄介なのは、MFA（多要素認証）のステップをスキップされるケースだ。例えば、パスワード入力後にSMS認証コード入力画面が表示されるが、攻撃者はSMS認証のAPIを叩かずに、直接ログイン後の画面に遷移するAPIを叩く、といった具合だ。

防御策: セッション管理と状態遷移の厳格化

システムが「現在どのステップにいるか」を正確に把握し、不正なステップ遷移を許さない設計が必須だ。

Python (Flask) での例:

from flask import Flask, request, jsonify, abort, session, redirect, url_for

app = Flask(__name__)
app.secret_key = ‘your_super_secret_key’ # 本番環境では環境変数などから取得

ダミーデータ
ORDERS = {}
ORDER_ID_COUNTER = 1

注文プロセス用の状態管理
実際のアプリケーションではDBなどに保存することが多い
PENDING_ORDERS = {} # key: session_id, value: {‘step’: ‘cart’|’shipping’|’payment’|’confirm’}

ダミーログイン (簡略化)
@app.route(‘/login_mfa_dummy’, methods=[‘POST’])
def login_mfa_dummy():
username = request.json.get(‘username’)
password = request.json.get(‘password’)
if username == ‘test’ and password == ‘password’:
session[‘user_id’] = 1 # ダミーユーザーID
session[‘mfa_pending’] = True # MFAが必要な状態
return jsonify({‘message’: ‘MFA required’, ‘next_step’: ‘/mfa_verify’}), 200
return jsonify({‘message’: ‘Invalid credentials’}), 401

MFA検証ステップ
@app.route(‘/mfa_verify’, methods=[‘POST’])
def mfa_verify():
if ‘user_id’ not in session or not session.get(‘mfa_pending’):
abort(400, description=”Invalid state for MFA verification”)

# 実際にはSMSコードなどの検証ロジック
mfa_code = request.json.get(‘code’)
if mfa_code == ‘123456’: # ダミーコード
session.pop(‘mfa_pending’, None) # MFA完了
session[‘logged_in’] = True # ログイン完了
return jsonify({‘message’: ‘MFA successful’, ‘next_step’: ‘/dashboard’}), 200
return jsonify({‘message’: ‘Invalid MFA code’}), 400

MFAスキップを狙うダッシュボードへの直接アクセス防御
@app.route(‘/dashboard’)
def dashboard():
if not session.get(‘logged_in’):
abort(401, description=”Authentication required”)
return jsonify({‘message’: ‘Welcome to the dashboard!’}), 200

— 注文処理の例 —

@app.route(‘/add_to_cart’, methods=[‘POST’])
def add_to_cart():
# … カート追加ロジック …
session[‘order_step’] = ‘cart’
return jsonify({‘message’: ‘Item added to cart’, ‘next_step’: ‘/shipping’}), 200

@app.route(‘/shipping’, methods=[‘POST’])
def enter_shipping():
if session.get(‘order_step’) != ‘cart’:
abort(400, description=”Invalid order step. Please add items to cart first.”)
# … 配送先入力ロジック …
session[‘order_step’] = ‘payment’
return jsonify({‘message’: ‘Shipping info saved’, ‘next_step’: ‘/payment’}), 200

@app.route(‘/payment’, methods=[‘POST’])
def enter_payment():
if session.get(‘order_step’) != ‘payment’:
abort(400, description=”Invalid order step. Please enter shipping info first.”)
# … 支払い情報入力ロジック …
session[‘order_step’] = ‘confirm’
return jsonify({‘message’: ‘Payment info saved’, ‘next_step’: ‘/confirm’}), 200

@app.route(‘/confirm’, methods=[‘GET’])
def confirm_order():
if session.get(‘order_step’) != ‘confirm’:
abort(400, description=”Invalid order step. Please complete payment first.”)
# … 注文内容確認表示ロジック …
return jsonify({‘message’: ‘Please confirm your order’, ‘next_step’: ‘/place_order’}), 200

@app.route(‘/place_order’, methods=[‘POST’])
def place_order():
global ORDER_ID_COUNTER
if session.get(‘order_step’) != ‘confirm’:
abort(400, description=”Invalid order step. Please confirm your order first.”)

order_id = ORDER_ID_COUNTER
ORDER_ID_COUNTER += 1
ORDERS[order_id] = {‘user_id’: session.get(‘user_id’), ‘status’: ‘completed’, ‘items’: ‘dummy_items’}
session.pop(‘order_step’, None) # 注文完了でステップをクリア
return jsonify({‘message’: ‘Order placed successfully’, ‘order_id’: order_id}), 200

if __name__ == ‘__main__’:
app.run(debug=True)

PHP での例 (擬似コード):

‘Item added to cart’, ‘next_step’ => ‘shipping’]);
break;

case ‘shipping’:
// 配送先入力処理
if (!canAdvanceToStep(‘shipping’) || getCurrentOrderStep() !== ‘cart’) {
header(‘HTTP/1.1 400 Bad Request’);
die(‘Invalid order step. Please add items to cart first.’);
}
$_SESSION[‘order_step’] = ‘payment’;
echo json_encode([‘message’ => ‘Shipping info saved’, ‘next_step’ => ‘payment’]);
break;

case ‘payment’:
// 支払い情報入力処理
if (!canAdvanceToStep(‘payment’) || getCurrentOrderStep() !== ‘payment’) {
header(‘HTTP/1.1 400 Bad Request’);
die(‘Invalid order step. Please enter shipping info first.’);
}
$_SESSION[‘order_step’] = ‘confirm’;
echo json_encode([‘message’ => ‘Payment info saved’, ‘next_step’ => ‘confirm’]);
break;

case ‘confirm’:
// 注文内容確認表示
if (!canAdvanceToStep(‘confirm’) || getCurrentOrderStep() !== ‘confirm’) {
header(‘HTTP/1.1 400 Bad Request’);
die(‘Invalid order step. Please complete payment first.’);
}
echo json_encode([‘message’ => ‘Please confirm your order’, ‘next_step’ => ‘place_order’]);
break;

case ‘place_order’:
// 注文完了処理
if (!canAdvanceToStep(‘completed’) || getCurrentOrderStep() !== ‘confirm’) {
header(‘HTTP/1.1 400 Bad Request’);
die(‘Invalid order step. Please confirm your order first.’);
}
// 注文DBへの書き込みなど
unset($_SESSION[‘order_step’]); // 注文完了でステップをクリア
echo json_encode([‘message’ => ‘Order placed successfully’, ‘order_id’ => 123]);
break;

case ‘mfa_verify’:
// MFA検証処理
if (!isset($_SESSION[‘user_id’]) || !isset($_SESSION[‘mfa_pending’]) || $_SESSION[‘mfa_pending’] !== true) {
header(‘HTTP/1.1 400 Bad Request’);
die(‘Invalid state for MFA verification.’);
}
// コード検証ロジック
if ($_POST[‘code’] === ‘123456’) { // ダミーコード
unset($_SESSION[‘mfa_pending’]);
$_SESSION[‘logged_in’] = true;
echo json_encode([‘message’ => ‘MFA successful’, ‘next_step’ => ‘dashboard’]);
} else {
header(‘HTTP/1.1 400 Bad Request’);
die(‘Invalid MFA code.’);
}
break;

case ‘dashboard’:
if (!isset($_SESSION[‘logged_in’]) || $_SESSION[‘logged_in’] !== true) {
header(‘HTTP/1.1 401 Unauthorized’);
die(‘Authentication required.’);
}
echo json_encode([‘message’ => ‘Welcome to the dashboard!’]);
break;

default:
header(‘HTTP/1.1 404 Not Found’);
echo ‘Not Found’;
break;
}
}
?>

ポイント:

セッションで状態管理: ユーザーの現在のプロセス状態をセッション変数やデータベースで厳密に管理する。
状態遷移の検証: 次のステップに進む前に、必ず現在のステップが正しいか、そして要求されたステップが次の有効なステップであるかを検証する。
バックエンドでの徹底: クライアントサイド（JavaScript）での制御は、あくまでユーザー体験のためのものであり、セキュリティ制御の主体は必ずバックエンドで行う。

シナリオ3: 過剰な情報開示 / 不適切なエラーハンドリング

攻撃者は、システムが出力するエラーメッセージやデバッグ情報、HTTPレスポンスヘッダなどから、システムの内部構造や脆弱性のヒントを得ようとする。これは直接的な攻撃ではないが、次の攻撃ステップのための重要な情報収集源となる。

攻撃例 (PoC): スタックトレースの漏洩

本番環境で予期せぬエラーが発生した際、詳細なスタックトレースやデータベース接続情報、APIキーなどの機密情報がWebページ上にそのまま表示されてしまう。攻撃者はこれを見て、使用されているフレームワークのバージョン、DBの種類、内部ネットワーク構成などを推測し、次の攻撃（特定の脆弱性を持つバージョンを狙う、DBに直接アクセスを試みるなど）の足がかりにする。

防御策: エラーメッセージの抽象化とログへの出力

ユーザーに見せる情報と、開発者が見るべき情報を明確に分ける。

Python (Flask) での例:

from flask import Flask, jsonify, render_template

app = Flask(__name__)

エラーハンドリングのカスタマイズ
@app.errorhandler(404)
def page_not_found(e):
# ユーザーには一般的なメッセージを表示
return render_template(‘404.html’), 404

@app.errorhandler(500)
def internal_server_error(e):
# 本番環境では詳細なエラーメッセージをユーザーに表示しない
# デバッグ情報やスタックトレースはログに出力する
app.logger.error(f”Internal Server Error: {e}”, exc_info=True) # exc_info=Trueでスタックトレースをログに出力
return render_template(‘500.html’), 500

@app.route(‘/’)
def index():
return “Welcome!”

@app.route(‘/buggy’)
def buggy_route():
# 意図的にエラーを発生させる
1 / 0
return “This won’t be reached.”

if __name__ == ‘__main__’:
# デバッグモードは本番環境では絶対にFalseに設定する
# debug=True だとスタックトレースがブラウザに表示される
app.run(debug=False)

`templates/404.html`:

ページが見つかりません – 404

404 Not Found

お探しのページは見つかりませんでした。

トップページに戻る

`templates/500.html`:

サーバーエラー – 500

500 Internal Server Error

現在、サーバーに問題が発生しています。しばらくしてから再度お試しください。

トップページに戻る

Nginx の設定例:

server {
listen 80;
server_name example.com;

root /var/www/html;
index index.html index.htm;

# エラーページをカスタム設定
error_page 404 /404.html;
error_page 500 502 503 504 /50x.html;

location = /404.html {
internal; # 外部から直接アクセスさせない
}

location = /50x.html {
internal; # 外部から直接アクセスさせない
}

location / {
try_files $uri $uri/ =404;
# PHPなどのアプリケーションサーバーへのプロキシ設定
# proxy_pass http://backend_app_server;
}

# サーバーのバージョン情報を隠す
server_tokens off;
}

ポイント:

汎用的なエラーメッセージ: ユーザーには「エラーが発生しました」のような一般的なメッセージのみを表示し、具体的なエラー内容やスタックトレースは絶対に表示しない。
ログへの出力: 詳細なエラー情報は、適切な権限管理がされた安全なログシステムにのみ出力する。機密情報（パスワード、APIキーなど）はログにも出力しないよう注意する。
HTTPヘッダの最小化: `Server` ヘッダなど、Webサーバーのバージョン情報を開示する設定は無効化する（Nginxの `server_tokens off;` など）。
デバッグモードの無効化: 本番環境ではフレームワークやサーバーのデバッグモードを必ず無効にする。

シナリオ4: レートリミットの欠如

ログイン試行回数、API呼び出し回数、パスワードリセット要求回数などに制限がないと、ブルートフォース攻撃やアカウント列挙、API乱用などの攻撃を許してしまう。

攻撃例 (PoC): ブルートフォース攻撃によるパスワード特定

攻撃者は、大量のパスワード候補を自動で試行し、アカウントへのログインを試みる。もしログイン失敗回数に制限がなければ、いつか正しいパスワードにたどり着く可能性がある。パスワードリセット機能でも同様に、大量のリクエストを送って有効なユーザー名を特定したり、リセットトークンを推測したりする試みが行われる。

防御策: IPアドレス、ユーザーID、セッションベースでのレートリミット

「何回失敗したらロックアウトする」「1秒間に何回までリクエストを許可する」といった制限を設ける。

Python (Flask) での例 (Redisを使ったレートリミット):

from flask import Flask, request, jsonify, abort
from redis import Redis
from functools import wraps
import time

app = Flask(__name__)
redis_client = Redis(host=’localhost’, port=6379, db=0) # Redis接続設定

レートリミットデコレータ
def rate_limit(key_prefix, limit, period):
def decorator(f):
@wraps(f)
def wrapper(args, kwargs):
# レートリミットのキーを生成 (IPアドレスとエンドポイントを組み合わせるなど)
# 実際には、ユーザーIDやセッションIDも組み合わせることが多い
key = f”{key_prefix}:{request.remote_addr}:{request.path}”

# RedisのINCRコマンドでカウントアップし、有効期限を設定
# INCRBY と EXPIRE をアトミックに実行するためにパイプラインを使うか、Luaスクリプトを使うとより安全
count = redis_client.incr(key)
if count == 1:
redis_client.expire(key, period)

if count > limit:
# ログに記録するべき重要なイベント
app.logger.warning(f”Rate limit exceeded for {request.remote_addr} on {request.path}”)
abort(429, description=f”Too many requests. Please try again after {period} seconds.”)
return f(args, kwargs)
return wrapper
return decorator

ログインエンドポイントにレートリミットを適用
@app.route(‘/login’, methods=[‘POST’])
@rate_limit(key_prefix=’login_attempts’, limit=5, period=60) # 1分間に5回まで
def login():
username = request.json.get(‘username’)
password = request.json.get(‘password’)

# 実際の認証ロジック
if username == ‘test_user’ and password == ‘correct_password’:
# 成功したらレートリミットカウンタをリセットすることも検討
# redis_client.delete(f”login_attempts:{request.remote_addr}:{request.path}”)
return jsonify({‘message’: ‘Login successful’}), 200
else:
# ログイン失敗時にアカウントロックアウト処理などを実装
# ユーザーIDごとの失敗回数をカウントし、一定回数でアカウントをロックするなど
return jsonify({‘message’: ‘Invalid credentials’}), 401

APIエンドポイントにもレートリミット
@app.route(‘/api/data’)
@rate_limit(key_prefix=’api_access’, limit=100, period=3600) # 1時間に100回まで
def get_data():
return jsonify({‘data’: ‘some_data’})

if __name__ == ‘__main__’:
app.run(debug=True)

Nginx の設定例:

httpブロック内で定義
http {
# ログインエンドポイントのレートリミット (1分間に5回まで)
# key: クライアントIPアドレス
# zone: 共有メモリゾーンの名前とサイズ
# rate: 1秒あたりのリクエスト数 (r/s) または1分あたりのリクエスト数 (r/m)
limit_req_zone $binary_remote_addr zone=login_limiter:10m rate=5r/m;

# APIエンドポイントのレートリミット (1時間に100回まで)
limit_req_zone $binary_remote_addr zone=api_limiter:10m rate=100r/h;

server {
listen 80;
server_name example.com;

# ログインパスへのレートリミット適用
location /login {
limit_req zone=login_limiter burst=10 nodelay; # burst: 許容するバーストリクエスト数, nodelay: 遅延させずに429を返す
proxy_pass http://backend_app_server;
}

# APIパスへのレートリミット適用
location /api/data {
limit_req zone=api_limiter burst=20 nodelay;
proxy_pass http://backend_app_server;
}

# その他の設定…
}
}

AWS WAF の設定例 (擬似コード):

{
“Name”: “RateLimitRule”,
“Priority”: 1,
“Action”: {
“Block”: {}
},
“VisibilityConfig”: {
“SampledRequestsEnabled”: true,
“CloudWatchMetricsEnabled”: true,
“MetricName”: “RateLimitMetric”
},
“Statement”: {
“RateBasedStatement”: {
“Limit”: 2000, # 5分間に2000リクエストを超えたらブロック (デフォルトで5分間)
“AggregateKeyType”: “IP”, # IPアドレスごとに集計
“ScopeDownStatement”: { # このルールを適用する範囲を絞る
“ByteMatchStatement”: {
“SearchString”: “/login”,
“FieldToMatch”: {
“UriPath”: {}
},
“TextTransformations”: [
{
“Priority”: 0,
“Type”: “NONE”
}
],
“PositionalConstraint”: “STARTS_WITH”
}
}
}
}
}

ポイント:

多様なキーでのレートリミット: IPアドレスだけでなく、ユーザーID、セッションID、APIキーなど、状況に応じて最適なキーでリクエスト数をカウントする。
バックエンドでの実装: NginxやWAFでのレートリミットは第一防衛線として有効だが、最終的な制御はアプリケーション自身で行うべきだ。特にユーザーIDベースのレートリミットはアプリケーションでしかできない。
アカウントロックアウト: ログイン失敗回数が増えたら、一定時間アカウントをロックアウトする。ただし、アカウント列挙攻撃の足がかりにならないよう、エラーメッセージは「ユーザー名またはパスワードが正しくありません」のように抽象化し、ロックアウトされたことを直接伝えないように注意する。

セキュアな設計のための心構えと習慣

Insecure Design対策は、特定の技術やツールを導入すれば終わり、という話じゃない。これは開発チーム全体のマインドセットと文化の問題だ。

1. 「性悪説」に立つ: ユーザーは常に悪意を持つ可能性があると考える。正規のユーザーであっても、操作ミスや勘違いでシステムに予期せぬ影響を与える可能性を考慮する。
2. 最小権限の原則 (Principle of Least Privilege): すべてのコンポーネント、ユーザー、サービスには、その機能を実現するために必要最小限の権限のみを与える。
3. 信頼境界線の明確化: システム内のどの部分が信頼でき、どの部分が信頼できないのかを明確に線引きする。信頼境界を越えるデータはすべて検証・サニタイズ・認可の対象となる。
4. セキュリティ要件を早期に組み込む (Security by Design): 企画・設計段階からセキュリティの専門家を巻き込み、セキュリティ要件を機能要件と同じ重みで扱う。後から付け足すのではなく、最初から組み込む。
5. 定期的な設計レビューとチームでの議論: 一人で抱え込まず、チームメンバーやセキュリティ専門家と積極的に設計を共有し、多様な視点からレビューを受ける。脅威モデリングはその最たる例だ。
6. 常に最新の脅威動向をキャッチアップする: OWASP Top 10はもちろん、CVE情報、セキュリティニュースなどを日頃からチェックし、攻撃者の手口を知る努力を怠らない。

まとめ

Insecure Designは、まさに「見えない敵」だ。表面的なバグじゃない。設計思想やビジネスロジックの奥底に潜む、システムの根幹を揺るがす脆弱性だ。

俺たちセキュリティチーフの役割は、ただバグを見つけて直させるだけじゃない。開発の後輩たちに「攻撃者の視点」を教え、彼らが自ら堅牢なシステムを設計できるようなマインドセットを育むことだと思ってる。

脅威モデリングは、そのための強力な武器だ。実装に入る前に、ホワイトボードを囲んで、ペンを片手に、とことん議論するんだ。「もし俺がハッカーだったら、どうやってこれを突破するか？」ってな。

設計段階でのたった数時間の議論が、本番環境での数億円規模の損害や、企業としての信頼失墜を防ぐ。これは決して大げさな話じゃない。泥臭く、しかし確実に、セキュアな設計を追求していくんだ。

さあ、今日の学びを胸に、明日の設計レビューから、攻撃者の顔を思い浮かべてみろ。それこそが、Insecure Designと戦うための第一歩だ。頑張っていこうぜ。

【実務・中級編】安全でない設計(Insecure Design)の特定と脅威モデリング – アプリケーションセキュリティ & 安全な開発防御ガイド

Insecure Designはなぜ生まれたのか？その盲点と本質

脅威モデリングの真髄：設計段階で攻撃者の視点を持つ

脅威モデリングは「ホワイトボードとペン」から始まる

実務での脅威モデリングプロセス

ビジネスロジックの欠陥を狙う攻撃と防御

シナリオ1: 認可ロジックの不備（水平・垂直権限昇格）

攻撃例 (PoC): ユーザーIDの書き換え

防御策: アクセスリソースごとに厳格な認可チェック

シナリオ2: ワークフローの迂回 / 多段階プロセスのスキップ

攻撃例 (PoC): 決済処理のスキップ

防御策: セッション管理と状態遷移の厳格化

シナリオ3: 過剰な情報開示 / 不適切なエラーハンドリング

攻撃例 (PoC): スタックトレースの漏洩

防御策: エラーメッセージの抽象化とログへの出力

404 Not Found

500 Internal Server Error

シナリオ4: レートリミットの欠如

攻撃例 (PoC): ブルートフォース攻撃によるパスワード特定

防御策: IPアドレス、ユーザーID、セッションベースでのレートリミット

セキュアな設計のための心構えと習慣

まとめ

コメント

Insecure Designはなぜ生まれたのか？ その盲点と本質

脅威モデリングの真髄：設計段階で攻撃者の視点を持つ

脅威モデリングは「ホワイトボードとペン」から始まる

実務での脅威モデリングプロセス

ビジネスロジックの欠陥を狙う攻撃と防御

シナリオ1: 認可ロジックの不備（水平・垂直権限昇格）

攻撃例 (PoC): ユーザーIDの書き換え

防御策: アクセスリソースごとに厳格な認可チェック

シナリオ2: ワークフローの迂回 / 多段階プロセスのスキップ

攻撃例 (PoC): 決済処理のスキップ

防御策: セッション管理と状態遷移の厳格化

シナリオ3: 過剰な情報開示 / 不適切なエラーハンドリング

攻撃例 (PoC): スタックトレースの漏洩

防御策: エラーメッセージの抽象化とログへの出力

404 Not Found

500 Internal Server Error

シナリオ4: レートリミットの欠如

攻撃例 (PoC): ブルートフォース攻撃によるパスワード特定

防御策: IPアドレス、ユーザーID、セッションベースでのレートリミット

セキュアな設計のための心構えと習慣

まとめ

コメント

Insecure Designはなぜ生まれたのか？その盲点と本質