AppScan and the OWASP Top 10: A Focus on SQL Injection の翻訳版です。
AppScan と OWASP Top 10: SQLインジェクションに焦点を当てた考察
2020年11月2日
著者: Rob Cuddy / Global Application Security Evangelist 共著: Neil Jones / Senior Product Marketing Manager for HCL Software's AppScan solution
もし、あなたがアプリケーションセキュリティに長く携わってきたならば、OWASP Top 10 のことを聞いたことがあるでしょう。OWASP Top 10 は、2010 年に開始され、2013 年と 2017 年に更新されました。今日では、アプリケーション開発者や Web アプリケーションセキュリティの専門家が注意しなければならない最も一般的な脆弱性のタイプの「デファクトスタンダードなリスト」であると広く考えられています。実際には、API や IoT に特化した OWASP Top 10 リストがあるほどの標準となっています。
この定期的なブログシリーズでは、OWASP Top 10 リストの中で最も広まっている脆弱性を見ていきます。今回の記事では、OWASP Top 10 の脆弱性の中で最も普及しているタイプである SQL インジェクションを検証します。また、効果的なアプリケーション・セキュリティ・プログラムがどのようにしてこの脅威に対処できるかを検討します。
SQL インジェクションの定義
OWASP によると、「SQL、NoSQL、OS、LDAP インジェクションなどのインジェクションの欠陥は、信頼されていないデータがコマンドやクエリの一部としてインタプリタに送られたときに発生します。攻撃者の敵対的なデータは、インタープリタを騙して意図しないコマンドを実行したり、適切な権限なしにデータにアクセスしたりすることができます。" インジェクションとは、データフローを利用して、意図しないことをするためにデータフローを利用することです。 誰もが耳にしたことのある一般的な例としては、Web ページのフィールドでシングルクォートを使用して SQL クエリを悪用しようとすることがあります。
SQL インジェクションの影響
最近の Ponemon Institute の「DevOps 環境におけるアプリケーションセキュリティ」調査では、回答した組織のビジネスクリティカルなアプリケーションの 67%が、継続的に脆弱性のテストを行っていないことがわかりました。そのため、SQL インジェクションのような脆弱性の潜在的な影響は計り知れません。そのため、著者の Pallavi Dutta 氏による最近の SecurityBoulevard.com の記事では、大規模な SQL インジェクション攻撃が、英国の通信会社、多数の大学や政府機関、さらには E コマース企業など、幅広い業界の組織に影響を与えていることを指摘しています。
しかし、なぜ SQL インジェクションはまだ存在するのでしょうか?
実際のところ、SQL インジェクションは文字通り何十年も前から公に議論されてきましたが、なぜこれほど多くの組織にとって未だに問題となっているのでしょうか? 現実には、SQLインジェクションを防止することはそれほど難しいことではありませんが、ソフトウェアがデータベースと通信し、ユーザーが提供した入力を使用している場所の数は膨大なものです。
「アプリケーション・パラノイア」ポッドキャスト・シリーズのシーズン 1、エピソード 10 では、アプリケーション・セキュリティの専門家で影響力のある Tanya Janca 氏に、誰もが二度と書いてはいけない脆弱性について尋ねたときに、この重要性を再認識しました。 Tanya は言いました。
「OK、それで、私のお気に入りの脆弱性で、私が修正しようと思っているもの。私はこの質問をひっくり返してみたいと思います。 なぜなら、すべてのプログラマが入力の検証をあるべき場所に配置し、入力の検証をきちんと行っていれば...それは膨大で膨大で膨大な量の脆弱性を修正することになり、この世のものとは思えないほどのものになるからです」。
インジェクション攻撃への対処
インジェクション攻撃の潜在的な影響を考えると、HCL AppScan はどのようにしてインジェクションを見つけ、それに対処しているのでしょうか?アプリケーションをスキャンする際には、あらゆる種類の可能な構成を試し、インジェクション攻撃が可能であることを示すものを探して出力を検査します。例えば、どのような種類のエラーメッセージが表示されているか、また、これらのメッセージがアプリケーションがどのように動作するかについての洞察を提供しているかどうかを調べます。私たちは良性のインジェクションを試してみて、それが「うまくいく」かどうかを確認し、開発チームがその存在に気づくことができるように、それらの試みの成功を報告します。また、発見された脆弱性の種類と、なぜそれが問題なのかについての情報を提供し、理解を助けます。
上図1は、HCL AppScan のスキャン設定パネルを示しています。 ここでは、ユーザーはテストしたい問題の種類を正確にカスタマイズすることができます。この例では、「Developer Essentials」プロファイルを選択することから始めました。これは、開発者が潜在的な問題について迅速にフィードバックを得ることができるように、成功する確率の高い多くの一般的なテストで構成されています。次に「インジェクション」という単語を検索して、選択されていない可能性のある他の関連テストを探し出し、それらを含めることができるようにしました。このような柔軟性により、テストに磨きをかけることができます。
インジェクションの問題が見つかったら、どのように対処すればいいのでしょうか? ポッドキャストシリーズ「アプリケーションパラノイア」のシーズン1、エピソード 9 では、「クリスに聞く」のセクションで、クリス・デュアーが素晴らしい洞察を提供してくれました。彼が与えた強力なアドバイスは以下の通りです。
"ベストプラクティス 1: 準備された文を使うこと。 実行クエリを使うのをやめろ...実行クエリや実行文を見るたびに、私の魂の一部が死んでしまう。 パラメータがなくても気にしない...パラメータを持たせて、それを持たせて、絶対にステートメントを使わない。 常に準備された文を使う。 常に準備されたクエリを使用する.... それは文字通りただの
"ベストプラクティス 1: 準備された文を使用する。 クエリを実行するのをやめてください... クエリの実行や文の実行を見るたびに、私の魂の一部が死んでしまいます。 パラメータがなくても気にしません... パラメータを持たせて、ステートメントを使わないようにします。 常に準備された文を使う。 常に準備されたクエリを使え.... 文字列を連結するクエリを書くのをやめろ。 SQL インジェクションの問題の 99.9%はそれで解決する.... 動的な SQL を使うのはやめて、動的な SQL でなければならない場合は、準備された文を使うようにしましょう。
要約すると、脆弱性が特定されたら、それに対処するには、通常、以下の2つのカテゴリーのいずれかに分類されます。
ユーザーからの入力を利用した動的なクエリの記述を排除する
ユーザーが提供した入力が利用される場合、"悪い" SQL がクエリの残りの部分に影響を与えるのを防ぎます。
これら 2 つのカテゴリーに対処するには、パラメータ化されたクエリ、ストアドプロシージャ、許容される入力のリストの 定義、ユーザーが入力した入力のエスケープなどを使用する必要がある。 図 2 で示されているように、HCL AppScan は、発見された脆弱性に関する具体的な情報を、潜在的な修正案の中でこれらの戦略を使用して提供しています。さらに、OWASP は、これらの様々な方法をどのように使用するかを例示する素晴らしいリソースを提供しています。
詳細
潜在的な SQL インジェクション攻撃に対抗する最善の方法は、効果的なアプリケーション・セキュリティ・テスト・プログラムを利用することです。アプリケーション・セキュリティ・テクノロジーをご自身でテストしたい場合は、HCL AppScan の 30日間の無料トライアルにご登録ください。