この記事の一部は、以下のサイトに掲載されています。 ヘルプネットセキュリティ.この記事は更新され、ここでシンジケートされています。

‍

もしあなたがサイバーセキュリティの仕事に就いていて、コードに精通している必要があるならば、SQLインジェクションについて何度も何度も考えなければならない可能性があります。SQLインジェクションは一般的な脆弱性であり、最初に発見されてから数週間で簡単な対処法がわかったにもかかわらず、我々のソフトウェアを悩ませ続け、導入前に検出されないままでいると、自称攻撃者にわずかなチャンスを与えることになります。

2020年12月13日、SQLインジェクションの22回目の誕生日を迎えました。この脆弱性はお酒が飲めるほど古いものであるにもかかわらず、私たちはこの脆弱性を永久につぶすことなく、そのままにしています。今年の8月、Freepik社は、830万人のユーザーのアカウントを危険にさらすSQLインジェクションの失態の被害に遭ったことを公表しました。ユーザーの中には、GoogleやFacebookなどの第三者によるログインを利用していた人もいましたが、数百万人のユーザーは、暗号化されていないパスワードがユーザー名とともに流出していました。彼らや他の多くのユーザーにとっては残念なことに、これらの事件の影響は大きな頭痛の種であり、ユーザーベースの信頼を回復するには長期的なプロセスが必要です。

この節目をレガシーとされる問題で「祝う」一方で、この問題を少し分析してみましょう。なぜこのような問題が後を絶たないのか、なぜOWASPトップ10の上位から何年も抜け出せないほど危険なのか、そしてなぜ比較的簡単な修正方法がソフトウェア開発の一般的なベンチマーク基準に入っていないのか。

なぜSQLインジェクションは2021年になっても有効なのか？

最近話題になったFireEye社への壊滅的なサイバー攻撃を見てみると、その巧妙さに驚かされます。この攻撃は、FireEye社の強盗用にカスタマイズされたと思われる高度な技術を駆使した、高度に組織化された国家的な攻撃でした。

"攻撃者 たちは、 ファイア・アイを標的にして 攻撃するために、その世界レベルの能力を特別に調整しまし た。 彼らはオペレーション・セキュリティの高度な訓練を受けており、規律と集中力を持って実行しました。彼らは、当社や当社のパートナーが過去に目撃したことのない斬新な技術の組み合わせを使用しました。”

CISOにとっては悪夢のような話ですが、もしFireEye社にこのようなことが起きれば、多くの企業がいかに脆弱であるかがわかるでしょう。

しかし、一般の企業にとっては、さらに悪いニュースです。FireEyeは、世界で最も有名なサイバーセキュリティ企業の1つですが、今回の攻撃では、黒幕レベルの悪人たちが全力を挙げて組織的に大規模な攻撃を行いました。しかし、多くの企業にとっては、単純なバグを利用して、素早く、しかも首謀者を必要とせずに、莫大な額のデータを流出させることができるかもしれません。SQLインジェクションはその典型的な例であり、ダークウェブで一儲けしようとするスクリプト・キディたちがいまだに利用しています。

2020年5月、ある男性が、数十万件の有効なクレジットカード番号を保存したデジタルメディアを持っていたことが発覚し、クレジットカードの不正利用とハッキングの罪で起訴されました。彼はSQLインジェクション技術を用いてこれらの情報を収集し、多くの企業とその顧客数百万人を危険にさらしました。

業界として、私たちは常に改善を続けていますが、SQLインジェクションは依然として重大な脅威であり、レガシーシステムやパッチが適用されていないシステムよりもはるかに多くのものに影響を与えます。

なぜ開発者はそれを維持しているのか（そしてそれが彼らの責任ではないことも

私たちは、SQLインジェクションは簡単に修正でき、コードはSQLインジェクションが全く発生しないように書くべきだと言い続けています。ほとんどのことがそうであるように、正しいやり方を教わっていれば簡単なのです。

ここで、ソフトウェア開発プロセスの歯車がぐらつき始めます。開発者は同じ間違いを繰り返し、SQLインジェクションのような脆弱性が繰り返しコードベースに侵入することになります。しかし、これは驚くべきことではありません。ほとんどのエンジニアは、安全なコーディングについてほとんど何も学ばずに学位を取得します。特に、自分の役割においてセキュリティがビジネス上の優先事項とみなされていない環境では、ほとんどのオン・ザ・ジョブ・トレーニングは不十分なものになります。

開発者がセキュリティに関心を持つ理由や、セキュリティ意識を高めるための強力なプラットフォームが提供されていないのです。劣悪なコーディングパターンがSQLインジェクションのようなバグを存続させています。私たちは、開発者のセキュリティ意識にもっと重点を置き、より高い水準の安全で質の高いコードを書くための時間を与える必要があります。安全なコーディングパターンを書くには時間がかかりますが、そのために費やした時間は、後の工程で非常に重要な効率性を生み出します。

SQLインジェクションの葬儀は行われないのか？

お葬式の例えは少し病的ですが、実際、SQLインジェクションが永久に眠りにつくことができれば、私たちの機密データはより安全になります。なぜなら、予防的なセキュリティの文化や、安全なコーディングの重要性が、棺桶に釘を打ち始めるのに十分なほど進化していないからです。

Rustのようにセキュリティに強い新しい言語は、より安全な関数を利用することで、長い間対処してきたバグを根絶するのに役立っていますが、膨大な量のレガシーソフトウェア、古いシステム、ライブラリは、今後も使用され続け、潜在的な脆弱性を持っています。

簡単な」エクスプロイトを永久に封じ込めるためには、開発プロセスにおけるセキュリティの責任分担（DevSecOps）が重要になります。開発者は最初から参加し、より安全で優れたコードを作成するために自分の役割に責任を持てるようにサポートされなければなりません。

開発者は自分のコードにあるSQLインジェクションのバグをどのように修正すべきでしょうか？

SQLインジェクションの識別と修正方法を学びたい開発者のために、包括的なガイドを用意しました。選択したプログラミング言語（COBOLも可）を使ったゲーム性のある課題が含まれており、すべての開発者がより安全で高品質なコードを作成するのに役立つ基礎的な学習ができます。