XSS(クロスサイト・スクリプティング)対策にはエスケープ


HTMLやJavaScriptの生成処理に不備があると発生する脆弱性として、XSS(クロスサイト・スクリプティング)が知られている。

WebアプリケーションにXSSが潜んでいると、次のような状況が起こりえる。

1:ユーザーのブラウザ上で不正スクリプトが実行され、ユーザーのクッキーが盗まれた結果、成りすまし被害にあう。

2:Webサイト上に偽の入力フォームが表示され、利用者の個人情報が盗まれる。

XSSが発生する原因と対策は、次のようなものになる。

原因1:HTML生成の際に特殊記号(「<」や「”」)にエスケープ処理を施していない場合、入力された文字列がスクリプトとして実行されてしまう。

対策1:要素内容は「<」と「&」をエスケープする。

対策2:属性値については、「<」と「”」と「&」を「”」で囲みエスケープする。

対策3: header関数を用いて、HTTPレスポンスに文字エンコーディングを明示する。

原因2:URLを属性値とするhref,img,frame,srcにおいて、URLを外部から変更できる場合、URLに「javascript:Javascript式」を入力することでスクリプトとして実行されてしまう。

対策1:http:, https:, /, で始まるURLのみを許可する。

対策2:許可されたURLは、属性値としてHTMLエスケープする。

原因3:JavaScriptの動的生成において、JavaScriptの文字列リテラルにエスケープ処理を施していない場合、入力された文字列がスクリプトとして実行されてしまう。

対策1:文字エンコーディングがUTF-8の場合、script要素の外側でhiddenパラメータを定義して、JavaScript側から参照する。

対策2-a:文字エンコーディングがUTF-8以外の場合、JavaScriptの文うち「”」「’」「」「改行」をエスケープする。

対策2-b:script要素内の場合は、対策2-aの結果に「</」が出現しないように処理する。script要素外の場合は、対策2-aの結果を文字参照によりHTMLエスケープした後、「”」で囲む。

 


SQLインジェクション対策には静的プレースホルダ


データベースへアクセスするSQLに不備があると発生する脆弱性として、SQLインジェクションが知られている。

WebアプリケーションにSQLインジェクションが潜んでいると、次のような状況が起こりえる。

1:データベースに不正アクセスされる

2:データーベースの内容が改ざんされる

3:IDとパスワードを用いずに不正ログインされる

4:データベースサーバーで不正にプログラムを実行される

SQLインジェクションが生まれる原因は、リテラルからはみ出した文字列をシステムがSQL文として認識した結果、元のSQL文が改変されることにある。

SQLインジェクションを回避するには、「静的プレースホルダによりSQL文を組み立てる」のが良いとされている。たとえば、次のSQL文の「?」がプレースホルダーになる。

SELECT * FROM drink WHERE author = ? ORDER BY id

静的プレースホルダーは、値のバインドをデータベースエンジン側で行う。プレースホルダーのついたSQL文は、そのままデータベースエンジンに送られコンパイルされSQL文が確定する。その後、バインド値がデータベースエンジンに送られ、エンジン側で値を当てはめた後にSQL文が実行される。このように、プレースホルダーの状態でSQL文がコンパイルされるため、原理的に後からSQL文を変更できない。

 


擬似乱数生成器でセッションIDの脆弱性を極力回避する


HTTPプロトコルはステートレスなもので、サーバー側ではクライアントの状態を保持しない。しかし、ECサイトのショッピングカートのようなアプリケーションでは、クライアントの状態を保持する必要がある。また、会員限定のサービスでもログインした状態を保持しておく必要がある。

HTTP認証を使えば、ブラウザ側でIDとパスワードを記憶するが、HTTP認証を使わない場合は、サーバー側で認証状態を保持する必要がある。このようにアプリケーションの状態を保持することをセッション管理という。

セッション管理をHTTPで実現するためにクッキーを渡す仕組みが導入された。サーバー側からブラウザーに対して名前と変数のペアを覚えておくように指示する際に使われる「名前=変数」をクッキーという。

ブラウザーは、サーバーから渡されたクッキーをPCに記憶させ、それ以降に同じサイトへリクエストを送る際にクッキーを添付する。

クッキーが保持できる文字列長には制限があるため、クッキーには「整理番号」としてのセッションIDを格納しておき、実際のデータはサーバー側で管理する方法が広く用いられている。これをクッキーによるセッション管理と呼び、PHPなどの主要なWebアプリケーション開発ツールには、セッション管理のための仕組みが提供されている。

セッションIDに求められる要件はつぎの3つになる。

1:第三者がセッションIDを推測できない

2:第三者からセッションIDを強制されない

3:第三者にセッションIDが漏洩しない

セッションIDを推測できないという要件からは、乱数の質が問題になる。乱数に規則性があると、セッションIDを収集することで他者のセッションIDが推測可能になる。そのため、セッションIDは暗号論的擬似乱数生成器を用いて生成されている。

セッション管理機構は自作せずにPHPなどの主要なWebアプリケーション開発ツールが提供しているAPIを使うのが良いとされる。

 


バグとセキュリティ対策


インターネットの安全性を脅かす要因の1つにボットネットワークがある。ボットネットワークとはマルウェアの一種で、PCに感染後は外部からの指令を受けて、迷惑メール送信やDDoS攻撃などの不正活動を行う。

Webアプリケーションの脆弱性がボットネットワークの構築に悪用されている。攻撃者は、脆弱性のあるWebサイトの内容を改ざんして、サイトを閲覧した利用者のPCをボットに感染させる。ボットネットワークに組み込まれたPCは、攻撃者の指令を受けて操作され、迷惑メール送信やDDoS攻撃に加担してしまう。

ボットを仕込むよう改ざんされたサーバー群とボットに感染したPC群は拡大していき、ネットワーク犯罪組織の収入源になっている。

インターネットに脆弱なWebサイトを公開することは、反社会的な勢力に荷担するのと同じことになってしまう。

脆弱性が生まれる原因として次の2種類がある。

1:バグによるもの

2:セキュリティ対策不足によるもの

SQLインジェクションやクロスサイト・スクリプティングはバグによるものとされ、ディレクトリ・トラバーサルはセキュリティ対策不足によるものとされる。

アプリケーションのセキュリティを確保するためには、バグをなくすだけでは不十分な場合がある。たとえば、通信路をHTTPSで暗号化していない状態では通信内容を盗聴される可能性がある。

セキュリティ対策をどこまで盛り込むかは、費用との兼ね合いでシステム発注者が決めることになる。

 


PHPのセキュリティホール一覧


・2005年10月31日
Hardened-PHP Projectは、PHPの深刻なセキュリティ・ホールを警告した。
このセキュリティ・ホールは、ファイル・アップロードでグローバル・シンボル・テーブル$GLOBALSが
書き換えられることにより、リモートからPHPのスクリプトを実行される可能性があるというもの。

・2011年8月22日
PHPコミュニティは、PHP 5.3.7にセキュリティホールが存在することを警告した。
このセキュリティ・ホールは、パスワードのハッシュにcrypt関数を用い、ハッシュアルゴリズムとして
MD5を使用している場合、「任意のパスワードで認証可能になる」というもの。

・2012年5月9日
PHP Groupは、PHPのリクエスト処理に関する脆弱性が存在することを警告した。
このセキュリティ・ホールは、Web サーバ上に PHP を CGI モードで動作させている場合、
遠隔の第三者が PHP スクリプトのソースコードを閲覧したり、Web サーバの権限で任意の
コードを実行したりするというもの。

・2015年1月29日
情報処理推進機構は、PHPに脆弱性が存在することを警告した。
このセキュリティ・ホールは、process_nested_data 関数の解放済みメモリの使用 (Use-after-free) により、
任意のコードを実行されるというもの。

・2015年6月12日
情報処理推進機構は、PHPにサービス運用妨害の脆弱性が存在することを警告した。
このセキュリティ・ホールは、不正なorder-of-growth結果を誘発する巧妙に細工されたformデータを介して、
サービス運用妨害 (CPU 資源の消費) 状態にされるというもの。

・2015年7月17日
情報処理推進機構は、Windows 版「PHP」には、OS コマンド・インジェクションの脆弱性が存在することを警告した。
このセキュリティ・ホールは、細工されたパラメータを escapeshellarg 関数に処理させることで、
任意のOS コマンドを実行させられるというもの。


FLASHのセキュリティホール一覧


・2015年9月24日
情報処理推進機構は、FlashPlayerにウェブを閲覧することで DoS 攻撃や任意のコード(命令)を実行される脆弱性が存在することを警告した。
このセキュリティ・ホールは、アプリケーションプログラムが異常終了したり、攻撃者によってパソコンが制御されたりするというもの。

・2015年8月12日
情報処理推進機構は、FlashPlayerにウェブを閲覧することで DoS 攻撃や任意のコード(命令)を実行される脆弱性が存在することを警告した。
このセキュリティ・ホールは、アプリケーションプログラムが異常終了したり、攻撃者によってパソコンが制御されたりするというもの。

・2015年7月13日
情報処理推進機構は、FlashPlayerにウェブを閲覧することで DoS 攻撃や任意のコード(命令)を実行される脆弱性が存在することを警告した。
このセキュリティ・ホールは、アプリケーションプログラムが異常終了したり、攻撃者によってパソコンが制御されたりするというもの。

・2015年7月9日
情報処理推進機構は、FlashPlayerにウェブを閲覧することで DoS 攻撃や任意のコード(命令)を実行される脆弱性が存在することを警告した。
このセキュリティ・ホールは、アプリケーションプログラムが異常終了したり、攻撃者によってパソコンが制御されたりするというもの。

・2015年6月24日
情報処理推進機構は、FlashPlayerにウェブを閲覧することで DoS 攻撃や任意のコード(命令)を実行される脆弱性が存在することを警告した。
このセキュリティ・ホールは、アプリケーションプログラムが異常終了したり、攻撃者によってパソコンが制御されたりするというもの。

・2015年6月10日
情報処理推進機構は、FlashPlayerにウェブを閲覧することで DoS 攻撃や任意のコード(命令)を実行される脆弱性が存在することを警告した。
このセキュリティ・ホールは、アプリケーションプログラムが異常終了したり、攻撃者によってパソコンが制御されたりするというもの。

・2015年5月13日
情報処理推進機構は、FlashPlayerにウェブを閲覧することで DoS 攻撃や任意のコード(命令)を実行される脆弱性が存在することを警告した。
このセキュリティ・ホールは、アプリケーションプログラムが異常終了したり、攻撃者によってパソコンが制御されたりするというもの。

・2015年4月15日
情報処理推進機構は、FlashPlayerにウェブを閲覧することで DoS 攻撃や任意のコード(命令)を実行される脆弱性が存在することを警告した。
このセキュリティ・ホールは、アプリケーションプログラムが異常終了したり、攻撃者によってパソコンが制御されたりするというもの。

・2015年3月13日
情報処理推進機構は、FlashPlayerにウェブを閲覧することで DoS 攻撃や任意のコード(命令)を実行される脆弱性が存在することを警告した。
このセキュリティ・ホールは、アプリケーションプログラムが異常終了したり、攻撃者によってパソコンが制御されたりするというもの。

・2015年2月6日
情報処理推進機構は、FlashPlayerにウェブを閲覧することで DoS 攻撃や任意のコード(命令)を実行される脆弱性が存在することを警告した。
このセキュリティ・ホールは、アプリケーションプログラムが異常終了したり、攻撃者によってパソコンが制御されたりするというもの。

・2015年1月28日
情報処理推進機構は、FlashPlayerにウェブを閲覧することで DoS 攻撃や任意のコード(命令)を実行される脆弱性が存在することを警告した。
このセキュリティ・ホールは、アプリケーションプログラムが異常終了したり、攻撃者によってパソコンが制御されたりするというもの。

・2015年1月23日
情報処理推進機構は、FlashPlayerにウェブを閲覧することで DoS 攻撃や任意のコード(命令)を実行される脆弱性が存在することを警告した。
このセキュリティ・ホールは、アプリケーションプログラムが異常終了したり、攻撃者によってパソコンが制御されたりするというもの。

・2015年1月14日
情報処理推進機構は、FlashPlayerにウェブを閲覧することで DoS 攻撃や任意のコード(命令)を実行される脆弱性が存在することを警告した。
このセキュリティ・ホールは、アプリケーションプログラムが異常終了したり、攻撃者によってパソコンが制御されたりするというもの。

・2014年12月10日
情報処理推進機構は、FlashPlayerにウェブを閲覧することで DoS 攻撃や任意のコード(命令)を実行される脆弱性が存在することを警告した。
このセキュリティ・ホールは、アプリケーションプログラムが異常終了したり、攻撃者によってパソコンが制御されたりするというもの。

・2014年11月26日
情報処理推進機構は、FlashPlayerにウェブを閲覧することで DoS 攻撃や任意のコード(命令)を実行される脆弱性が存在することを警告した。
このセキュリティ・ホールは、アプリケーションプログラムが異常終了したり、攻撃者によってパソコンが制御されたりするというもの。

・2014年11月12日
情報処理推進機構は、FlashPlayerにウェブを閲覧することで DoS 攻撃や任意のコード(命令)を実行される脆弱性が存在することを警告した。
このセキュリティ・ホールは、アプリケーションプログラムが異常終了したり、攻撃者によってパソコンが制御されたりするというもの。

・2014年10月15日
情報処理推進機構は、FlashPlayerにウェブを閲覧することで DoS 攻撃や任意のコード(命令)を実行される脆弱性が存在することを警告した。
このセキュリティ・ホールは、アプリケーションプログラムが異常終了したり、攻撃者によってパソコンが制御されたりするというもの。

・2014年9月10日
情報処理推進機構は、FlashPlayerにウェブを閲覧することで DoS 攻撃や任意のコード(命令)を実行される脆弱性が存在することを警告した。
このセキュリティ・ホールは、アプリケーションプログラムが異常終了したり、攻撃者によってパソコンが制御されたりするというもの。

・2014年8月13日
情報処理推進機構は、FlashPlayerにウェブを閲覧することで DoS 攻撃や任意のコード(命令)を実行される脆弱性が存在することを警告した。
このセキュリティ・ホールは、アプリケーションプログラムが異常終了したり、攻撃者によってパソコンが制御されたりするというもの。

・2014年7月9日
情報処理推進機構は、FlashPlayerにウェブを閲覧することで DoS 攻撃や任意のコード(命令)を実行される脆弱性が存在することを警告した。
このセキュリティ・ホールは、アプリケーションプログラムが異常終了したり、攻撃者によってパソコンが制御されたりするというもの。

・2014年6月11日
情報処理推進機構は、FlashPlayerにウェブを閲覧することで任意のコード(命令)を実行される脆弱性が存在することを警告した。
このセキュリティ・ホールは、攻撃者によってパソコンが制御されるというもの。


DCOMの脆弱性を悪用した外部からの攻撃を未然に防ぐ方法


DCOMは、COMをリモートから実行できる分散オブジェクト機能として知られている。DCOMの脆弱性を悪用した外部からの攻撃を未然に防ぐ方法として、DCOMを無効にしておくのが良い。

DCOMを悪用したウィルスには、インターネットに接続しているだけで感染する危険性があるとされている。

DCOMを無効にする手順はつぎのようになる。

1: スタートメニューの下段にある「プログラムとファイルの検索」フィールドにdcomcnfgと入力する

2: スタートメニューの上段にあらわれるdcomcnfgを実行する

3: 表示されたウィンドウの左側メニュー内にある、「コンポーネントサービス」をクリックして下層の「コンピューター」を表示させる

4: 「コンピューター」をクリックして下層の「マイコンピューター」を表示させる

5: 「マイコンピューター」を右クリックしてプロパティを選択する

6:表示されたダイアログの上段にある「規定のプロパティ」を選択し、「このコンピューター上で分散COMを有効にする」についているチェックを外す。

7: ダイアログの右下の「適用」ボタンを押した後に、「OK」ボタンを押す

 

 


Webサーバーに対する攻撃を回避する


Webサーバーに対する主な攻撃として次の2つが知られている。

1:OS、Webサーバー、ミドルウェアなどの脆弱性をついた攻撃により、サーバーに不正侵入する。

2:Telnet、FTPサーバー、SSHサーバー、phpMyAdmin、Tomcat管理画面などへのパスワード攻撃により、サーバーに不正侵入する。

対策としては、つぎのようなものがある。

1:不要なアカウントは削除する。

2:NFSがディレクトリをマウントまたはエクスポートしないようにする。

3:すべてのコンパイラを削除する。

4:サイト運営に不要なユーティリティプログラムは削除する。

5:メールサーバーを運用しない。

6:つねに脆弱性情報を監視する。脆弱性が見つかったものには、すみやかにパッチをあてる。ソフトウェアのバージョンが古くパッチのサポートを受けられない場合は、アプリケーションへの影響を確認してから、新バージョンをインストールする。

7:外部からは専用線かVPN経由で接続し、不要なポートを閉じて、特定のIPアドレスのみ許可する。

8:Telnetサーバー、FTPサーバーを削除し、SSHサーバーのみを稼動させる。さらに、パスワード認証を停止して公開鍵認証のみ許可する。

 


強度の高い使い捨てパスワード


システムの安全性を確保する要件の1つは、パスワードを正しく使うことだと言われている。

侵入者は、システムに不正アクセスするために、次のような方法で正規ユーザーのパスワードを推測している。

1:汎用パスワードデータベースの中のパスワードを試していく。

2:システム内部のパスワードファイルを盗み出し、暗号化されているパスワードを復号する。

侵入者にパスワードを盗まれないよう防御する方法は、強度の高い使い捨てパスワードを利用することだと言われている。

強度の高いパスワードとは、数多くの文字、数字、記号をランダムに組み合わせたパスワードをいう。

使い捨てパスワードとは、1度使用した後は無効になるパスワードをいう。

銀行のWeb認証システムでは、使い捨てパスワードを表示するための専用の機器(トークン)をユーザーに配布して、安全性を高めている。トークンは、30~90秒ごとに現在時刻、日付、IDを使ってパスワードを生成する。トークンとサーバーで時刻にずれが生じると認証エラーになるため、その際には時刻のずれを補正しなければならない。

ユーザーのコンピューターがウィルスに感染している場合、ユーザーが使い捨てパスワードで認証した直後に、ウィルスによって不正送金されてしまう可能性もある。

欧米各国の金融機関を標的にした事件では、2カ月間に2000億円の被害が発生したと言われている。