セキュリティを整える
専門SQLインジェクションのしくみを整える。
＝ 入力欄の細工でデータが抜ける“あの脆弱性”を、手元の練習DBで安全に体験
SQL インジェクションが初めての方は、先に そもそも SQL インジェクションとは・どんな場面で出会うか をどうぞ。
防御・教育目的
このツールは「なぜ脆弱なコードは破られ、正しいコードは破られないのか」を理解するための 防御教育です。動かしているのはあなたのブラウザ内のダミー DB だけ（送信ゼロ・実在のサービスやデータベースには一切アクセスしません）。 実在するサービスや他人のシステムへの SQL インジェクションは、不正アクセス禁止法に触れる犯罪行為です。絶対に行わないでください。
アニメで見る — SQL インジェクションのしくみ 開くと1ステップずつ動きます
入力欄
name / password
アプリ
クエリ組み立て
データベース
SQLite
入力欄
name / password
アプリ
プリペアド文
データベース
SQLite
STEP 1
※ これはイメージ図です。下の「手元のサンドボックスで試す」で、同じ入力が脆弱版と安全版でどう変わるかを実際に比べられます。
手元のサンドボックスで試す
同じ入力を、脆弱版と安全版に同時に流し込む。
ログイン想定のクエリ SELECT * FROM users WHERE name='…' AND password='…' を、
2 通りの実装で実行します。name 欄に攻撃文字列を入れて「実行」を押すと、左（文字列連結）は認証バイパスで全件返り、右（プレースホルダ）は 0 件になることを見比べられます。
攻撃文字列サンプル（クリックで name 欄に挿入）
文字列連結（危険な実装）
入力をそのまま + で連結している
実行された生 SQL
赤地・下線・太字 ＝あなたの入力がそのまま命令に混ざった部分
プレースホルダ（安全な実装）
クエリの形は固定し、入力は ? に値として渡す
テンプレート＋バインド値
サンドボックス users テーブル（ダミー・機密でない学習用データ）
taro / hunter2・hanako / sakura88・admin / s3cr3t-admin の 3 行。すべて作り物で、リセットでいつでも戻せます。
そもそも SQL インジェクションとは
入力された文字が、データベースへの「命令」として解釈されてしまう弱点。
SQL（Structured Query Language）は、データベースに「この条件の人を探して」「この内容を書き込んで」と頼むための言葉です。SQL インジェクションは、入力欄に書かれた文字が、データの一部ではなく「命令の一部」として受け取られてしまう弱点のことです。
たとえるなら、窓口で「山田さんの書類をください」と書く用紙に、別の依頼まで書き足されて、係の人がそれも実行してしまうようなものです。用紙の「欄」と「命令」が混ざっていることが原因です。
どこで・どんな場面で出会うか
-
ログイン画面
ユーザー名とパスワードを、データベースの登録内容と突き合わせるところです。入力をそのまま命令に組み込む作りだと、弱点になります。
-
検索フォームや絞り込み
キーワードや条件を入れて一覧を出す画面は、入力がデータベースへの問い合わせに直接つながりがちです。
-
URL に商品 ID や記事番号が付くページ
アドレスの数字を使って中身を取り出す作りも、入力の一つです。見落とされやすい場所です。
-
社内システムや自作ツール
急ぎで作ったものは、入力の扱いが後回しになりがちです。社内だけだから安全、とは限りません。
-
古いシステムや、ひな形をそのまま使ったコード
昔の書き方では、文字をつなげて命令を作るものが多く残っています。引き継いだときに確認したい点です。
知らないと何が困るか
- 顧客情報や会員情報が外に出てしまう。データベースの中身がまとめて読み出されると、被害が一度に大きくなります。
- データを書き換えられたり、消されたりする。読み取りだけでなく、更新や削除ができてしまう場合があります。
- 原因に気づくのが遅れる。画面は普通に動いているため、被害が出てから発覚することが少なくありません。
上のサンドボックスで、守っていない書き方と守っている書き方の結果の違いを、見比べてみてください。
どう防ぐか
「入力を命令にしない」ための 4 つの基本。
① プレースホルダ／プリペアドステートメント（最重要）
クエリの「形」を先に固定し、入力は ? や名前付きパラメータに値として渡す。入力はどんな文字でも「データ」にしかならず、命令として解釈されません。これだけで本デモの攻撃は無力化されます。
② 入力検証（バリデーション）
「数値のはずの欄は数値だけ」「メールは形式チェック」など、期待する形以外を弾く。ただし連結をやめる代わりにはならない補強策。検証だけに頼るのは危険です。
③ 最小権限（least privilege）
アプリが使う DB ユーザーに、必要な権限だけを与える。読み取りしかしないなら更新・削除権限を持たせない。万一抜かれても被害範囲を小さくできます。
④ ORM / クエリビルダ
多くの ORM（Prisma / Active Record / SQLAlchemy など）は内部でパラメータ化を行うため、素の文字列連結を避けやすい。ただし生 SQL を書く箇所では結局①が必要です。
使い方
- 1攻撃文字列サンプルを押す、または name 欄に直接入力する（初期値は
' OR '1'='1' --）。 - 2「▶ 両方で実行」を押す。左（脆弱）と右（安全）に同じ入力が流れます。
- 3左は生 SQL に攻撃文字列が混入して全件返り、右は0 件になるのを見比べる。「なぜ通るか」が生 SQL で見えます。
- 4
taro / hunter2など正規の入力では両方とも 1 件返る＝安全版でも普通のログインは壊れない、を確認する。
このツールについて
「入力欄に変な文字を入れると、なぜ全部のデータが抜けるのか？」──ログイン想定のクエリに攻撃文字列を入れ、文字列連結の“脆弱版”とプレースホルダの“安全版”を並べて比べます。手元のサンドボックスDBだけで完結し、実在サービスには一切触れません。攻撃の練習ではなく、防ぐ仕組みを掴むためのツールです。
`' OR '1'='1' --` を入れると、なぜ全件抜けるのか。脆弱版と安全版を並べて、プレースホルダがそれを無力化する様子を生SQLで確かめる。
🔰 かんたんに言うと
入力欄の細工でデータベースが乗っ取られる不具合（SQLインジェクション）を、練習用のDBで安全に体験します。
主な機能
- 手元のsql.jsサンドボックスDB（ダミー3件）で完結・送信ゼロ
- 脆弱版（文字列連結）の実行された生SQLをそのまま表示
- 安全版（プレースホルダ ? バインド）と同一入力で同時対比
- 「入力→混入→DBが命令と解釈」をStepDiagramで図解
- 攻撃文字列サンプル＋正規ログインのワンクリック検証
- 防御解説（プレースホルダ/入力検証/最小権限/ORM）
- 注入された入力部分を SQL 上で色分け表示
📖 このツールで使う用語
用語集トップへ →分からない用語があれば、クリックして解説をご覧ください。
よくある質問
Q. 実在のサービスに試せますか？
A. いいえ。動くのはブラウザ内のダミーDBだけで、実在サービス・DBには一切接続しません。他人のシステムへのSQLインジェクションは不正アクセス禁止法に触れる犯罪です。
Q. ' OR '1'='1' -- を入れると何が起きますか？
A. 脆弱版では入力の ' がクエリの引用符を閉じ、OR '1'='1' が常に真の条件として混入し、-- 以降（パスワード判定）が無効化されて全ユーザーが返ります（認証バイパス）。
Q. プレースホルダはなぜ安全なのですか？
A. クエリの「形」を先に固定し、入力は ? に値として渡すためです。引用符やSQL断片も「ただの文字データ」として扱われ、命令には変わりません。
Q. 入力検証（バリデーション）だけでは防げませんか？
A. 補強にはなりますが不十分です。抜け道が残りやすく、根本対策はプレースホルダ（プリペアドステートメント）です。検証は併用する補助策と考えてください。
Q. ORMを使えば自動的に安全ですか？
A. 多くのORMは内部でパラメータ化するため安全寄りですが、生SQLを書く箇所では結局プレースホルダが必要です。
Q. データは送信されますか？
A. されません。sql.js（WASM）がブラウザ内で完結し、入力もDBも端末から出ません（送信ゼロ）。
入力値はURLの「#」以降に入るためサーバーには送信されません。リンクを開くと同じ状態を復元します。
続けて整える
この内容は、研修でも扱っています
totonoe.tech を運営する株式会社Koinobori は、法人向けの研修サービス「NOBORIBA®」も運営しています。 ここで手を動かした内容を、講師から教わる形の研修です。このページの道具は無料のまま、登録もいりません。
