NoSQLの「ドアノブ」を回す侵入者――型変換攻撃からシステムを守るには？
こんにちは。セキュリティの現場で日々、泥臭いインシデントと向き合っているエンジニアです。
今日は、Webアプリケーションの「入り口」で起きている、ちょっと厄介な手口についてお話しします。「SQLインジェクション」という言葉は聞いたことがあるかもしれませんが、最近のモダンなアプリで使われるNoSQL（MongoDBなど）でも、似たような、あるいはもっと巧妙な「なりすまし」が起きていることをご存知でしょうか。
「うちのサイトはSQLを使っていないから大丈夫！」なんて思っていると、実は泥棒に裏口の鍵を預けているのと同じ状態かもしれません。一歩ずつ、そのメカニズムと対策を紐解いていきましょう。
—
1. 泥棒は「文字列」を求めているのに、「命令」を渡してくる
まずは、家のセキュリティに例えてみましょう。あなたの家の玄関には、「名前を書いて入れる」ポストがあるとします。本来なら、そこには「山田太郎」という文字列だけが入るはずですよね。
ところが、攻撃者はここに「手紙」ではなく、「鍵を無効化する魔法のカード（オブジェクトや配列）」を投げ込んでくるのです。これがNoSQLにおける型変換攻撃の正体です。
攻撃のメカニズム：期待を裏切る「型」の混入
多くのNoSQLデータベース（例えばMongoDB）では、入力値として「文字列」を期待している場所に、「クエリ演算子（特別な命令）」を含むオブジェクトを渡すと、プログラムがそれを「単なる文字」ではなく「データベースへの命令」として解釈してしまうことがあります。
例：ログイン処理での悪用
本来は {"username": "user1"} というデータを探したいのに、攻撃者が {"username": {"$gt": ""}}（意味：空文字より大きいユーザー名を探せ＝つまり誰でもいいからログインせよ）というオブジェクトを送り込むと、システムがそれを「命令」として受け取ってしまい、パスワードなしでログインできてしまうのです。
—
2. なぜ「型」をチェックしないといけないのか？
プログラミングの世界では、データが「数字なのか」「文字列なのか」「配列なのか」という「型」は非常に重要です。しかし、Webからの入力値は、多くの場合「何でも入る箱」として受け取ってしまいがちです。
泥棒が「私は花瓶です」と書かれた札を持っていても、中身が爆弾だったら困りますよね？ だからこそ、「入ってくるデータの形が、期待しているものと合致しているか」を厳格にチェックする必要があるのです。
—
3. 実践！安全な開発のための「型バリデーション」
では、実際にどう守ればいいのでしょうか。一番の対策は、「入力されたデータが、想定した型（文字列など）以外なら、即座に追い返す」ことです。
Node.jsとMongoDBを使っている場合を例に、守りを固めてみましょう。
悪い例：そのまま受け取ってしまう（穴だらけ）
// 注意！これだとオブジェクトを投げ込まれたらそのまま命令として実行されます
app.post(‘/login’, (req, res) => {
const query = { username: req.body.username }; // 入力をそのままクエリに！
db.collection(‘users’).findOne(query, …);
});
良い例：ライブラリを使って「型」を縛る
ここでは、Joi という有名なバリデーションライブラリを使って、「文字列以外は受け取らない！」と宣言する方法を紹介します。
const Joi = require(‘joi’);
// スキーマ（設計図）を定義する
const schema = Joi.object({
// usernameは「文字列」で、かつ「20文字以内」というルールを作る
username: Joi.string().alphanum().max(20).required()
});
app.post(‘/login’, (req, res) => {
// 入力値がルール通りかチェック
const { error } = schema.validate(req.body);
if (error) {
// ルール違反なら「泥棒お断り！」として処理を止める
return res.status(400).send(“不正な入力です”);
}
// ここまで来たら安全！安心してクエリを実行できる
const query = { username: req.body.username };
db.collection(‘users’).findOne(query, …);
});
—
まとめ：あなたのコードを守る「玄関の門番」
今回お伝えしたかったのは、「入力を信じるな」というセキュリティの鉄則です。
1. 型を意識する: 文字列が欲しいところに、オブジェクトや配列を渡させない。
2. スキーマバリデーションを導入する: Joi や Zod のようなライブラリを使って、入り口でデータの形を厳しくチェックする。
3. 最小権限の原則: もし万が一侵入されても、データベースの権限を絞っておけば被害は最小限で済みます。
セキュリティ対策は、一度やって終わりではありません。ですが、こうして「データの形」を意識する習慣をつけるだけで、あなたの書くコードは格段に強固になります。
今日からあなたの書くコードに、小さな「門番（バリデーション）」を置いてあげてください。それが、あなたの大切なユーザーを守る第一歩になります。また次の現場でお会いしましょう！
コメント