おっと！先週、SQLインジェクションの脆弱性により、WordPressコアの緊急パッチが適用されました。
7月17日、WordPressは、コアに存在する認証不要のリモートコード実行の脆弱性を修正するための緊急リリースを公開しました。この脆弱性は、匿名の攻撃者がデフォルトエクスプロイト SQLインジェクションを介して エクスプロイト 。その深刻さから、WordPress.orgでは強制的な自動更新機能まで有効にしました。この脆弱性を報告したSearchlight Cyber社によると、WordPressを利用しているサイトは5億以上と推定されています。影響を受けている場合は、バージョン7.0.2、または旧ブランチの場合は6.9.5へアップデートしてください。
SQLインジェクション（SQLiとも表記される）は、修正脆弱性 容易脆弱性 古くからの脆弱性 であるため、人々はもはや存在しないと思い込んでいます。しかし、つい先日改めて指摘されたように、そうではありません。
SQLインジェクション：その humble beginnings から現代に至るまで
SQLインジェクションとその対策は、コンピュータサイエンスの入門講座で扱われる内容です。10年以上前に大学でプロンプトインジェクションについて学んだことを覚えています。正直なところ、授業で教わったアプリケーション脆弱性 それだけです（その話題を扱った後、他のトピックに移ったのか、あるいはそれ以降は私が注意を払っていなかったのかもしれません）。
SQLインジェクションについては、1998年に「rainforest puppy」として知られる研究者によって初めて公に報告されました。SQLインジェクションの問題のほとんどを解決する対策である「プリペアードステートメント」は、その約1年後に考案されました。この対策は、社内の多くのエンジニアよりも歴史が古いものです。パラメータ化されたクエリを使用し、ユーザー入力は単なるデータとして扱う必要があります。しかし、対策が存在するにもかかわらず、SQLインジェクションは依然として発生しています。
GitHubアドバイザリデータベースのデータに基づき、CWEごとにアドバイザリを絞り込み、年ごとに集計すると：
SQLインジェクションに関するアドバイザリの件数は、2023年から2025年にかけて、各暦年ごとに増加し、2,096件から2,850件へと伸びた。最も古くから存在する3つのインジェクション種別、すなわちSQLインジェクション、コマンドインジェクション、パストラバーサルを合わせると、報告された全件数の10件に1件以上を占めている。
OWASPは2025年の「トップ10」において、インジェクションを3位から5位に順位を下げましたが、これは問題が解決されたからではありません。インジェクションというカテゴリー全体では、依然として6万件以上が報告されており、他のどのカテゴリーよりも多くのCVEが報告されています。そのうち、SQLインジェクションだけで1万4,000件以上を占めています。Mackenzieによるクローズドソースのリポジトリのスキャンでは、プロジェクトの20％が初回スキャン時点で少なくとも1つのSQLインジェクションの脆弱性を抱えていました。
なぜSQLインジェクションは根絶されないのか
まず、前置きとして言っておきますが、コードを書く際、人はミスを犯すものです。それは避けられないことです。ですから、時折、SQLインジェクションが見逃されてしまうこともあります。しかし、本来は私たちを助けるはずの最新のシステムも、100％完璧に機能するわけではなく、かえって別のミスを引き起こしてしまうことさえあるのです。
例えば、新しいフレームワークには、SQLインジェクションを防ぐための機能が備わっています。Django、Hibernate、ActiveRecordといったORMは、デフォルトでパラメータ化を行うため、多くのチームはこの問題に対処済みだと誤解しがちです。しかし、誰かが生のクエリを実行したり、安全でないメソッドを呼び出したりすると、その保護は機能しなくなります。
DjangoのCVE-2024-42005がその一例です。JSONカラムからフィールドを読み取るために使用されるDjango独自のクエリメソッドのうち2つは、渡されたフィールド名をクリーンアップせずにそのままSQLに組み込んでいました。そのため、フィールド名を制御できる攻撃者は、開発チームが安全だと想定していたメソッドを通じて、クエリの一部を制御できてしまう可能性がありました。
その一方で、非常に古いコードも問題であり、レガシーコードはこうした欠陥を何十年にもわたって引き継いでいます。チームはWAFに頼り、それがすべてを捕捉してくれると想定（あるいは願って）います。修正策は25年以上前から存在していますが、すべてのクエリ、すべてのエンドポイント、そしてレガシーコードの隅々まで、毎回適用することは非常に骨の折れる作業であり、これまでどのコードベースにおいても完全に完了したことはありません。 当社のフィールドCTOであるマッケンジー・ジャクソンが指摘するように、これはもはや技術的な問題ではなく、文化、プロセス、そして教育の問題となっているのです。
そしてもちろん、AIです。
AIもSLQiを作成します
当然の期待としては、数十年にわたる事例で学習されたAIコーディングアシスタントが、1998年のバグを再現しなくなるだろうということだ。しかし、ご存知の通り、AIが完璧なコードを書くわけではない。
これを定量的に見てみましょう。ニューヨーク大学（NYU）とコーネル大学が2021年に実施した「Asleep at the Keyboard」調査では、GitHub Copilotを用いて一般的な脆弱性シナリオに基づいた1,689個のプログラムを生成し、そのうち約40％に脆弱性が確認されました。最も頻繁に見られたのはSQLインジェクションとコマンドインジェクションでした。マッケンジー氏自身のテストでも、同様の結果が得られています。 ChatGPTに対して1つのプロンプトを数百回実行したところ、結果の約12％がインジェクション攻撃を受けやすいものであり、これはオープンソース全体で見られる割合に近いものでした。
しかし、なぜでしょうか？モデルは、こうした欠陥を含む公開コードから学習するため、同様の頻度でそれらを再現してしまうのです。AIは、クロスサイトスクリプティングのような文脈に依存するバグよりも、SQLインジェクションへの対応が優れています。同報告書によると、後者についてはほとんどの出力が安全でないことが判明しています。AIは進化し続けているため、これらの数値は半年もすれば時代遅れになるでしょうが、私たち人間がそうであるように、AIも依然としてこうしたコードを誤って記述してしまうことが予想されます。
そして現在では、技術的な訓練をあまり受けていない「雰囲気重視のコーダー」がコードを書くことが増えています。こうした人々は、SQLインジェクションを認識する可能性が低い（そもそもその存在に気づくかどうかさえ定かではありません）ため、この問題への対処が適切に行われているかを確認する熟練した目を通さずに、より多くのコードが企業のコードベースに組み込まれてしまうことになります。
だからこそ、セーフティネットが必要なんだ
たとえ、あらゆる場所でパラメータ化されたクエリを使用したり、すべての入力に対して許可リストを設定したりするなど、あらゆる対策を講じたとしても……それでも実行時の保護は必要です。すべてのエンドポイントにおいて、常に完璧なサニタイズを実現することなど不可能です。SQLインジェクションは、自分が管理できない脆弱な依存関係（あるいは、ウェブサイトのホストのデフォルトサイトなど）で発生する可能性さえあり、それは合理的に管理できる範囲をはるかに超えた問題です。
Aikido Zen は、アプリケーション内部で動作するアプリ内ファイアウォールであり、データベースクエリやファイル読み取りといったデータシンクへ向かうユーザー入力を監視します。
攻撃のペイロードがこれらの場所のいずれかに到達しようとした瞬間、Zen それを即座にZen 。その際、攻撃と、たまたま攻撃のように見える検索文字列とを区別するのに十分なアプリコンテキストが活用されます。
また、依存関係を通じて侵入してくる欠陥、つまり自社のコーディング基準ではカバーしきれない部分にも対応します。これは、セキュアコーディングが不十分な場合（実際には常にそうなるものです）のランタイム上の安全策として捉えてください。Zen 、コードレベルで危険な入力を検知します。これは、ネットワークレベルで不審な入力をブロックするWAFとは異なります。WAFは精度が低いため、必要以上にブロックしてしまう傾向があります。 この点については、「WAF vs RASP vs ADR」に関する記事でさらに詳しく解説しています。
Zen のようなアプリ内ファイアウォールは、wp2shellとパッチが適用されていないWordPressサイトとの間にZen 。Zen 、この脆弱性が利用するSQLインジェクションをブロックするようにZen 、アップデートを待っているサイトでも、パッチの配布が行われている間、防御体制を維持することができました。
開発ブランチでSQLインジェクションを検出する
実行時の対策は安全策ではありますが、もちろん予防こそが最善策です。理想を言えば、コード内のすべてのSQLインジェクションを発見し、除去することが望ましいでしょう。
SAST 静的解析では、パラメータ化されたステートメントを使わず、入力がそのままクエリに組み込まれる単純なタイプのSQLインジェクションの多くをSAST 。しかし、今回のケースは検出できなかったでしょう。WordPressのコアは、ソフトウェアとしてはほぼ徹底的にスキャンされている部類に入りますが、このバグは見逃されていました。 このケースでは、不正な形式のバッチリクエストによってWordPressの内部管理が乱され、クリーンアップ処理をスキップする経路を通じて値がデータベースに到達した場合にのみ、このインジェクションが悪用可能になります。これは、静的スキャナーでは追跡できないリクエスト間の相互作用です。脆弱性 発見するには、4つのエージェントを6時間稼働させるフロンティアモデル 脆弱性 。
日常的な侵入はスキャナーの仕事です。しかし、隠蔽され、ロジックに依存するタイプの侵入については、他者に先んじてそれを発見するためにAIが必要となるケースが増えており、これはAikido 」によるペネトレーションテストにも 当てはまります。 この研究者がWordPressに対して行ったように、 自社のコードに対してAIを向けさせるのです 。 Aikido は「Aikido 」による継続的なペネトレーションテスト機能を提供しており、コードレビューの網をくぐり抜けようとする新たなSQLインジェクションを定期的にチェックするのに役立ちます。
リトル・ボビー・テーブルズは今も健在です。彼を真剣に受け止め、コードのセキュリティを徹底しましょう。たとえ退屈な部分であってもです。
