Hello there, ('ω')ノ
記事：
https://medium.com/@medz20876/blog-post-bypassing-an-admin-panel-with-sql-injection-20b844442711
ねらい
この記事はSQL Injection（SQLi）を利用して、Webアプリの管理者パネルへの認証をバイパスする手法を解説しています。 攻撃者の狙いは「パスワードが分からなくてもSQL文を操作して管理者としてログインする」ことです。
全体像（ストーリー）
- 攻撃対象は 管理者ログイン画面。
- 入力されたユーザー名とパスワードがSQLクエリにそのまま渡されている。
- 攻撃者は' OR '1'='1 などのペイロードを試す。
- SQL文の構造が壊れ、常に真になる条件が成立。
- 結果：本来の認証を通さず管理者としてログイン成功。
実践：一手ずつ「なぜそうするか」
1) フォーム入力の観察
- 操作：管理画面のログインページを開く。
- 観察：ユーザー名とパスワードを入力できるシンプルなフォーム。
- なぜ：こうしたフォームはSQLiの典型的な入り口だから。
2) 単純なペイロードでテスト
操作：パスワード欄に
' OR '1'='1を入力。なぜ：この入力がSQLに入ると次のようになる：
SELECT * FROM users WHERE username='admin' AND password='' OR '1'='1';
- 結果：
'1'='1'が常に真 → 認証バイパス。
3) 管理者権限を奪取
- 観察：ログイン画面を通過 → 管理者パネルに入れる。
- なぜ：アプリが「最初に見つかったユーザー（admin）」を返す仕様だったため。
失敗するパターン
入力値がサニタイズされている場合 →
' OR '1'='1が文字列として処理され、SQLが壊れない。プリペアドステートメント使用時 → 値とクエリが分離されており、インジェクションできない。
実務目線の防御策
プリペアドステートメント（Prepared Statements）の利用 → SQLiを原理的に防止。
入力検証とエスケープ →
' " ; --などを適切に処理。エラーメッセージを隠す → SQLエラーをユーザーに返さず、ログにのみ記録。
管理画面へのアクセス制限 → IP制限や多要素認証を導入。
まとめ
攻撃者の思考はこうでした：
- 管理者ログインフォームを観察
- SQL文の挙動を推測
- シンプルなペイロードでテスト →
' OR '1'='1 - 認証がバイパスされ、管理者パネルに侵入
つまり、「SQL文に直接渡される入力がないか」を常に確認することが、バグハンティングの第一歩になります。
Best regards, (^^ゞ
