XML External Entity Injection攻撃（XXE injectionと略されることもある）は、発生から数年経っても話題になっている古典的な脆弱性に比べると、比較的新しい攻撃です。しかし、現在、ハッキングコミュニティの間では非常に人気があり、成功例を重ねることでさらに人気が高まっています。

実際、OWASPは、XXEインジェクションを、サイトが注意し、積極的に防御する必要があるトップ10の脆弱性の1つとして挙げています。しかし、心配する必要はありません。XXEインジェクションは、サイバー攻撃で使用されている他のエクスプロイトよりも強力なものではありません。ただ、少しだけ新しく、少しだけ理解されていないだけです。防ぐことができますし、実際に完全に止めることもできます。

このエピソードでは、以下のことを学びます。

• 攻撃者がXXEインジェクションを使用する方法
• XXE注入が危険な理由
• この脆弱性を防ぐことができる技術

攻撃者はどのようにXXEインジェクションを引き起こすのか？

XXEインジェクションの脆弱性は、悪意のあるユーザーがXMLコードを送信する機能を与えられた場合に発生する可能性があります。悪意のあるユーザは、この機能を使って、外部のエンティティへの参照を作成します。この外部参照とコードは、デフォルト設定のXMLパーサーや、脆弱な設定のXMLパーサーをすり抜けるように設計されています。

この攻撃者は、XML規格がエンティティの概念をある種の記憶装置として定義しているが、その記憶装置は外部にも内部にもあるという事実を利用しています。適切に使用すれば、XMLプロセッサがリモートリソースにアクセスできるようになります。多くの場合、攻撃者はこの機能を利用して、Webサイトの内部構造を探ったり、リモートリソースにアクセスしようとする大規模なシステムプロセスを起動してサービス拒否攻撃を行ったり、さらにはローカルホストから自分がコントロールするリモートホストにデータをダンプしたりするなど、XMLデータベースに含まれるパスワードや個人情報などの重要なデータを流出させるのに適した手法となっています。

攻撃に使われる実際のコードは、実体のある機能を利用するだけの非常に単純なものであることが多い。例えば、ハッカーがマスターパスワードファイルにアクセスすることができるようなものです。

<!ENTITY hackwithxxe SYSTEM file:///etc/password>

なぜXXEインジェクションは危険なのか？

XXEインジェクション攻撃が非常に危険であり、また蔓延している理由はいくつかあります。1つは、現在あまり理解されていない脆弱性であること。そして、この脆弱性を悪用することで攻撃者が得られる利益は相当なものです。1つは、持続的な攻撃者が内部ネットワークのすべてのパスをゆっくりとマッピングしたり、ポートをスキャンしたりできることです。これにはかなりの時間がかかるかもしれませんが、ハッカーは信頼されたXMLパーサーによってクリアされたXMLコードをサーバーに送信しているだけなので、ターゲットネットワーク上のアクティブな防御によってハッカーの活動が発見される可能性はほとんどありません。

いったんマップが作成されると、攻撃者は同じXXEインジェクション技術を使用して、必要なファイルを取得し、直接情報を盗んだり、有効なユーザー認証情報を侵害して二次攻撃に利用したりすることができます。最後に、ただ騒ぎ立てて悪意を持ちたい攻撃者は、サービス拒否攻撃を誘発し、システムを停滞させるように設計された遠隔地のリソースにアクセスするようにアプリケーションに命令するといったことができます。  

XXEインジェクション脆弱性の解消

XXEインジェクション攻撃が急増しているため、多くのXMLパーサーは外部エンティティ（DTDと呼ばれることもある）をデフォルトで完全に無効にし始めています。このような場合、重要なのは、その機能を有効にしないことです。

しかし、DTDを許可しているパーサーでも、その機能を無効にすることができます。一般的には、完全にブロックするためには以下のような記述が必要になりますが、必要なコードを正確に把握するためには、ローカルフレームワークのドキュメントを確認してください。

factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true)。

セキュリティの原則に従って、すべてのユーザーの入力をサニタイズし、アプリケーション全体のフィルタを使用して検証する必要があります。GET や POST のパラメータ、HTTP ヘッダー、Cookie も忘れずに入れてください。また、パーサーに処理させたい特定の DTD やコマンドのホワイトリストを作成し、それ以外のものを禁止することもできます。

ホワイトリストやフィルタリングは有効ですが、XXEインジェクション攻撃が増加しているため、機能が必要でない場合はDTDサポートを完全に無効にすることをお勧めします。

XXE Injectionsの詳細情報

さらに、OWASPがXXEインジェクション攻撃についてどのように述べているかを読んでみてください。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御知識を試すこともできます。この脆弱性やその他の脅威への対策については、Secure Code Warrior ブログをご覧ください。

今回のようなブログや記事では、句読点が読者の助けになります。例えば、ピリオドは文章の終わりを読者に伝えますし、コンマはリストの中で記事を区切ったり、アイデアを分けるために固い間を入れたりします。このブログのようによく書かれたブログでは、句読点はほとんど目立たず、私たちが何年も前に処理することを学んだ標準的な背景コードの一部に過ぎません。

でも、もしハッカーがこの記事に入り込んで、変な句読点を間違った場所に挿入したらどうなるでしょう？こんな感じで。

テキストを変更することなく、情報を処理することが非常に困難になります。

これは基本的にCRLFインジェクション攻撃で起こることです。CRLFとは、キャリッジリターンとラインフィードの略で、行の終わりを示すために単独または組み合わせて使用されます。攻撃者が既存のアプリケーションにCRやLFのコードを挿入することができれば、時にはアプリケーションの動作を変更することができます。その効果は一般的な攻撃に比べて予測が困難ですが、標的となる組織にとってはそれに劣らず危険です。

このエピソードでは、以下のことを学びます。

• 攻撃者がCRLFインジェクションを引き起こす方法
• なぜCRLFの注射は危険なのか
• この脆弱性を修正することができる技術

攻撃者はどのようにしてCRLFインジェクションを引き起こすのでしょうか？

既存のコードにCRLF文字を挿入し、特定の結果を得ようとすることは、不可能ではないものの、かなり困難です。それが難しいのは、攻撃者がオペレーティングシステムや対象となるシステムのその他の要素に応じて、異なるCRLFの組み合わせを使用する必要があるからです。例えば、最新のWindowsマシンでは、行末にCRとLFの両方が必要ですが、LinuxではLFのコードのみが必要です。HTTPリクエストでは、行末に必ず正確なCRLFコードが必要です。

しかし、CRLF攻撃は実装が難しく、その結果を予測するのも難しいという事実に加え、他のインジェクションタイプの攻撃とほぼ同様の方法で開始されます。悪意のあるユーザーは、ウェブサイトやアプリケーション上の入力可能な領域にデータを入力しますが、その際、通常の入力データの代わりに、または入力データの後にCRLFコードを入力します。

例えば、攻撃者は HTTPS ヘッダーの最後に、キャリッジリターン（%0d）を表す ASCII コードと、それに続くラインフィード（%0a）を表す ASCII コードを入力することができる。すると、クエリ全体は次のようになります。

https://validsite.com/index.php?page=home%0d%0a

データがサニタイズされていなかったり、フィルタリングされていなかったりすると、上記のコードによって対象となるアプリケーションやWebサイトでおかしなことが起こる可能性があります。

なぜCRLFの注射は危険なのか？

CRLF インジェクションによる攻撃は、他の攻撃に比べて精度が低いものの、少なくとも一部の場合はかなり危険です。低レベルでは、余分な行を追加することでログファイルが混乱し、サイバーセキュリティの自動防御機能が作動して管理者に問題のないことを警告するかもしれません。しかし、これを利用して、同時期に発生している実際の侵入行為からリソースをそらすことも可能です。

しかし、CRLF攻撃は直接ダメージを与えることもあります。例えば、コマンドを受け付けてから特定のファイルを検索するように設計されているアプリケーションの場合、クエリにCRLFコードを追加すると、アプリケーションがその処理を隠したままではなく画面に表示するきっかけとなり、攻撃者にとって貴重な情報となる可能性があります。

CRLF を注入することで、行末のコードが有効なレスポンスを複数に分割してしまう、いわゆるレスポンス・スプリッティング攻撃を行うこともできます。これにより、ハッカーはCRLFコードの後のヘッダーをコントロールできるようになり、それを利用して追加コードを注入することができます。また、CRLF攻撃によって破壊された部分に続く行に、攻撃者が自分のコードを完全に注入できるような隙を作り、別の攻撃を引き起こす可能性もあります。

CRLFインジェクション脆弱性の解消

このシリーズから得られる重要なメッセージがあるとすれば、それは「ユーザーの入力を絶対に信用してはいけない」ということです。本連載で取り上げた脆弱性のほとんどは、何らかの形でユーザーの入力領域に関わっており、CRLFインジェクションの欠陥も例外ではありません。

ユーザーが入力する箇所には、アプリケーションやサーバが誤って解釈する可能性のある不正なコードの注入を防ぐためのフィルタを適用する必要があります。CRLF 攻撃では、HTTP ヘッダのロックダウンが特に重要ですが、GET や POST のパラメータ、さらには Cookie も忘れてはなりません。CRLFコードがさらなるインジェクションの引き金にならないようにするには、ユーザーのブラウザに送信されるすべてのデータにHTMLエンコーディングを適用することが有効です。

CRLFインジェクションの詳細情報

さらに詳しい情報は、OWASPがCRLFインジェクションについてどのように述べているかをご参照ください。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御の知識を試すこともできます。この脆弱性やその他の脅威の対策についての詳細は、Secure Code Warrior ブログをご覧ください。

このブログシリーズをご覧になっている方は、今回のリモートファイル取り込みの脆弱性と、前回ご紹介したローカルファイル取り込みおよびパストラバーサルの脆弱性の間に、多くの類似点があることにお気づきになるかもしれません。これらの脆弱性の根本的な原因は、推奨される修正方法と同様に類似しています。

多くの点で、リモート・ファイル・インクルージョンの脆弱性は、ローカル・ファイル・インクルージョンの脆弱性よりもはるかに危険であり、また悪用されやすいものです。そのため、できるだけ早く発見し、対策を講じる必要があります。あるいは、より良い方法として、ウェブアプリケーションは、そもそもこの脆弱性が発生しないように設計されるべきです。

このエピソードでは、以下のことを学びます。

• リモートファイルインクルージョンの脆弱性を利用したハッカーの手口
• リモートファイルインクルードの許可が危険な理由
• この問題を解決するためのテクニック。

攻撃者はどのようにしてリモートファイルインクルージョンを利用するのか？

リモートファイルインクルードの脆弱性は、ほとんどのプログラミングフレームワークに存在する「ダイナミックファイルインクルード」コマンドまたはメカニズムを利用しています。この機能は、開発者がセカンダリ・サーバ上にあるファイルを使用して、アプリケーション・サーバ上でアクティビティを実行できるようにすることを目的としています。明らかに、これは悪用されると危険です。

攻撃者がこの機能を利用するには、HTTPヘッダーや対話型フォームの入力エリアなど、ユーザーの無制限な入力を許可しているウェブサイトやアプリケーションを見つけることが必要です。これは、HTTPヘッダーや対話型フォームの入力エリアなどで、ファイルインクルードコマンドを生成するための出発点として使用されます。

例えば、サイトがページの読み込みに GET 関数を使用している場合、page = request.getParameter("page"); include page; のように、攻撃者は page コマンドを使用して、自分がコントロールするサイトの URL と実行したいファイルのファイルパスを指定して、クエリを送信することができます。このクエリがサーバーに渡され、リモートファイルがホスト上で実行されます。この活動は、信頼されたアプリの一部であるため、許可されます。

リモートファイルインクルージョンはなぜ危険なのか？

リモートファイルインクルードの危険度は極めて高い。ローカルファイルインクルードの脆弱性では、攻撃者が実行するファイルがホスト上に存在し、かつ攻撃者が試行錯誤して見つけなければなりませんが、リモートファイルインクルードではそのような制限はありません。明らかに、攻撃者は悪用したいファイルの場所を知っています。なぜなら、それらは自分のマシンや自分が管理するサイトに存在する可能性が高いからです。また、ファイルは攻撃者が手動で選択することができ、悪用する前にターゲットマシン上に存在する必要はありません。このファイルは、リモートホストを悪用するために特別に書かれたスクリプトで構成されていることもあります。

要するに、ひとたび攻撃者がリモート・ファイル・インクルージョンの脆弱性を発見し、それを利用することができれば、アプリケーションやサイト全体を完全にコントロールすることが可能になります。確かに、そこに保存されているデータは、彼らの侵入から安全ではありません。

リモートファイルインクルージョンの脆弱性の除去

ユーザーの入力をファイル取り込みコマンドに直接渡して実行させてはいけません。代わりに、コマンドの間接参照マップを使用し、そこからのみコマンドを実行します。間接参照マップは、信頼できないユーザーの入力を、サーバー上でハードコードされた信頼できる値のセットにマッピングします。ユーザーがデータを入力できる場所は必ずホワイトリストに登録し、HTTPヘッダー、フォームパラメーター、さらにはクッキーもリストに含めることを忘れないでください。そうすることで、ファイルインクルードコマンドを作成しようとする攻撃者が利用できるウィンドウを閉じることができます。

さらに、ユーザーが作成したコンテンツを適切にサニタイズおよび検証し、参照マップを使用してコマンドを実行することで、リモートファイルインクルードの脆弱性だけでなく、このバグの危険な従兄弟であるローカルファイルインクルードおよびパストラバーサルのエクスプロイトを含む、その他の多くの脆弱性を潰すことができます。

リモートファイルインクルージョンの詳細情報

さらに詳しく知りたい方は、OWASPreference guidefor remote file inclusion exploitsをご覧ください。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御の知識を試すこともできます。この脆弱性やその他の脅威への対策について詳しくは、Secure Code Warrior ブログをご覧ください。

多くの脆弱性とは異なり、ローカルでのファイルの取り込みやパス・トラバーサル処理を悪用するには、十分に熟練した攻撃者とそれなりの時間、そしておそらく少しの運が必要です。しかし、この脆弱性を無視できるというわけではありません。熟練した攻撃者は、この脆弱性を利用して、組織の内部ファイルを敵に回したり、ディレクトリ構造をマッピングしたり、さらには、危険な二次攻撃に利用できるパスワードやユーザー情報を盗むこともできます。

このエピソードでは、以下のことを学びます。

• ハッカーがローカルファイルの取り込みやパストラバーサルの脆弱性を利用する方法
• 無制限にローカルファイルの取り込みやパストラバーサルを許可することが危険な理由
• この問題を発見し、解決するために採用できる方針と技術。

攻撃者はどのようにしてローカルファイルインクルージョンやパストラバーサルを利用するのか？

テレビの名探偵コロンボは、事件を解決するための貴重な情報を提供する前に、必ず「もうひとつだけ」と言っていた。その時は、取るに足らないことのように思え、容疑者はほとんどの場合無視していましたが、いつも破滅を招くことになりました。ローカルファイルの取り込みやパス・トラバーサルの脆弱性は、それとよく似ています。

ローカルファイルインクルードおよびパストラバーサルの脆弱性は、ASP、JSP、PHPスクリプトなど、ほとんどのプログラミングフレームワークに存在する動的ファイルインクルードの仕組みを利用しています。ローカル・ファイル・インクルードでは、攻撃者はローカル・サーバ上に存在するファイル名を、ヘッダやフォーム入力領域などのウェブ・アプリケーション内の領域に挿入します。アプリケーションは、通常通りメインの入力を処理しますが、include(page)などのコマンドも処理します。パストラバーサルでは、攻撃者は疑いのあるファイルへのパスを定義し、通常はドット、ドット、スラッシュ(../)の文字を変数として使用します。これはコロンボのようなもので、ハッカーは最初の部分の議論を本当に気にしません。これは、ハッカーが最後に「もうひとつだけ」を追加するための手段に過ぎません。

いずれの場合も、攻撃者は通常、かなりの量の試行錯誤を行う必要があります。サイトの構造を熟知していない限り、パス構成やファイル名を推測するのには長い時間がかかります。とはいえ、ほとんどのサイトは特定のパターンに従っており、多かれ少なかれ似たようなディレクトリやファイル名を持っています。そのため、思ったほど時間はかからないかもしれません。また、報酬が非常に高額になる可能性があることを考えると、ハッカーにとっては、ローカルファイルの取り込みやパストラバーサルの脆弱性が見つかった場合、それを利用しようとするインセンティブが大きくなります。

ローカルファイルインクルードやパストラバーサルの脆弱性はなぜ危険なのか？

ローカル・ファイル・インクルージョンやパス・トラバーサルの脆弱性は、攻撃者が機密ファイルや重要なファイルへのアクセスを許してしまう危険性があります。データファイルの場合、ハッカーがユーザーのパスワードやその他の個人情報などの貴重な情報を入手する危険性があります。主な標的は、パスワードやユーザ設定ファイルであることが多く、これによってサイトの他の部分にアクセスできるようになります。データベースも主要なターゲットです。ローカル・ファイル・インクルードやパス・トラバーサルの脆弱性により、最悪の場合、攻撃者はデータベースの内容全体を盗むことができます。

実行ファイルの場合、そのファイルにアクセスすることで、サイトの一部を破壊したり、システムリソースを浪費してある種の内部サービス拒否攻撃を行うなど、悪意のある活動が可能になる危険性があります。しかし、その危険性の範囲は、攻撃者の創意工夫と技術、そして攻撃対象のサーバーにすでに存在するファイルにアクセスできるかどうかによってのみ制限されます。

ローカルファイルインクルージョンとパストラバーサルによる脅威の除去

ローカルファイルのインクルードやパストラバーサルの脆弱性がもたらす危険性は、サイバーセキュリティの適切な実践によって排除することができます。最も重要なことは、「ファイルインクルード」や同様の機能を持つ他のコマンドでユーザーの入力を決して許可しないことです。もしアプリケーションがそれを許可しなければならない場合は、それを直接渡さないでください。代わりに、間接参照マップを使用します。間接参照マップは、ユーザーの入力をハードコードされた信頼できる値にマッピングし、それを安全に使用することができます。

他の多くの脆弱性と同様に、クッキー、HTTPヘッダ、フォームパラメータなど、ユーザが制御するすべての入力領域に特に注意してください。許可される入力はホワイトリスト化し、それ以外は明示的に拒否します。それができない場合は、入力検証を使って、数字や英数字など、許可される値を厳しく管理してください。

ローカルファイルのインクルードとパストラバーサルに関する詳細情報

さらに詳しく知りたい方は、ローカルファイルのインクルードとパストラバーサルのエクスプロイトに関するOWASPテストガイドをご覧ください。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御知識を試すこともできます。この脆弱性やその他の脅威への対策について詳しくは、Secure Code Warrior ブログをご覧ください。

アプリケーションサーバとそれが使用するバックエンドシステムを完全に保護したとしても、トランスポート層の保護が不十分であれば、通信は盗聴される可能性があります。物理的な世界では、装甲車を使ってハードカレンシーを移動させるのは、移動中の保護のためです。お店や銀行がどんなに安全であっても、そこで作られたお金がゴルフカートに積まれて街中を移動するのでは意味がありません。

これはサイバー領域のトランスポート層にも同じことが言えます。アプリケーションが安全であっても、そこに入ってくる情報が無防備な状態で送信されると、致命的な脆弱性が生じます。また、一部のアプリケーションでは、他のサーバーやデータベースにも情報を送信する場合、第二の脆弱性があります。そのような情報は、取引を盗み見ることに関係のない内部の人間にさらされる可能性があります。

ユーザーとデータを完全に保護するには、トランスポート層を保護する必要があります。そうすることで初めて、最後から最後までのトランザクション全体を完全に保護することができます。

このエピソードでは、以下のことを学びます。

• 不十分なトランスポート層保護をハッカーが利用する方法
• トランスポート層を保護しないことがなぜ危険なのか
• アプリケーションやサーバーに入る、または通過するすべてのデータのトランスポートを保護するために何ができるのか。

攻撃者はどのようにして不十分なトランスポート層保護を利用するのか？

トランスポート層の保護が不十分な場合、データストリーム内の2つのポイントで攻撃を受ける可能性があります。最も悪用されやすいのは、ユーザーとアプリケーションサーバの間です。情報が平文で送信されたり、暗号化が不十分だったりすると、ハッカーはその情報を監視したり、盗んだり、変更したりすることができます。これにより、ハッカーはユーザーのクレジットカードやログイン情報など、アプリケーションサーバに送信されたあらゆる情報を盗むことができるかもしれません。たとえサーバ自体が安全であっても、サーバとユーザの間の安全でないチャネルを監視するハッカーは、多くの情報にほぼ無制限にアクセスできる可能性があります。

次に、アプリケーションと他のネットワークとの間のトランスポート層が、保護されていないことがよくあります。例えば、アプリケーションサーバがオンラインショッピングの注文を処理してフルフィルメントシステムに送ったり、データを単純にデータベースにオフロードして保存したりする場合があります。これらの内部チャネルが保護されていない場合、内部のユーザーがその情報を見ることができる可能性があります。

すべての社内ユーザーが善良な人間であると信じたいところですが、実際には、多くの業界でインサイダーの脅威が増加しています。インサイダーは、攻撃者や競合他社のために機密情報を収集する見返りに、賄賂を受け取っていることが明らかになっています。また、何千枚もの有効なクレジットカードなどにアクセスできることは、無視できないほど魅力的なことかもしれません。

攻撃技術の面では、保護されていない通信を傍受することはそれほど難しくありません。低レベルのハッカーでも、暗号化されていないデータストリームに対して中間者攻撃を行う方法を知っています。もし知らなくても、ネット上には30分以内にトレーニングできるビデオがあります。

トランスポートレイヤー保護が不十分な脆弱性はなぜ危険なのか？

トランスポート層の保護が不十分または存在しないことは、ハッカーが機密情報を極めて容易に収集できるようになるため危険です。ハッカーは、アプリケーションサーバに侵入したり、ネットワークをハッキングしたりする必要はありません。アプリケーションサーバに侵入したり、ネットワークをハッキングしたりする必要はなく、中間者攻撃を仕掛けて、ユーザからサーバに送信される情報をすべて読み取るだけでよいのです。その中には、ユーザー名やパスワードも含まれており、将来、有効な認証情報を使ってセキュリティを回避するために使用することができます。アプリケーションによっては、クレジットカード情報やその他のユーザーの個人情報も含まれることがあります。

そして重要なのは、これらのスヌーピングがすべてネットワークの外で行われているということです。安全でないトランスポートチャネルを使用している場合、誰かがその情報を取得しているかどうかを知る方法はありません。通常、最初の兆候は、多くのユーザーがアカウントの漏洩やクレジットカードの購入を報告し始めたときであり、共通の要因は、アプリケーションが「良い場所ではない」ということです。また、ハッカーは情報を入手した後に、例えば配送先の住所を変更したり、ユーザーに渡す前にサーバーのレスポンスに悪意のあるスクリプトを挿入したりして、情報を改ざんすることができます。

バックエンドでは、トランスポート層のセキュリティを確保できないと、内部の人間にデータが公開されてしまいます。内部の人間がトランスポート層を盗み見ることは、外部からのハッカーが同じことをするのに比べれば、おそらくはるかに少ないでしょう。なぜなら、内部の脅威は、ユーザーデータだけでなく、パケットを送信する前にアプリケーションサーバーによって追加された独自の情報も見ることができるからです。

トランスポートレイヤープロテクションの不十分な脆弱性の解消

トランスポート層の保護が不十分だと危険ですが、すべてのトランスポートチャネルを適切に保護することは、それほど難しいことではありません。まず、バックエンドのインフラから始める。バックエンドは HTTPS のみを使用し、HTTPS と HTTP が混在しないように注意する。最後に、有効な SSL 証明書を最低 2048 ビットの鍵サイズで維持し、すべてのユーザに HTTP Strict Transport Security (HSTS) で保護されたブラウザを使用して対話することを強制します。

インフラが整備されたら、開発者はトランスポート層を保護するために強力なプロトコルを使用する必要があります。理想的にはTLS 1.2を使用すべきですが、どうしても必要な場合はTLS 1.1や1.0でも構いません。インフラが整備されたら、SSLv2のような弱いプロトコルは完全に無効化し、決してサポートしないようにしてください。

また、バックエンドの暗号が十分に強力なものであることにも注意を払う必要があります。理想的には、セッションキーの最小サイズは128ビットです。プロトコルと同様に、DES や RC4-40 のような弱い暗号アルゴリズムのサポートは無効にすべきです。最後に、サーバ自体と、サーバに出入りするすべてのデータパスの両方が十分に保護されるまで、アプリケーションを真に安全だと考えてはいけません。

不十分なトランスポートレイヤー保護の脆弱性に関する詳細情報

さらに詳しく知りたい方は、OWASPguide to protectingtransport layersをご覧ください。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御の知識を試すこともできます。この脆弱性やその他の脅威の対策についての詳細は、Secure Code Warrior ブログをご覧ください。

XMLインジェクション攻撃は、XMLデータベースを搭載したシステムを危険にさらすために、ハッカーが考案したちょっとした悪意ある攻撃です。これには、従来のデータベースで思い浮かぶような、薬から映画まであらゆる情報を詳細に保存したものが含まれます。XMLデータストアの中には、許可されたユーザーをチェックするために使用されているものもあります。そのため、新しいXMLコードを注入すると、ホストシステムがその時点から受け入れることができる新しいユーザーが作成されます。

攻撃者がXMLインジェクションを実行するためには、XMLデータベースに依存しているか、少なくともXMLデータベースにアクセスしているアプリケーションが必要です。その際、ユーザーの入力が適切に吟味されていないと、新しいXMLコードがデータストアに追加されてしまいます。攻撃者のスキルにもよりますが、新しいXMLコードを追加することで、かなりのダメージを与えることができますし、データベース全体へのアクセスが可能になることもあります。

読み進めていくと、XMLインジェクションが、前回取り上げたSQLインジェクション攻撃と密接に関連していることに気づくかもしれません。この2つの攻撃は、異なる種類のデータベースを対象としているにもかかわらず、非常によく似ているからです。そして、ありがたいことに、修正方法も似ています。一方の攻撃を防ぐ方法を学ぶことで、もう一方の攻撃を防ぐための作業を有利に進めることができます。

このエピソードでは、以下のことを学びます。

• XMLインジェクションの仕組み
• なぜ彼らは危険なのか
• 完全に阻止するための防御策を講じることができます。

攻撃者はどのようにしてXMLインジェクションを引き起こすのか？

XML インジェクションは、権限のないユーザーが XML コードを記述し、それを既存の XML データベースに挿入することができれば、必ず成功します。これが機能するためには、XMLデータベースに依存している、または接続しているアプリケーションと、攻撃者が攻撃を開始するための安全でないデータ経路の2つが必要です。

XMLインジェクションは、ユーザーの入力がサーバーに送られて処理される前に、サニタイズやその他の制限が行われていなければ、ほぼ必ず成功します。これにより、攻撃者は通常のクエリ文字列の最後に独自のコードを書いたり、注入したりすることができます。これが成功すると、サーバーを騙してXMLコードを実行させ、レコードの追加や削除、さらにはデータベース全体の公開を可能にします。

ハッカーは、通常のクエリにXMLコードを追加することで、XMLインジェクション攻撃を行います。これには、検索フィールドからログインページまで、あらゆるものが含まれます。また、クッキーやヘッダーなども含まれることがあります。

例えば、登録フォームで、ユーザー名やパスワードの欄の後に次のようなコードを追加するとします。

<user></user>
<role>administrator</role>
<username>John_Smith</username><password>Jump783!Tango@12</password>

この例では、John_Smithという名前の新しいユーザーが管理者権限で作成されます。少なくとも、この新しいユーザーはパスワード密度の高いルールを採用しています。しかし、実際には攻撃者であることが残念です。

ハッカーは、XMLインジェクションで成功するために、必ずしも常にこのようなホームランを打つ必要はありません。クエリを操作し、サーバーが返すさまざまなエラーメッセージを記録することで、XMLデータベースの構造を把握することができるかもしれません。そしてその情報は、他のタイプの攻撃を強化するために使用することができます。  

なぜXML注射は危険なのか？

XMLインジェクション攻撃の危険度は、対象となるXMLデータベースにどのような情報が保存されているか、またはその情報がどのように使用されているかによって異なります。例えば、ユーザーの認証にXMLデータベースを使用している場合、XMLインジェクションによって攻撃者はシステムにアクセスすることができます。これにより、攻撃者は対象となるネットワークの管理者になることができるかもしれませんが、これはもちろん非常に危険な状況です。

従来のデータベースに対して行われるXMLインジェクションでは、情報が盗まれたり、誤ったデータがストアに追加されたり、場合によっては正常なデータが上書きされたりする危険性があります。XMLコードの習得はそれほど難しくなく、コマンドの中には、情報フィールド全体を上書きしたり、データストアの内容を表示したりするなど、非常に強力なものもあります。

一般的に、データベースに保存されている情報に価値がなければ、誰もデータベースを構築しません。ハッカーはこのことを知っているので、しばしばデータベースを標的にします。そのデータに従業員や顧客の個人情報などが含まれている場合、その情報が漏洩すると、評判の失墜、経済的影響、多額の罰金、さらには訴訟にまで発展する可能性があります。  

XMLインジェクション攻撃の阻止

XMLインジェクションは、攻撃の難易度が低く、XMLデータベースが普及していることもあり、かなり一般的に行われています。しかし、これらの攻撃は長い間存在しています。そのため、これらの攻撃が実行されないようにするための鉄板の修正方法がいくつかあります。

このような攻撃を阻止する最善の方法の一つは、コンパイル済みのXMLクエリのみを使用するようにアプリケーションを設計することです。これにより、クエリの機能は、許可された活動のサブセットに制限されます。プリコンパイルされたクエリの機能と一致しない余分な引数やコマンドが入ってきたものは、単に実行されません。ここまで制限したくない場合は、パラメータ化を使用することもできます。これは、ユーザの入力を特定のタイプのクエリやデータに制限するもので、例えば整数のみを使用するといったものです。これらのパラメータから外れたものは無効とみなされ、クエリは失敗に終わります。

また、プリコンパイルされたクエリやパラメータ化されたクエリに、カスタマイズされたエラーメッセージを組み合わせるのも良いアイデアです。アプリケーションは、失敗したクエリからデフォルトの説明的なエラーメッセージを送り返すのではなく、それらのレスポンスをインターセプトして、より一般的なメッセージに置き換えるべきです。理想的には、なぜクエリが失敗したのかをユーザに伝えたいが、データベース自体に関する情報は伝えたくないということです。このようなカスタムメッセージをいくつかの選択肢に限定すれば、ハッカーは失敗したクエリから有益な偵察を行うことができなくなります。

XMLインジェクションが開発された当初は大きな成功を収めました。しかし、それが昔のことであるならば、今日では、もはや破られることのない防御策を簡単に構築することができます。

XML Injectionsの詳細情報

さらに詳しく知りたい方は、OWASPのXMLインジェクションに関する記事をご覧ください。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御の知識を試すこともできます。この脆弱性やその他の脅威の対策についての詳細は、Secure Code Warrior ブログをご覧ください。

このブログでは、ハッカーがネットワークを攻撃し、防御を回避するために使用する危険な脆弱性や悪意のある悪用方法について紹介してきました。その内容は、プログラミング言語の弱点を突いたり、さまざまな形式でコードを注入したり、転送中のデータを乗っ取ったりと、多岐にわたります。これらの脅威は非常に多岐にわたりますが、これらの脅威が成功した場合、被害者のアプリケーションには1つの共通した要素があることが多いのです。

ロギングとモニタリングが不十分であることは、アプリケーションの防御構造の中で存在しうる最も危険な状態の1つです。この脆弱性や状態が存在する場合、それに対して行われる高度な攻撃のほとんどは、最終的に成功することになります。ログと監視が不十分であるということは、攻撃や攻撃の試みが発見されない期間が非常に長いことを意味します。これは基本的に、攻撃者が有用な脆弱性を見つけてそれを利用するのに必要な時間を与えてしまうことになります。

このエピソードでは、以下のことを学びます。

• 不十分なログやモニタリングを攻撃者がどのように利用するか
• なぜ不十分な記録と監視が危険なのか
• この脆弱性を修正することができる技術

攻撃者はどのようにして不十分なロギングとモニタリングを利用するのか？

攻撃者は、システムが適切に監視されているかどうか、ログファイルに不審な動きがないかどうか、最初はわかりません。しかし、それを知るのは簡単なことなのです。攻撃者は、よく使われるパスワードをユーザーデータベースに照会するなど、ブルートフォース（総当たり攻撃）のような無作法な攻撃を仕掛けます。そして、数日後にまた同じような攻撃を試みます。もし、2回目の攻撃がブロックされていなければ、誰もログファイルに不審な動きがないか注意深く監視していないことを示しています。

アプリケーションの防御力をテストしたり、アクティブな監視がどの程度行われているかを測定したりすることは比較的簡単ですが、それは攻撃を成功させるための要件ではありません。攻撃者は、できるだけ音を立てないような方法で攻撃を仕掛けることができます。多くの場合、多すぎるアラート、アラートの疲労、不十分なセキュリティ設定、あるいは単に悪用可能な脆弱性の多さなどが相まって、防御側がその存在に気づく前に、目的を達成するための時間が十分に確保されていることになります。

なぜ不十分なログ・モニタリングが危険なのか？

ロギングやモニタリングが不十分だと、攻撃者が攻撃を開始するだけでなく、防御側が対応を開始するよりもずっと前に目的を達成するための時間を与えてしまうことになり、危険です。どのくらいの時間がかかるかは、攻撃を受けたネットワークによって異なりますが、Open Web Application Security Project（OWASP）などのさまざまな団体は、侵入されたネットワークの平均対応時間を191日以上としています。

ちょっと考えてみてください。もし強盗が銀行を襲って 人々が警察に電話して 対応に半年もかかったらどうなるでしょう？

警察が到着したときには、強盗はとっくにいなくなっているだろう。実際には、警察が最初の事件に対応する前に、同じ銀行に何度も強盗が入ることがあります。

サイバーセキュリティの分野でも同じことが言えます。ニュースで報道されるような有名な情報漏えい事件のほとんどは、「破壊と奪取」の類のものではありません。多くの場合、攻撃者が数ヶ月、あるいは数年にわたってデータをほぼ完全にコントロールした後に、標的となった組織が侵害について知ることになります。このように、ログの記録や監視が不十分であることは、優れたサイバーセキュリティを実践しようとする際に起こりうる最も危険な状況の1つです。

不十分なロギングとモニタリングの解消

不十分なログや監視を防ぐには、主に2つのことが必要です。まず、すべてのアプリケーションは、サーバ側の入力検証の失敗を監視し、ログに記録する機能を備えていなければなりません。この機能には、セキュリティチームが、攻撃者が使用しているユーザアカウントはわからなくても、ツールやテクニックを特定できるだけの十分なユーザ・コンテキストが必要です。あるいは、このような入力をSTIX（Structured Threat Information eXpression）のような言語にフォーマットし、セキュリティ・ツールが迅速に処理して適切なアラートを生成できるようにしなければなりません。

第二に、優れたアラートを生成するだけでは十分ではありません。組織は、警告がタイムリーに調査されるよう、役割と責任を確立する必要があります。実際に成功した多くの侵害事件では、攻撃を受けたネットワーク上で警告が発せられましたが、責任の所在を問われたために警告に耳を傾けられませんでした。誰が対応すべきか分からなかったり、誰かが問題を調べていると思い込んだりしていたのです。

責任の所在を明確にするためには、米国標準技術局（NIST）が特別出版物800-61で推奨しているようなインシデント対応・復旧計画を採用することから始めるのがよいでしょう。この他にも、様々な業界に特化したものなど、参考となる文書がありますが、それらを忠実に守る必要はありません。しかし、組織内の誰がアラートに対応し、どのようにしてタイムリーに対応するかを定義した計画を立てることは重要です。

不十分なロギングとモニタリングに関する詳細情報

さらに、OWASPが不十分なロギングとモニタリングについて述べていることを参考にしてみてください。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御の知識を試すこともできます。この脆弱性やその他の脅威の対策についての詳細は、Secure Code Warrior ブログをご覧ください。

不十分なログやモニタリングを見つけ、修正し、解消する準備はできていますか？私たちのトレーニングアリーナへどうぞ。 [Start Here] (ここからスタート)

Webサイトやアプリケーションで、妥当性のないリダイレクトや転送を処理する機能をコード化することは、ユーザーにとっても組織にとっても非常に危険です。この一般的なミスは、フィッシング詐欺や、通常は制限されているページや情報へのアクセスを狙うハッカーによく利用されます。

ウェブアプリケーションがユーザーを新しいページに転送するように設計されている場合、そのリクエストが操作されたり乗っ取られたりする危険性があります。これは、転送パラメータが意図しない目的地を指すのを防ぐための検証プロセスがない場合に起こります。

良いニュースは、検証されていないリダイレクトやフォワードは、お客様の環境から排除するのが容易な脆弱性の一つであるということです。排除した後は、いくつかの簡単な手順を踏むことで、今後このような脆弱性が発生しないようにすることができます。

このエピソードでは、以下のことを学びます。

• 無効なリダイレクトとフォワードの脆弱性を利用するハッカーの手口
• 検証されていないリダイレクトやフォワードを許可することが危険な理由
• この問題を発見し、解決するために採用できる方針と技術。

攻撃者はどのようにして無効なリダイレクトやフォワードを利用するのか？

攻撃者は、まず、ユーザを特定のページに転送するように設定されているウェブアプリケーションを見つけなければなりません。転送先のページがコードの中で定義されていれば、脆弱性はありません。例えば、Javaであれば、ハイパーリンクをクリックするなどのアクションを必要とせずに、ユーザを新しい場所に送るための安全で事前に定義された方法となります。

response.sendRedirect("http://www.knownsafesite.com")。

この脆弱性は、リダイレクトのためにユーザーの入力を受け付けるようにサイトがプログラムされている場合や、別のソースから情報を取得するためにパラメータをオープンにしている場合に発生します。例えば、開発者は「url'GET」というパラメータを使用することができます。

response.sendRedirect(request.getParameter("url"));

これにより、柔軟性が増す一方で、検証されていないリダイレクトとフォワードの脆弱性が生じます。ハッカーは、フォワードスラッシュの後に情報を追加することで、任意のサイトへのリダイレクトを引き起こすことができます（おそらくフィッシングメールの一部として）。ユーザーは、リンクの最初の部分に信頼できるドメインを見て、そのウェブサイトがハッカーのサイトに転送される可能性があることに気づきません。

なぜ無効なリダイレクトやフォワードは危険なのか？

検証されていないリダイレクトやフォワードを許可することでもたらされる危険性は大きいものです。ユーザーにとっての最大の危険は、フィッシング攻撃の被害に遭うことです。ユーザーはトップレベルのURLを目にするため、フィッシングメールなどを信用してリンクをクリックしてしまう可能性が高くなります。また、リダイレクト先のページが実際のページのように見える場合、その欺瞞は非常に効果的です。ユーザー名、パスワード、その他の認証情報を共有しても、自分が操作されていることを疑うことはないでしょう。

無効なリダイレクトとフォワードがもたらす脅威の除去

無効なリダイレクトやフォワードは、アプリケーションの開発中に発生します。事後的に排除することもできますが、最も簡単な方法は、そもそもリダイレクトや転送の機能の一部として、ユーザのパラメータやオープンストリングを許可しないことです。代わりに、ユーザーが転送されるURLを厳密に定義することで、変数を排除し、攻撃者が操作する余地をなくすことができます。さらに言えば、リダイレクトやフォワードを一切使用しないことも検討してください。

リダイレクトやフォワードのプロセスで変数を使わないようにする方法がどうしてもない場合は、リダイレクト先が有効な目的地の1つであることを確認するための検証プロセスを導入する必要があります。最後に、実際のURLではなくマッピング値を使用することです。ハッカーは代わりにURL情報を使おうとしますし、たとえマッピングスキームが使われていると疑っても、それを推測することはできないでしょう。

無効なリダイレクトとフォワードに関する詳細情報

さらに詳しく知りたい方は、OWASP のリファレンスページである unvalidated redirects and forwards をご覧ください。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御の知識を試すこともできます。この脆弱性やその他の脅威への対策について詳しくは、Secure Code Warrior ブログをご覧ください。

検証されていないリダイレクトやフォワードを徹底的に排除します。新しい知識を活用し、ゲーム性のあるトレーニングプラットフォームで自分のスキルを試してみましょう。 [Start Here]をクリックしてください。

コードインジェクション攻撃は、多くのWebサイトやアプリケーションが遭遇する最も一般的な攻撃であり、また最も危険な攻撃でもあります。コードインジェクション攻撃は、その巧妙さと危険性の両面で様々な種類がありますが、ユーザーの入力を受け付けるサイトやアプリケーションであれば、ほぼすべてのものが脆弱になる可能性があります。実際、この種の攻撃は、ほとんどすべてのサイバーセキュリティ担当者がキャリアの中でいつかは対処しなければならないものであり、おそらく何度も対処することになるでしょう。

コードインジェクション攻撃は、アプリケーションやWebサイトがユーザーからの入力を受け付ける際に発生します。これは、検索機能を提供したり、ユーザーに識別情報の入力を求めたりするような単純なものです。この攻撃は、悪意のあるユーザーが、通常のテキスト入力ではなく、開いているフィールドにコードを入力することで起こります。攻撃者の目的は、サーバーに入力されたコードを有効なコードと勘違いさせ、攻撃者が望むあらゆる機能を実行させることです。

コード・インジェクション攻撃は非常に一般的なものですが、それを阻止するために利用可能な防御策もあります。このエピソードでは、以下のことを学びます。

• 仕組み
• なぜ彼らは危険なのか
• それを阻止するためには、どのような防御策を講じるべきか。

攻撃者はどのようにコードインジェクションを利用するのか？

コード・インジェクション攻撃の具体的な内容は、使用するプログラミング言語によって変わりますが、ユーザーにデータを入力させるアプリやWebサイトであれば、どのようなものでも脆弱になり得ます。コード・インジェクション攻撃は、SQL、HTML、XML、CSSなど、あらゆる一般的なプログラミング言語で引き起こされています。

まず、攻撃者はアプリケーション内で脆弱なコードを見つけなければなりません。通常、ユーザーが自分で入力することが許されている箇所です。例えば、このコードは、PHPのeval()関数を受け取り、それをユーザーに渡して変更させますが、その際、戻り値の文字列については何の検証も行いません。

$myvar = "varname";
$x = $_GET[arg];
eval("˶‾᷅˵‾᷄˵‾᷅˵")

巧妙な攻撃者は、独自の文字列をeval関数に簡単に追加でき、選択次第ではシステムコマンドを実行することも可能です。

/index.php?arg=1; system(id)

コード・インジェクション攻撃では、システム・コマンドを送信することもありますが、それだけに限定されないことに注意してください。実際、コード・インジェクション攻撃では、ハッカーは言語自体の機能によってのみ制限されます。今回の例では、攻撃者は対象となるシステムに、PHPフレームワークで許可されているほぼすべての機能をプログラムすることができます。

コードインジェクション攻撃はなぜ危険なのか？

コードインジェクション攻撃は、攻撃者の技量によっては非常に危険なものになる可能性があります。攻撃者は、プログラミング言語で許可されていることなら何でもできるため、アプリのプログラマーと同じ立場になることができます。攻撃者は事実上、自分自身のアプリを作成し、それをターゲット環境で実行させることができます。

熟練度の低い攻撃者であっても危険です。自分でアプリケーションやコードを書くのではなく、対象となるシステムにあらかじめプログラムされたマルウェアを受け入れさせ、インストールさせることができるのです。これは、サイトの改ざんやランサムウェアの攻撃につながるだけでなく、サイトのユーザーを狙ったフィッシングキャンペーンの根拠にもなります。

多くの場合、コードインジェクション攻撃は、ユーザーリストやパスワードなどを盗み出したり、システムをさらに危険にさらすために貴重な偵察を行ったりするために使用されます。しかし、注意していただきたいのは、熟練したコーダーはコードインジェクション攻撃でほとんど何でもできるということです。だからこそ、コードインジェクション攻撃の可能性があるものをすべて発見し、環境から取り除くことが重要なのです。

誰も信じない。少なくとも、ユーザーではない

コード・インジェクション攻撃の脆弱性を排除するために、まず最初に見るべき場所は、ユーザーの入力を要求したり、許可したりする場所です。ユーザーが入力したものは、どのような場合でも信用できません。フィルタリングや検査を行わずにユーザーの入力を許可することは、基本的に攻撃者がシステムやネットワークへの侵入を自由に行えるようにしていることになります。

常に可能とは限りませんが、コード・インジェクション攻撃を阻止する最善の方法は、関数がユーザーの入力を直接実行したり解釈したりしないようにすることです。例えば、ユーザーは自由にクエリを入力できる代わりに、静的な選択肢を与えられ、アプリケーションはそれらの限られた選択肢のみを有効なものとして受け入れるようにプログラムされています。必ずしも適切な方法ではないかもしれませんが、可能な限りこの方法を用いることで、コード・インジェクションが始まる前に排除することができます。

ユーザーが自分で入力する必要がある分野では、そのデータを厳重に管理する必要があります。すべてのものが攻撃の対象になると考えるのは、良いスタート地点です。クライアント側とサーバー側の両方で、ユーザーのアクセスを読み取り専用にするなど、最小権限のポリシーを実施することで、ほとんどのコードの実行を防ぐことができます。

もうひとつの有効な防御策は、アプリケーション全体でフィルターを実装し、ユーザーが入力するものすべてをサニタイズすることです。開発者は何年も前からコード・インジェクション攻撃に気付いており、実績のあるフィルタのライブラリがあらゆるフレームワークや言語に対応しています。これらのフィルタを適用する際には、明らかなユーザ入力領域や、GetやPostコマンドのような一般的なパラメータに対してだけでなく、CookieやHTTPヘッダに対してもフィルタを適用するようにしてください。

コードインジェクションの修正の適用

不必要なユーザー入力領域を環境から削除し、最小権限主義を徹底し、最新のフィルタリング・サニタイズツールを使用して潜在的な攻撃を検査・検出することで、この危険な脆弱性の扉を閉めることができます。また、ユーザーの入力を決して信用しないという考え方を持つことも、今後の活動に役立ちます。このようにして、この危険なタイプの攻撃の一歩先を行くことができるのです。

さらに詳しく知りたい方は、コードインジェクションに関するOWASPの記事をご参照ください。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御の知識を試すこともできます。この脆弱性やその他の脅威の対策についての詳細は、Secure Code Warrior ブログをご覧ください。

今すぐコードインジェクションに真正面から向き合う。ゲーム化されたトレーニングプラットフォームでチャレンジしてみましょう。 [Start Here] (ここからスタート)