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エスケープした後、「”」で囲む。

 


CakePHPは規約通りに命名することで機能的に動作する


CakePHPは、Ruby on Railsの基本理念を取り入れたMITライセンスのフレームワークとして知られている。MVCアーキテクチャを採用しており、次のような規約がある。

・コントローラの規約:コントローラのクラス名は複数形でキャメル記法で最後に Controller をつける(例:BooksController)。コントローラのクラス名は、小文字の URL パスにマップされる(例:BooksController -> example.com/books)。

・ファイルとクラス名の規約:ファイル名はクラス名と同じものになり、キャメルケースとなる(例:BooksController -> BooksController.php)。

・モデルとデータベースの規約:モデルのクラス名は単数形でキャメル記法でとなる(例:WhiteBook )。モデルに対応するテーブル名は、複数形でアンダースコア記法となる(例:WhiteBook -> white_books)。

・ビューの規約:ビューを表示するコントローラの関数に合わせた、アンダースコア記法で ビューのテンプレートファイル名を付ける(例:BooksController .getStory-> /app/views/books/get_story.ctp)。

面倒な設定を必要とするフレームワーク(たとえばstruts)とは違い、上記の規約通りに命名することで機能的に動作するようになる。

 


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文を変更できない。

 


タッチタイピング(ブラインドタッチ)の利点と習得のコツ


タッチタイピング(ブラインドタッチ)の利点は、入力速度向上、ミス修正速度向上、眼精疲労抑制とされている。
タッチタイピング習得のコツは次のようになる。
1:通常の指の位置はホームポジションに置き、キー入力で指を移動させる必要がある時だけ、その指を移動させて入力し、入力後は元の位置に指を戻す。
TouchTyping_HomePosition_QWERTY
2:キー入力時はキーボードを見ないで画面に集中する。
3:「キー配列と指の位置」を画面に表示させているキー入力練習ソフトを利用すると、指位置の確認も画面上で可能となり、効率が良い。
4:はじめは、様々な英単語のキー入力を練習して、ローマ字入力を覚える。
5:ローマ字入力を習得した後で、数字と記号のキー入力を練習する。
6:「キー配列と指の位置」を見ないで、キー入力練習ソフトの問題を1文字1秒以内にミスせず入力できるようになってから、日本語入力の練習をはじめる。


CanvasとJavaScriptへ移行するFlashコンテンツ


HTML5の機能のうち特に注目されている要素がCanvasだといわれている。Canvasはdivと同様にページの中で単純に矩形の領域をとり、JavaScriptによって洗練されたグラフィックスを描画することができる。

Canvasは、もともとApple社により、Safariの画像描画機能として開発された。Apple社は、W3Cの会合において、Canvasに関連する特許をロイヤリティフリーのライセンスで公開した。

Canvasの描画命令は、SVGと異なり、呼び出された瞬間に実行される。Canvasには、描画前に階層的な描画オブジェクトを保持するような中間的なデータ構造がないため、性能を犠牲にすることなく描画処理を積み重ねられる。

Canvas要素は、IE,Firefox,Chrome,Opera,Safariなど、主要なブラウザでサポートされている。

Canvasには、ベクターとビットマップの両方のコマンドが少数精鋭で用意されている。これらのコマンドは様々なアプリケーションで利用できる。ベクターとビットマップの違いは次のようになる。

ベクター:直線や曲線を数学的な表現で定義する。画質を損ねることなく任意に拡大できる。エッジや細部は非常に鋭い。グラフや地図などの大きな領域が単一の色やグラデーションで塗りつぶされていて詳細の密度が粗い画像に向いている。

ビットマップ:画像はJPEGフォーマットと同様に、さまざまな色のピクセルが集まったグリッドとして定義される。拡大縮小には向かない。写真のような粒度の画像に適している。

Canvasの最終的な出力は、ビットマップになる。拡大する際は、新しい拡大率でベクターコマンドを実行して再描画しなければならない。

Adobeの公式ブログには、FlashからHTML5への移行をデベロッパーに推奨するメッセージが出されている。

 


擬似乱数生成器でセッション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で暗号化していない状態では通信内容を盗聴される可能性がある。

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