詳細を見る

KLOCWORK | ホワイトペーパー | 2013 年 12 月
インジェクション攻撃に対する防御
一般的なセキュリティーの脆弱性の理解およびその軽減
我々が日常生活において日々ますますソフトウェアに頼るようになると、
ソフトウェアをできる限り最
も安全な方法で実装することが必須となってきます。
ソフトウェアは我々が仕事に使うコンピューターを制御しているだけでなく、電話、自動車そしてイン
スリン注入ポンプやペースメーカーも制御しています。それは複雑であったり危険な作業を実施する
マシンや、現在の航空機におけるフライトコントロール装置等のすでに人間が直接管理しなくなった
ものを制御するために利用されています。
また、電気、水、
ガス、輸送、通信その他を提供するすべての
ネットワークを管理しています。
こうしたすべてのデバイスやシステムは、見えないところでますます
相互接続されていっており、
「ネットワーク効果」の進展をもたらしています（Wikipedia、2013 年）。
こうした状況に対して、デバイスが適切に作動することを期待し、使用されているソフトウェアの技術
的な影響について考えたくないエンドユーザーという状況が相まって、悪意ある攻撃に対する耐性の
あるコードを書くことの重要性が理解されてきています。
このシリーズのホワイトペーパーでは、弊社はソフトウェア開発業界を現在蝕んでいる最も一般的な
セキュリティー上の脆弱性について検証し、静的コード解析（SCA）による検知の異なる方法を示して
ゆきます。
弊社は脆弱性を次の論理的な「分類」に整理してゆきます。それらは、インジェクション攻撃、バッファ
操作、情報漏洩、暗号化ミスそしてセキュリティーの構成ミスです。それぞれの分類に対し、弊社は以
下を実施します：
»
»
»
弱点の詳細な説明の提供
エンドユーザーや開発者への提示方法
各問題の解決に役立つ軽減戦略の説明
セキュリティー上の脆弱性
セキュリティー上の弱点は、ユーザーの PC、
タブレットや携帯端末からアクセスできるソフトウェアで
今日最も頻繁に生じています。
Web ベースのアプリケーション、ネットワーク対応またはネットワーク制御可能なデバイス、そして幅
広く利用されているモバイル系ソフトウェアが最もターゲットとなっているアプリケーションです。
これ
に続き、オペレーティング・システム、Web サーバー、そしてプラグインやエクステンションを含むブラ
ウザ・ベースのソフトウェアがターゲットとなっています。
こうした脆弱性の原因は、
ソフトウェアの誤使用や想定されていないアクションが実施されることを開
発者が念頭に置いていないことから通常生じるものです。根幹にある問題は、最初にスキャンされお
らず、有害な側面が排除されていないアプリケーションのインプットやコンテンツをブロックする安全
なインプット処理の欠如がしばしば原因となっています。
このテクニックは、
よく
「インプット・サニタイジング」
と呼ばれており、実装されるアプリケーションやタスクに応じて異なる形態
となっています。例えば、0 から 9 までの数字と、A から Z までのアルファベットだけを許可するよう設計することができます。
しかしながら、
これはかなりシンプルな一例に過ぎません。今日のアプリケーションは、幅広いソースからのインプットを受け入
れる必要があり、
これにより悪意あるアクションを検知することが一段と難しくなってきています。例えば、現在の Web アプリケ
ーションはエンドユーザーからのインプットを受け入れるだけでなく、データベースのデータも読み取り、写真やドキュメント等
のアップロードされたファイルを受け入れ、サードパーティーの Web サービスにリンクし、
コンピューターやネットワークの名
前を解決するためにオペレーティング・システムの API やフレームワークを利用し、LDAP サービスその他と統合されてゆきま
す。
これにより、
アプリケーションへのインプットのすべてのソースを単純に信用するわけにはいかなくなってきています。
脆弱性の分類
OWASP の上位 10 種類や7つのセキュリティー違反分野（Mitre、2013 年）等のよく知られている分類を含め、
ソフトウェアの脆
弱性を分類する異なる方法があります。
このシリーズのホワイトペーパーでは、
こうした分類を利用し、共通する主要な特徴や基準が自動解析で対処される方法に基
づいてグループ化しました。
このシリーズの最初のホワイトペーパーは、インジェクション攻撃に対する脆弱性として規定されるソフトウェアの脆弱性の分
類に重点を置いています。
これは、
アプリケーションやコードに特定のコマンドを注入し、
自らに代わってこれらに不健全な行為
を実行させる攻撃者の能力について言及しています。
こうした攻撃は、通常は後処理のためにユーザーのインプット
（データ）を要求するポイントでアプリケーションを悪用します。イ
ンジェクション攻撃に対する脆弱性における最も一般的なものには、SQL インジェクション、
コマンド・インジェクション、XPath
および LDAP インジェクションなどがあります。HTML/スクリプト・インジェクションも一般的なもので、
クロスサイト・スクリプテ
ィング（XSS）
という呼称で良く知られています。
こうした弱点のすべてが悪用され、同様の方法で軽減されます。
脆弱性の軽減
セキュリティーの脆弱性を発見・修正することは既存のソフトウェア開発ライフサイクル（SDLC）に組み込むことのできるプロセ
スです。あらゆるタイプの脆弱性に関して、
このプロセスには次の 3 つのステップが関係してゆきます：
1.
2.
3.
問題の検知
問題の把握
問題の是正
問題の検知
このプロセスにおいて最も困難で時間のかかるステップは、脆弱性の検知です。従来の検知手法はしばしば手動でのコード点
検、通常シナリオの一部のみを網羅するテスト一式の作成や、チェックイン後のコード解析に関係するものとなっていました。
こ
うしたアプローチは時間やリソースの双方の点から非効率なもので、脆弱性を取りこぼすことにつながりやすいものです。最新
の検知アプローチは、はるかに費用対効果があり信頼性の高いものです。
脆弱性の検知を自動化かつ包括的なものとするため、静的ソースコード解析が標準となってきています。SCA はプログラム実
行に代わるコンピューターソフトウェアの自動解析です。
これはネイティブのビルド理解、
ソースコードのコンパイル、抽象構文
木（AST）の検証、およびすべての制御フローパスおよびデータオブジェクト・ライフサイクルのモデル化シミュレーションにより
実現されます。
SCA ツールの現在の世代は、過去 10 年の間にかなり成熟してきており、現在では、
ここで指摘されたインジェクション攻撃に
対する脆弱性を含め、数多くの脆弱性を発見し、他方でプロセスにおいて小量のコンピューティング・リソースしか消費しませ
ん。
これは、SCA ツールがタイピングのエラーだけでなく本物の問題を見つけることができることを意味しています。
こうした問
題は、
コストを削減するソフトウェア開発ライフサイクル（SDLC）において早期に発見が可能であり、その解析結果は既存の開
発環境に統合することができ、開発者の既存のワークフローに追加のステップやツールを追加せずに済むようになっています。
主流の SCA エンジンは、
ランタイム予想のモデルベースのシミュレーションに加え、
コードの注入（バッファオーバーフロー）、
DoS 攻撃（メモリリークや整数汚染）、初期化されていないデータ
（データ注入）、文字列汚染、および同時発生する関連問題を
検知するため、制御およびデータフロー解析を活用します。
こうしたエンジンは、
ファイルシステムやデータベース等データがシ
ステムに入るポイントやその最終ポイントを判断するため、手続き間ベースでコードを追及してゆきます。
こうしたソースとシン
クは、
ソフトウェア解析の場合にはパズルの重要な一片となるものです。
SCA ツールの最新の世代は、既存のコードのエラーを発見するだけでなく、開発者がタイプする際にセキュリティーの弱点も
特定します。
コードが書かれる最中にその各行を解析する。
これはまるでソースコードのスペルチェッカーのようですが、チェッ
クイン前に安全なコードが開発されることを保証する上で役に立ちます。
インジェクション攻撃に対する防御 | Klocwork ホワイトペーパー | 2
静的コード解析ツールは、安全なソフトウェア開発ライフサイクルの重要な一部となっています。実際、Microsoft は開発者が「
導入フェーズ」の一環として静的解析を実施することを推奨しています。特に、SDL #10 は以下のように述べています：
「コンパ
イル前にソースコードを解析することでセキュリティーのあるコードレビューのスケーラブルな手段が提供され、安全なコーデ
ィング方針が実践されていることを保証ことを支援します。」
このホワイトペーパーに規定される脆弱性のそれぞれについて、
ソースコード解析により検知することができます。
セキュリティー上の問題の理解および修正
検知された問題に対処するため、開発者はその問題、その仕組み、その内容そして修正に使える手段を完全に理解する必要が
あります。
このセクションでは、直面しうるインジェクションフローの様々なタイプに関する概要を提供します。
SQL インジェクション攻撃に対する脆弱性
最も一般的なコード悪用は、SQL インジェクション攻撃（アプリケーションにデータベース・エンジンにより実行される SQL 文を
注入し、
アプリケーションに代わってコマンド（挿入、
アップデートおよび削除）を実行することでデータを抽出）
です。
こうした攻撃は、他のタイプのものと比べ Web ベースのアプリケーションが多いことから特に一般的なものとなっています。
また、
開発者の経験度と熟練度は、
こうしたクラスのソフトウェアでは低いことがあり、
さらなる脆弱性が生まれることとなっています。
SQL インジェクション攻撃に対する脆弱性は、通常は文字列に返還された未検証のユーザー・インプットでデータベース・エン
ジンの実行 API に直接渡されるものの連続体としてソースコード中に存在しています。結果として、個別に対処できる2つの欠
陥が存在することになります。それはユーザー・インプットの経路と SQL 実行処理であり、SCA は双方の経路の特定を支援する
ことができます。
図 1 | SQL インジェクションフローの例
例えば図 1 で、"account" 変数がリクエストパラメータ "req" から直接割り当てられていることを確認できます。
これは、そのネイ
ティブなステータスからチェックや修正がされていないものです。次にこれは、新規 SQL コマンドを作成するため、大量の SQL
SELECT コマンドとともに "query" 変数に渡されます。そしてデータベース・エンジンを実行する "executeQuery" API へ直接渡
されます。
最後に、その結果は結果の内容に係わらずコールへ戻されます。
どのポイントでもデータの妥当性に関するチェックは実施され
ていません。
パラメータ化クエリの活用
こうした脆弱性を緩和するためにまず重要なことは、データベース・エンジン API に渡されることになる SQL 文の構築のため、
「パラメータ化クエリ」を利用することです。
主要な言語のすべて、
とりわけ主流のものについては、
これに対する何らかのサポートが提供されています。
クエリ・パラメータ
化の虎の巻により、必要となるライブラリを特定します。
インジェクション攻撃に対する防御 | Klocwork ホワイトペーパー | 3
上記の例では、Java "prepareStatement()" メソッドが SQL コールの悪用に対処することになります。
これは、
このクエリがプレ
ースホルダ値でデータベース・エンジンにより事前コンパイルされ、SQL コードをデータから分離するためです。
こうしたプレー
スホルダ値は、
アプリケーション実行中に更新され、データはプレースホルダの位置に渡されます。
これらは、既存のコンパイル
済みクエリに対する値として処理されるものであり、
クエリの修正版としてではありません。
これはSQL インジェクションを防止
する仕組みとして主軸となるものです。
パラメータの追加検査の実施
この関数に渡されるパラメータの追加検査も、SQL インジェクション攻撃の防止に役立ちます。
先の例では、関数に渡されているコンテンツのタイプと長さを点検することが賢明であると言えるでしょう。文字列の範囲を数
字だけに限定することも、攻撃を制限することになります。
結果セットが妥当かどうかを判断するための検査も、
こうした脆弱性を悪用しようとする攻撃者の手段を封じることになります。
例えば、
クエリが何百行も返す場合に、それは悪意があったり、エラーのあるクエリが作成され、エラー状態が返されていること
を示唆している可能性があります。
コマンド・インジェクション攻撃に対する脆弱性
図 2 に示されている 2 つ目の例では、
コマンド・インジェクションフローを分析してします。
図 2 | コマンド・インジェクションフローの例
QWAP ページからのこのシンプルな例では、ユーザーによるインプットが cat コマンドに連結された後で 'system()' コマンドに
渡されることを確認することができます。
プログラムにセミコロンで分離される追加コマンドを提供することで、
任意のアプリケーションが実行されます。
例えば、
"; rm –rf /"
をインプットすると、ルート・ディレクトリ全体を削除することになります。
このアプリケーションが高次元の権限で実行された場
合、その結果はシステムにとって破滅的なものとなりえます。
システム API のコールを避ける
脆弱性を緩和する最適な方法は、システム API を一切コールしないことです。
プログラミングの観点からは、実装はかなり面倒
ですがシステムとのやり取りにおいて、
もっとリスクの低い方法があります。
悪意のあるインプットが実行できないことを保証
アプリケーションに代わってコマンドを実行するため、オペレーティング・システムに直接コールを実装しなければならない状
況においては、悪意のあるインプットが実行できないことを保証する必要があります。最も厳格なサニタイジング手法、
できれば
「一致検査」
またはホワイトリスト・アプローチを利用してインプットを検査することでこれを実現することができます。
ブラック
リストは既存の制約の周囲にある作業へ新たなテクニックが適用されることは想定していないことに注意してください。
クロスサイト・スクリプティングに対する脆弱性
SQL およびコマンドのインジェクション攻撃に対する脆弱性に加え、
クロスサイト・スクリプティング（XSS）はアプリケーションと
りわけ Web ベースのアプリケーションに対する最も一般的な形態の攻撃の一つです。
XSS が「インジェクション」のグループに含められている理由は、それが HTML や JavaScript をユーザーによるインプット経路
から Web アプリケーションに注入する同様のテクニックを利用しているからです。XSS と SQL/コマンド・インジェクションの主
な違いは、XSS がデータベース・エンジンやオペレーティング・システム等の別のリソースを利用するのではなく、
ブラウザによ
って処理または実行される点にあります。
インジェクション攻撃に対する防御 | Klocwork ホワイトペーパー | 4
XSS 攻撃には 2 つの主要なタイプがあります：それは「蓄積型」
（持続型）
と
「折り返し型」
（非持続型）です。XSS インジェクシ
ョンの持続型とは、特定のユーザーを特に対象とすることなく、事後の拡散に備えてサーバー上に格納された攻撃を意味して
います。
これはまた、折り返し型の攻撃の主要な制約ともなります。XSS インジェクションの折り返し型はもっと一般的なもの
で、HTTP クエリや HTML フォーム送信等、Web クライアントによって提供されたデータにより開始される攻撃のことを意味して
います。
折り返し型 XSS 攻撃でよくあるタイプの一つは DOM によるものです。
クライアント再度にあるブラウザの DOM が攻撃者のス
クリプトによって改変された時こうした攻撃が生じます。そしてこれは、DOM ベースの攻撃とサーバーサイドで生じる他の攻撃
との主要な相違点となっています。
図 3 | XSS フローの例
インプットのサニタイジングと認証、ならびにアウトプットのエンコード
XSS に対する脆弱性を緩和することは、Web ページに未検査のインプットを注入する多くの方法があるために、
より複雑な作
業となります。図 3 では、SCA が検知する脆弱性のあるインプットの形態を示し、図 4 ではこのフローを緩和する一つの方法を
示しています。
図 4 | 修正された XSS フローの例
インプットのサニタイジングと Web ページの不正な位置へ注入されないことの認証に加え、
アウトプットを安全なフォーマット
へエンコードすることも良い方法です。事実、
このアプローチは、
アウトプット・タイプへの位置の置換は極めて小さいものであ
ることから、ずっと簡単な方法です。
こうした推奨テクニックのすべては、
クエリのパラメータ化の虎の巻に記載されています。
「XSS 防止」教育となると OWASP は
世界標準であり、
アプリケーションからこうした脆弱性を適切に排除する方法について豊富な情報を提供しています。
XPath インジェクション攻撃に対する脆弱性
XPath と LDAP インジェクション攻撃は、その性質において先の述べた SQL やコマンドのインジェクション攻撃に極めて類似し
たものです。XPath インジェクション攻撃は、Web アプリケーションが重要な情報の格納のために XML データを利用する際に
生じうるものです。
この攻撃により、ページやサイトの背後にある XML データ構造を判断するために意図的に不正な形式のイ
ンプットが Web サイトに送信され、攻撃者や他の人間へ公開を予定していなかったデータを返す XPath クエリを作成します。
インジェクション攻撃に対する防御 | Klocwork ホワイトペーパー | 5
このようにして、攻撃者は論理的に任意の親子ノードを返しデータを記録することで、XML ファイル全体を取得することができ
ます。
ちょうど SQL インジェクション攻撃のように、XPath インジェクション・テクニックは言語が過剰に広範囲にわたるクエリ結
果を出力するよう信じさせるものです。
データのサニタイジングおよび XPath の事前コンパイル
XPath インジェクション攻撃に対する脆弱性を緩和するため、SQL インジェクションについて説明したようにインプットのサニ
タイジングが必要となります。
また、事前コンパイルした XPath を利用する必要があります。
これは事前に準備された構文に類
似したもので、
ここで前もってコンパイルされインプットに限定してパラメータを許可します。
LDAP インジェクション攻撃に対する脆弱性
LDAP インジェクション攻撃は、
ユーザーによるインプットから LDAP コマンドを構築するアプリケーションに限って適用されます。
ログインを企業の社内ネットワークと互換性のあるものにするため、
アプリケーションを LDAP サーバーを統合したい場合があ
ります。
アプリケーションのインプットが適切にサニタイジングされていない場合、攻撃者はアプリケーションを騙して、ユーザ
ー資格や組織構成を含むセンシティブな情報をサーバーから返させることができます。
これに加えて、脆弱性のあるログイン実
装により、誰でもログイン用に適切な LDAP コマンドを作成することができてしまいます。
ホワイトリストの活用
この脆弱性を緩和する最適な方法は、必要とされる文字にだけホワイトリストを実施することです。
これにはインプットが識別
名（DN）の一部として、あるいは検索クエリの一部として利用される場合に応じて、数字やアルファベットではない一定の文字も
含まれます。
結論
今日のコンピューター・ソフトウェアに存在するセキュリティーの脆弱性には多くの種類や分類が存在しています。限られた時間
とリソースでは、
アプリケーションの意図に反してユーザー・インプットが利用されるすべての方法を把握、予想または回避する
のは困難です。
こうした脆弱性をできる限り早急に把握・排除することで、重要な機能を実行しているソフトウェアが悪用されな
いことを保証します。
静的コード解析ツールは、既存のコードベースならびに新規作成中のコードからこうした種類の問題を特定、把握および排除
することを支援することができます。
さらに PC に SCA ツールを入れておくことで、既存のミスから学ぶことに役に立ち、
これに
より自分と自分のチームの生産性を向上させ、
より安全なソフトウェア・ソリューションにつなげることができます。
インジェクション攻撃に対する脆弱性および SCA に対する詳細については、以下のリソースを確認してください：
無料の CWE-77 インジェクション攻撃に
対する脆弱性オンライン・コース を受講し
てインジェクション攻撃に対する脆弱性の
別の例やタイプについて学びましょう。
Klocwork 開発者ネットワーク にアクセス
して入手可能な SCA チェッカーのリスト
や、
これまで知らなかったセキュリティー
の脆弱性を克服する最適な方法を提示し
ている例を確認しましょう。
Klocwork Insight™ の 無料トライアルに
登録して 安全なコードを簡単に書く方法
について学びましょう。
Klockwork について
アプリケーションのセキュリティーの世界において、セキュリティーに取り組む開発者と企業は競争力を高めることのできるツ
ールを必要としています。Klocwork は、開発者が安全かつ信頼性が高いソフトウェアをもっと容易に迅速に開発することを可能
とするる注目すべきデスクトップ ツールにより、
こうした必要性に応えています。Klocwork のユニークな SCA ツールは、開発者
がコードを書く際に正確かつ信頼性の高い解析を実現し、
ソフトウェアのビルドへ進む前に潜在的なセキュリティーの脆弱性、
信頼性の問題または規約違反を認識します。追加的なデスクトップ ツールによりコードレビュー、
リファクタリングおよびアー
キテクチャー解析が簡略化されます。
自動車業界、消費家電、ゲーム業界、医療技術、国防産業および航空業界、モバイル端末や
通信業界における最大手ブランドを含む 1,100 社以上の顧客が、
日々こうしたツールを活用してソフトウェアをより安全かつ信
頼性の高いものとしています。誇りを持てるアプリケーションの構築。詳細については www.klocwork.com
Klocwork は米国およびその他の国における Klocwork Inc. の登録商標です。他のすべての名称は、それぞれの会社の商標また
は登録商標です。
米国：
15 New England Executive Park
Burlington, MA 01803
© Klocwork Inc. All rights reserved.
カナダ：
30 Edgewater Street, Suite 114
Ottawa, ON K2L 1V8
電話：+1.866.556.2967
ファクス：+1-613-836-9088
www.klocwork.com