ハッピーバースデー SQL インジェクション、潰せないバグ

この記事のバージョンは、最初に掲載されました ヘルプネットセキュリティ。ここで更新され、シンジケートされました。

‍

サイバーセキュリティの実務に携わっている場合（コードにある程度の知識が必要）、SQLインジェクションについて何度も何度も考えなければならない可能性があります。これはよくある脆弱性であり、最初に発見されてから数週間でかなり簡単な解決策がわかったにもかかわらず、ソフトウェアを悩ませ続け、展開前に検出されないままにしておくと、攻撃者になりそうな人にわずかな機会を与えてしまいます。

2020 年 12 月 13 日は SQL インジェクションが 22 周年を迎えました。この脆弱性は十分に古くから存在していますが、私たちはこの脆弱性を永久に潰すのではなく、弱体化させようとしています。今年8月、Freepik Companyはこうしたことを明らかにしました。 SQLインジェクションの失敗の犠牲になった 830万人のユーザーのアカウントが危険にさらされましたその多くはサードパーティのログイン（Google、Facebookなど）を利用していましたが、数百万人がユーザー名とともに暗号化されていないパスワードが公開されていました。彼らや他の多くの人々にとって悲しいことに、これらのインシデントによる影響は大きな頭痛の種であり、ユーザーベースとの信頼関係を再構築することは長期的なプロセスです。

このマイルストーンをレガシー問題と考えられる問題で「祝う」一方で、少し詳しく見てみましょう。なぜそれが次々と現れ続けるのか、なぜまだそれほど危険で、OWASP Top 10 のトップの座から何年も離れていないのか、そして、その比較的単純な修正がソフトウェア開発の一般的なベンチマーク標準に含まれていないのはなぜか。

2021年になってもSQLインジェクションが依然として重要なのはなぜですか？

最近注目を集めた侵害をざっと見てみると、 FireEyeに対する壊滅的なサイバー攻撃は、驚異的なレベルの洗練さを明らかにしています。これは、FireEye強盗のためにカスタマイズされたように見えるさまざまな高度な手法を利用した、高度に調整された国家間の攻撃でした。FireEyeのCEO、ケビン・マンディアは声明の中で次のように述べました。

」攻撃者は、特に標的を絞って世界クラスの機能を調整し、 攻撃 ファイアーアイ。彼らは運用上のセキュリティについて高度な訓練を受けており、規律と集中力をもって業務を遂行しています。彼らは、これまで私たちやパートナーが見たことのない、斬新な技術の組み合わせを使用していました。」

これはどのCISOにとっても悪夢のような燃料であり、FireEyeにこのようなことが起こった場合、多くの企業が実際にどれほど脆弱であるかがわかります。

... ただし、均等です ひどい 平均的な組織向けのニュース。FireEyeは地球上で最も有名なサイバーセキュリティ企業の1つであり、攻撃が成功するには、首謀者レベルの詐欺師が手持ちのものをすべて組織的かつ大規模な実行に投げ込む必要がありました。多くの企業にとって、首謀者をまったく必要とせずに、単純なバグをかなり迅速に悪用すれば、儲かるデータ漏えいが発生する可能性があります。そして、SQL インジェクションは後者の一般的な例で、ダークウェブで手っ取り早く金を稼ごうとしているスクリプト開発者が今でも利用しています。

2020 年 5 月には、 ある男がクレジットカードの売買とハッキングの罪で起訴された彼が何十万ものアクティブなクレジットカード番号を保存しているデジタルメディアで発見されたとき。多くの企業と数百万の顧客を危険にさらしたオペレーションで、SQL インジェクション技術を使用してそれらの情報をすべて収集しました。

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

開発者がそれを存続させている理由 (そしてなぜそれが彼らのせいではないのか)

SQLインジェクションは簡単に修正できるので、まったく導入しないようにコードを書くべきだと言い続けています。ほとんどのことがそうであるように、正しい方法を教えられて初めて簡単になります。

ソフトウェア開発プロセスでは、ここからホイールがぐらつき始めます。開発者は同じ過ちを犯しており、SQL インジェクションがコードベースに侵入するなどの脆弱性が繰り返し発生しています。しかし、これは驚くべきことではありません。ほとんどのエンジニアは、どちらかといえばセキュア・コーディングについてあまり学んでいないまま、学位を取得しています。ほとんどの実地研修は、特にセキュリティが彼らの役割においてビジネス上の優先事項と見なされていない環境では不十分です。

開発者にセキュリティを気にかける理由を与えたり、セキュリティへの意識を高め始めるための強力なプラットフォームを提供したりしているわけでもありません。コーディングパターンが貧弱なため、SQL インジェクションのようなバグが残っているため、開発者のセキュリティ意識にもっと重点を置き、より高水準の安全で高品質なコードを書く時間を与える必要があります。セキュア・コーディング・パターンの作成には時間がかかりますが、そこに費やす時間が効率化につながり、プロセスの後半で非常に貴重な成果が得られます。

SQLインジェクション葬儀は行われますか？

葬儀のメタファーは少し病的ですが、実際には、SQL インジェクションが永久に保たれれば、機密データの方が安全です。しかし、その前に、私たちはもう少し誕生日を祝うことができると確信しています。なぜなら、予防的セキュリティと安全なコーディングに重点を置く文化は、棺桶を釘付けにするほどには進化していないからです。

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

「簡単な」エクスプロイトを永久に阻止したいのであれば、開発プロセス（こんにちは、DevSecOps）におけるセキュリティに対する責任分担が不可欠です。開発者は最初からその道に足を踏み入れ、より安全で優れたコードを作成する責任を果たすよう支援されなければなりません。

開発者はコード内の SQL インジェクションのバグの修正にどのように取り組むべきでしょうか?

まとめました 総合ガイド SQL インジェクションを特定して修正する方法を学びたい開発者向けです。自分が選んだプログラミング言語 (COBOLも含む!) でゲーム感覚のチャレンジを完遂できます。これにより、すべての開発者がより安全で高品質なコードを作成するのに役立つ、いくつかの優れた基礎知識が得られます。