SQLインジェクション、誕生おめでとう。決して消えないバグへ

本記事は Help Net Security に掲載された記事を元に、更新および転載したものです。

‍

コードに触れる機会のあるサイバーセキュリティの実務に携わっている方なら、SQLインジェクションについて何度も考えさせられた経験があるのではないでしょうか。これは非常に一般的な脆弱性であり、発見から数週間でその単純な解決策が判明していたにもかかわらず、現在もソフトウェアを脅かし続けています。デプロイ前に検知できなければ、攻撃者に格好の侵入経路を与えてしまうのです。

2020年12月13日で、SQLインジェクションは誕生から22年を迎えました。成人してもおかしくない年齢になってもなお、私たちはこの脆弱性を根絶するどころか、いまだに振り回されています。今年8月、Freepik Companyは SQLインジェクションの不手際により被害を受けた ことを公表し、830万人分のユーザーアカウントが流出しました。その多くはGoogleやFacebookなどのサードパーティログインを利用していましたが、数百万件についてはユーザー名とともに暗号化されていないパスワードまで流出していました。本人や関係者にとって、こうしたインシデントによる被害は計り知れず、ユーザーからの信頼を回復するには長い年月を要します。

この「レガシー」な問題の記念日を祝うにあたり、少し立ち止まって分析してみましょう。なぜこの脆弱性は繰り返し発生するのか、なぜ長年OWASP Top 10の首位から転落しないほど危険であり続けるのか、そしてなぜその比較的単純な修正方法がソフトウェア開発の一般的なベンチマーク基準として定着しないのでしょうか。

なぜ2021年になってもSQLインジェクションが問題なのか？

最近の注目すべき侵害事例である FireEyeへの壊滅的なサイバー攻撃 を見ると、その巧妙さは驚くべきレベルです。これは国家レベルの攻撃者が高度な技術を駆使し、FireEyeを標的にして綿密に計画された攻撃でした。FireEyeのCEOであるケビン・マンディア氏は声明で次のように述べています。

「攻撃者は、FireEyeを標的として 攻撃 するために、世界最高レベルの能力を特化させていました。彼らはオペレーショナル・セキュリティ（OPSEC）の訓練を積んでおり、規律と集中力を持って実行に移しました……彼らは、私たちやパートナーが過去に目にしたことのない、斬新な技術の組み合わせを用いていました。」

これはあらゆるCISOにとって悪夢のような話です。FireEyeのような企業でさえこのような事態に陥る可能性があるという事実は、多くの企業がいかに脆弱であるかを浮き彫りにしています。

……しかし、一般的な組織にとってはさらに 悪い ニュースです。FireEyeは世界で最も有名なサイバーセキュリティ企業の一つであり、彼らへの攻撃を成功させるには、黒幕レベルの犯罪者が総力を挙げて組織的かつ大規模に実行する必要がありました。しかし多くの企業にとって、利益の上がるデータ侵害は、黒幕など必要とせず、単純なバグを突くだけでいとも簡単に引き起こされてしまうのです。SQLインジェクションはまさにその後者の典型例であり、ダークウェブで小銭を稼ごうとするスクリプトキディたちに今も悪用され続けています。

2020年5月、ある男がクレジットカードの不正売買とハッキングの容疑で起訴されました。男が所持していたデジタルメディアには、数十万件もの有効なクレジットカード番号が保存されていました。彼はSQLインジェクション技術を駆使してこれらを収集し、多くの企業と数百万人の顧客に被害を与えていたのです。

業界全体として私たちは 常に 進歩していますが、SQLインジェクションは依然として重大な脅威であり、レガシーシステムやパッチ未適用のシステムだけでなく、より広範囲に影響を及ぼしています。

なぜ開発者はSQLインジェクションを放置してしまうのか（そして、それは彼らのせいではない理由）

SQLインジェクションの修正は簡単であり、そもそも混入させないコードを書くべきだと私たちは言い続けています。しかし、何事もそうであるように、それは「正しいやり方」を教わって初めて簡単なことなのです。

ソフトウェア開発プロセスにおいて、歯車が狂い始めるのはここからです。開発者が同じ過ちを繰り返すことで、SQLインジェクションのような脆弱性がコードベースに浸透してしまいます。しかし、これは驚くべきことではありません。ほとんどのエンジニアは、大学でセキュアコーディングについてほとんど、あるいは全く学ばずに卒業しています。職場でのトレーニングも不十分なことが多く、特にセキュリティがビジネス上の優先事項と見なされていない環境ではなおさらです。

私たちは開発者に対し、セキュリティを重視すべき理由も、セキュリティ意識を高めるための強力な基盤も提供できていません。不適切なコーディングパターンがSQLインジェクションのようなバグを存続させています。私たちは開発者のセキュリティ意識向上にもっと重点を置き、より高品質でセキュアなコードを書くための時間を確保する必要があります。セキュアなコーディングパターンは記述に時間がかかることもありますが、そこで費やした時間は、後のプロセスにおいて計り知れない効率化をもたらします。

SQLインジェクションに「葬式」が訪れる日は来るのか？

葬式のメタファーは少し不謹慎かもしれませんが、SQLインジェクションが完全に葬り去られれば、私たちの機密データはより安全になるはずです。しかし、それが実現するまでにあと何度か「誕生日」を祝うことになるでしょう。なぜなら、予防的なセキュリティ文化やセキュアコーディングへの重視といった意識は、棺桶の蓋を閉めるほどにはまだ進化していないからです。

Rustのような新しくセキュリティ堅牢性の高い言語は、より安全な関数を活用することで長年悩まされてきたバグの撲滅に貢献しています。しかし、膨大な量のレガシーソフトウェアや旧システム、ライブラリは今後も使用され続け、潜在的な脆弱性を抱えたままとなるでしょう。

「容易な」エクスプロイトを完全に排除するには、開発プロセスにおけるセキュリティの共同責任（DevSecOpsの出番です）が不可欠です。開発者を最初からプロセスに巻き込み、より安全で優れたコードを作成するという役割を担えるよう支援しなければなりません。

開発者は、コード内のSQLインジェクションの脆弱性をどのように修正すべきでしょうか？

私たちは、SQLインジェクションの特定と修正方法を学びたい開発者のために、包括的なガイドを作成しました。好みのプログラミング言語（COBOLでさえも！）で挑戦できるゲーム形式の課題も用意されており、すべての開発者がより安全で高品質なコードを作成するための基礎をしっかりと学べます。