Vulnerabilities

SQLインジェクション(SQLi)とは何か?

SQLインジェクション(SQLi)は、攻撃者が入力フィールドに悪意のあるSQL文を入力してデータベースを操作する攻撃の一種です。

SQLインジェクション(SQLi)とは何か?

SQLインジェクション(SQLi)は、攻撃者が入力フィールドに悪意のあるSQL文を入力してデータベースを操作するタイプの攻撃です。

この攻撃は、適切に検証やユーザー入力を処理できないアプリケーションを対象とし、パスワードやクレジットカードの詳細などの機密データへの不正アクセスを許可します。

SQLインジェクションの仕組み

アプリケーションがユーザー入力を適切に検証せずにデータベースクエリに直接含めると、攻撃者はクエリの動作を変更して悪意のあるSQL文を入力することができます。

例えば:

SELECT * FROM users WHERE username = 'admin' AND password = '12345';

攻撃者は次のように入力することができます:

' OR '1'='1

結果として:

SELECT * FROM users WHERE username = '' OR '1'='1' AND password = '';

これにより常にtrueが返され、不正アクセスが許可されます。

サイバーセキュリティにおけるSQLインジェクションの重要性

SQLインジェクションはサイバーセキュリティにおいて最も危険で古い技術です。このタイプの攻撃は常にOWASP Top 10にリストされています。

小さな脆弱性でも攻撃者に以下を許可します:

  • データのアクセス、変更、削除
  • 認証の回避
  • データベースでの管理操作の実行
  • システム全体の侵害

SQLインジェクションの一般的な種類

  • クラシックSQLi : ウェブフォームやURLパラメータを介した直接的な注入。
  • ブラインドSQLi : 攻撃者がエラーメッセージや応答時間を通じて間接的にデータベース情報を推測。
  • ユニオンベースSQLi : UNION演算子を使用して複数のクエリからの結果を結合。
  • エラーベースSQLi : データベースのエラーメッセージに依存して情報を抽出。
  • 時間ベースブラインドSQLi : サーバーの応答遅延を利用してクエリ結果を推測。

SQLインジェクションを防ぐ方法

1. パラメータ化されたクエリ(プリペアドステートメント)の使用

SQLコマンドがユーザー入力をデータとして扱い、実行可能なコードとして扱わないようにする。

cursor.execute("SELECT * FROM users WHERE username = ?", (username,))

2. 入力の検証とサニタイズ

ユーザーからのすべての入力を検証し、期待される文字のみを許可する。

3. ORMフレームワークの使用

PrismaやHibernateなどのフレームワークは、直接的なSQLの取り扱いを減少させる。

4. 最小特権の原則

ユーザーの権限を制限し、必要な権限のみを与える。

5. 定期的なセキュリティテスト

アプリケーションセキュリティテストツールとして、SASTDAST、またはIASTを使用し、早期にインジェクションの欠陥を検出します。

実世界の例

あるオンラインストアのウェブサイトが侵害され、攻撃者がログインフォームでSQLインジェクションを使用してデータベースからクレジットカードの詳細を抽出しました。

関連用語

Ready to validate what matters?

Ready to validate what matters?

Plexicus is Proof-Driven AppSec: validated findings, contextual understanding, and reviewed remediation — anchored in evidence, scoped with you.

Qualification

Check whether AI Swarm Pentest fits your environment.

Share the minimum context. We will review the scope and tell you the next commercial step.

Before submitting — verify you fit
Do you have a recent classic pentest you're not happy with?

0 / 280

No commitment. If you don't fit, we'll tell you.

SAMPLE HANDOVER · ILLUSTRATIVE

Sample evidence handover

A trimmed view of what your team receives at the end of an AI Swarm Pentest engagement. Real engagements include full technical evidence, executive narrative, and a remediation plan.

VALIDATED FINDING Evidence attached

Server-Side Request Forgery in webhooks/receiver

demo-project/sample-app · src/webhooks/receiver.py:42

SeverityHigh CVSS 3.18.6 Priority79 Confirmedvia replay

Untrusted caller-supplied URLs reach an internal egress without an allowlist. Replayed in a sandbox against a fresh authorised target — the same control was validated to fail twice.

REVIEWER-READY REMEDIATION Merge-ready PR

Validate the target URL against an allowlist of permitted hostnames. Reject private/internal IP ranges. Enforce HTTPS only.

plexicus/remediation/webhooks-ssrf 3 changed · 0 new files
42resp = requests.get(target_url)
42+if not is_allowed_host(target_url):
43+  raise WebhookRejected(target_url)
44+resp = requests.get(target_url, timeout=5)
Every engagement hands over:
  • Executive briefing
  • Validated findings list
  • Merge-ready PRs
  • Compliance mapping (NIS2 · DORA · CRA)