「セキュリティ面が怖いからネットは使わない」そういう人もいるだろう。しかし、火を正しく使えば安全なように、ネットにも安全に使う方法がある。ここでは、HTTP、セッション管理、同一生成元ポリシーといったWebセキュリティの前提となる基礎知識についてまとめる。
１ HTTPとセッション管理
なぜHTTPか
Webアプリケーションの脆弱性には、Web固有の特性に由来するものがある。そのため、HTTPやセッション管理についての理解が不可欠である。
一番簡単なHTTP
以降の例は、すべて著者が「http://example.jp」にメニューとして提示してくれている。順に箇条書きで挙げていく。
- Burp SuiteによるHTTPメッセージの観察（現在時刻のスクリプト）
- リクエストメッセージ：メソッド、リクエストURL、プロトコルバージョン
- レスポンスメッセージ
- ステータスライン
- レスポンスヘッダ
入力-確認-登録パターン
ここでは、名前・メールアドレス・性別の入力画面、確認画面、登録画面を通して学ぶ。
- POSTメソッド
- メッセージボディ：ブラウザから入力された値。POSTにより送信される値に関するヘッダがContent-Length（ボディのバイト数）とContent-Type（送信する値のMIMEタイプ）
- パーセントエンコーディング：特殊記号や日本語などURLに使用できない文字をURL上に記述する場合に用いられる。対象の文字をバイト単位で「%xx」という形式で表す。xxはバイトの16進数表記
- Referer：リンク元のURLを示すヘッダ
- GETとPOSTの使い分け：データ更新など副作用を伴うリクエストの場合、秘密情報を送信する場合、送信するデータの総量が多い場合のどれかに当てはまればPOSTメソッドを利用するべき
- hiddenパラメータは書き換え可能：ブラウザから送信する値は書き換えられる
- hiddenパラメータのメリット：情報漏洩や第三者からの書き換えに対して堅牢
HTTP認証も以前の状態を保持しない
- Basic認証：認証の必要なページにアクセス、ブラウザがユーザ名とパスワードを要求、認証情報を伴って再リクエスト、ドキュメントが得られるという流れ。Webサーバーの設定などで実現する場合が多いが、PHPの機能でプログラミングすることも可能
- 認証と認可：認証（authentication）とは本人確認のことで、認可（authorization）とは認証済みの利用者に権限を与えること
クッキーとセッション管理
クッキー（cookie）とは、セッション管理をHTTPで実現するために導入された仕組みである。セッション管理とはアプリケーションの状態を覚えておくことで、クッキーはサーバー側からブラウザに対して「名前＝変数」の組を覚えておくように指示する。例えば、ECサイトのショッピングバスケットなどがある。
「クッキーによるセッション管理」は、認証と利用者情報表示を簡素化したもので、3つの画面から構成される。IDとパスワードの入力画面、IDとパスワードによる認証画面、個人情報（ID）の表示画面である。
- クッキーの特徴：保持できる値の個数や文字列長には制限がある。値が利用者本人には参照・変更できるので、秘密情報の格納には向かない
- セッション管理のポイント：開発ツールの提供するセッション管理機構を利用する、認証後にセッションIDを変更する
- セッションIDの要件：第三者が推測できない、強制されない、漏洩しない
- セッションID漏洩の原因：クッキー発行の際の属性不備、ネットワーク的盗聴、アプリケーションの脆弱性、プラットフォームの脆弱性、Refererヘッダ
- クッキーの属性：Domain（サーバーのドメイン）、Path（URLのディレクトリ）、Expires（クッキー値の有効期限）、Secure（SSLの場合のみクッキーを送信）、HttpOnly（JavaScriptからアクセス不可）
２ 受動的攻撃と同一生成元ポリシー
能動的攻撃と受動的攻撃
- 能動的攻撃（active attack）：攻撃者がWebサーバーに対して直接攻撃すること。例えばSQLインジェクション攻撃など
- 受動的攻撃（passive attack）： 攻撃者がWebサイトの利用者に罠を仕掛けることにより、罠を閲覧したユーザを通してアプリケーションを攻撃すること。単純なもの（罠閲覧→仕掛けのあるHTML→マルウェア感染）、正規サイトを悪用するもの、サイトをまたがるものがある
- 正規サイトを悪用する受動的攻撃：正規サイトへ不正操作→サイト閲覧→仕掛けのあるHTML→マルウェア感染・情報漏洩・不正操作という経路のもの。例えばガンブラー（Gumblar）など
- サイトをまたがった受動的攻撃：罠サイトの罠閲覧→仕掛けのあるHTML→正規サイトへ攻撃用リクエスト（不正操作（CSRF））→仕掛けを含むレスポンス→情報漏洩・不正操作（XSSなど）という経路のもの。例えばクロスサイト・リクエストフォージェリ（CSRF）やクロスサイト・スクリプティング（XSS）、HTTPヘッダ・インジェクションなど
ブラウザはどのように受動的攻撃を防ぐか
- サンドボックス（sandbox）：プログラムのできることを制限する環境のこと。JavaScriptやJavaアプレット、Adobe Flash Playerなどで採用されている考え方。一般的に以下のように機能が制限される。ローカルファイルへのアクセスの禁止、プリンタなどの資源の利用禁止、ネットワークアクセスの制限（同一生成元ポリシー）
- 同一生成元ポリシー（same origin policy）：JavaScriptによるサイトをまたがったアクセスを禁止するセキュリティ上の制限であり、ブラウザのサンドボックスに用意された制限の1つ。著書ではJavaScriptによるiframeアクセスの実験を介して、その必要性を説明している
- 同一生成元である条件：URLのホスト（FQDN;Fully Qualified Domain Name）が一致している、スキーム（プロトコル）が一致している、ポート番号が一致している
- アプリケーション脆弱性と受動的攻撃：クロスサイト・スクリプティング（XSS）攻撃とは、JavaScriptを送り込むことで同一生成元ポリシー下でJavaScriptを実行するもの
- 第三者のJavaScriptを許可する場合：サイト運営者が第三者を信頼して実行するJavaScript（アクセス解析、バナー広告、ブログパーツなど）と閲覧者が第三者を信頼して埋め込むJavaScript（Firefoxのグリースモンキーアドオンなど）の2つのケースがある。
JavaScript以外のクロスドメインアクセス
- frame要素とiframe要素：JavaScriptによるクロスドメインのドキュメントへのアクセスは禁止
- img要素：img要素のsrc属性は可能。
- script要素：script要素にsrc属性を指定すると他のサイトからJavaScriptを読み込むことができる
- CSS（Cascading Style Sheets）：クロスドメインでの読み込みが可能。例えばHTMLのlink要素や、CSS内から@import、JavaScriptからaddImportメソッド
- form要素のaction属性：formの送信（submit）はFavaScriptから常に操作可能
最後に
Webアプリケーションの脆弱性の理解に役立つ、HTTP、Basic認証、クッキー、セッション管理、そして受動的攻撃とそれに対するブラウザの防御戦略である同一生成元ポリシーについてまとめた。
実際に実験を行っていくと、想像以上に簡単に「攻撃」ができることがわかる。しかし、その分同一生成元ポリシーといった「対策」が準備されていることもわかる。そのWebサイトがどの程度対策されているものかを判断する知識さえ身につければ、必要以上に恐れることはないのだろう。状況に合わせてクッキーの活用などをすることで、より快適なWeb体験ができる。最低限のセキュリティに対する知識があるだけで、私たちの生活はより選択肢が増え、豊かになるだろう。
次回は、Webアプリケーションの機能および入力値と脆弱性の関係についてまとめる。
 |
「HTTPとセッション管理、同一生成元ポリシーがセキュリティの基礎」への1件のフィードバック