なぜ「バリデーション」が現場で軽視されるのか —— 脆弱性の入り口を塞ぐ極意
こんにちは。現場で泥をすすりながらインシデント対応をしていると、つくづく思うことがあります。「なぜ、これほどまでにインジェクション攻撃は消えないのか」と。
多くのエンジニアが「ORMを使っているからSQLiは大丈夫」「エスケープはライブラリがやってくれる」と安易に考えがちです。しかし、攻撃者はそんな教科書通りの穴は突きません。彼らは「開発者が想定しなかったデータの型」や「仕様の隙間」をピンポイントで狙い撃ちしてきます。
今日は、Node.js/Express環境における防波堤、『express-validator』を使った「負けないためのバリデーション実装」について、実務の現場目線で深掘りします。
—
攻撃者の視点：バリデーションなきアプリの「末路」
例えば、ユーザーIDを受け取ってDBを検索するだけの単純なAPIがあるとします。
// 【危険なコード】バリデーションを怠った実装
app.get(‘/user/:id’, async (req, res) => {
// 入力をそのままクエリに突っ込むのは自殺行為
const user = await db.query(SELECT FROM users WHERE id = ${req.params.id});
res.json(user);
});
攻撃者はここに対し、1 OR 1=1 といった古典的なSQLiだけを仕掛けてくるわけではありません。1; DROP TABLE users; -- のようなOSコマンド混じりの攻撃や、あるいは型変換を利用した不整合攻撃を仕掛け、アプリケーションのロジックを崩壊させます。
「型が違うならエラーになるだろう」という性善説は、Webの最前線では通用しません。「受信したすべてのデータは悪意があるものとみなす」。これがセキュリティの鉄則です。
—
実践：express-validatorによる「拒絶」の設計
express-validatorの真価は、コントローラーが処理を始める前に、ミドルウェア層で「不正な値を遮断する」ことにあります。
実装サンプル：堅牢なバリデーション定義
まず、express-validatorを導入し、ルーター側で入力を厳格に定義します。
const { param, validationResult } = require(‘express-validator’);
// バリデーションミドルウェア
const validateUserRequest = [
// 1. 型の強制: idは数値のみ許可
// 2. 範囲の指定: マイナス値や巨大な数値を除外
param(‘id’)
.isInt({ min: 1, max: 999999 })
.withMessage(‘無効なID形式です’),
// バリデーションチェック実行
(req, res, next) => {
const errors = validationResult(req);
if (!errors.isEmpty()) {
// ログには詳細を残し、クライアントには最小限の情報のみ返す
console.error([Security Alert] Validation Failed: ${JSON.stringify(errors.array())});
return res.status(400).json({ error: ‘不正なリクエストです’ });
}
next();
}
];
// ルート定義
app.get(‘/user/:id’, validateUserRequest, async (req, res) => {
// ここに来る時点で、idは必ず「1〜999999の整数」であることが保証されている
const userId = req.params.id;
// プリペアドステートメントと組み合わせれば鉄壁
const user = await db.query(‘SELECT FROM users WHERE id = ?’, [userId]);
res.json(user);
});
なぜこれが「安全」なのか
- ホワイトリスト方式: 「何がダメか」を考えるのではなく、「何が正しいか（整数であるか）」のみを定義しています。
- 早期リターン: アプリケーションロジックに到達する前に処理を止めることで、バックエンド（DBやOS）への攻撃ベクトルを物理的に断ち切ります。
- 可観測性: バリデーションエラーをログに残すことで、攻撃者が「どのエンドポイントをスキャンしているか」という予兆検知が可能になります。
—
現場のシニアとしてのアドバイス：多層防御の思考
バリデーションだけで全てが解決するわけではありません。真の防御は「重層的」であるべきです。
1. DBアクセス: どんなにバリデーションを完璧にしても、SQLクエリ構築には必ず「プレースホルダー（プリペアドステートメント）」を使用してください。バリデーションは「入力の適正化」、プレースホルダーは「データベースへの安全な渡橋」です。この両輪が欠けてはいけません。
2. WAF（Web Application Firewall）: AWS WAFなどを利用している場合、SQL Injection系のマネージドルールを有効にしつつ、正規表現によるフィルタリングを追加しましょう。
- ヒント:
/api/user/.[;'"\-].のようなパターンをWAFでブロックするだけでも、初歩的なスキャン攻撃の多くは弾けます。
3. 機密情報のログ出し禁止: バリデーションエラーのログに、ユーザーの入力値（攻撃者のペイロード）をそのまま出力すると、ログファイル自体がインジェクションの標的になります。ログ出力時は必ずサニタイズを行ってください。
—
まとめ：防御は「コスト」ではなく「信頼のインフラ」
バリデーションを書くのは面倒です。しかし、一度SQLインジェクションで数万件の個人情報が流出すれば、その代償はコードを書く時間の数万倍になります。
「動くコード」を書くのはジュニアエンジニアの仕事です。「攻撃されても倒れないコード」を書くのが、我々プロフェッショナルの仕事です。まずは今日、あなたのプロジェクトのルーティング定義を見直し、express-validatorで門番を配置することから始めてください。
セキュリティは、一朝一夕には完成しません。日々のコードレビューと、少しの疑り深さが、あなたのサービスを守る最大の武器になります。
それでは、また現場で会いましょう。何かあれば、いつでも相談してください。
コメント