「安全なウェブサイトの作り方」改訂第5版を読んで

「安全なウェブサイトの作り方」は、IPAが届出を受けた脆弱性関連情報を基に、届出件数の多かった脆弱性や攻撃による影響度が大きい脆弱性を取り上げ、ウェブサイト開発者や運営者が適切なセキュリティを考慮したウェブサイトを作成するための資料です。それが今回、携帯ウェブサイトの実装方法を追加した第5版が公表されました。

• 第1章「ウェブアプリケーションのセキュリティ実装」
  • SQLインジェクション 、OSコマンド・インジェクション やクロスサイト・スクリプティング 等9種類の脆弱性を取り上げ、それぞれの脆弱性で発生しうる脅威や特に注意が必要なウェブサイトの特徴等を解説
  • 脆弱性の原因そのものをなくす根本的な解決策、攻撃による影響の低減を期待できる対策を示しています
• 第2章「ウェブサイトの安全性向上のための取り組み」
  • ウェブサーバのセキュリティ対策やフィッシング詐欺を助長しないための対策等7つの項目を取り上げ、主に運用面からウェブサイト全体の安全性を向上させるための方策を示しています
• 第3章「失敗例」
  • 第1章で取り上げた脆弱性の中から8種類を取り上げ、ウェブアプリケーションに脆弱性を作り込んでしまった際のソースコード、その解説、修正例を示しています。
• 巻末
  • ウェブアプリケーションのセキュリティ実装の実施状況を確認するためのチェックリスト。

※PDF資料は以下のサイトでダウンロードすることができます。

• http://www.ipa.go.jp/security/vuln/websecurity.html

こちらの資料ではPDFでしか見ることが出来ず、少し読みづらいしチェックしずらいと思ったので、簡単に1章と2章だけまとめてみました。

第1章「ウェブアプリケーションのセキュリティ実装」

• 自分が選択する対策が、どのような性質を持っているのか、期待する効果が得られるものなのか、ということを正しく理解、把握することが大事

• アプリケーションにおける脆弱性対策は２つに分かれる。「根本的解決」と「保険的対策」である
  • 1.根本的解決
    • 脆弱性を作りこまない実装を実現する方法。これによって脆弱性を狙った攻撃が無効化されることが期待される。

• • 2.保険的対策
    • 攻撃による影響を軽減する方法。原因そのものをなくすものではないが、攻撃から被害までの各フェーズにおいて、それぞれの影響を軽減できる。
    • 基本的には根本的解決が望ましいが、すでに作ってしまったアプリケーションであったりコストの観点から併用する必要がある。
    • ただ、保険的対策は対策の内容によっては本来の機能を制限することになるものもあるので、そのような副作用の影響も考慮する必要がある。

具体的なセキュリティの問題点

• 1.SQLインジェクション
  • ◆根本的解決
    • SQL文の組み立ては全てプレースホルダで実装する。
    • 値を文字列型として埋め込む場合は、値をシングルクォートで囲んで記述しますが、その際に文字列リテラル内で特別な意味を持つ記号文字をエスケープ処理します（たとえば、「'」→「''」、「\」→「\\」等）。形で埋め込みます。
    • この処理は外部からの入力の影響を受ける値のみに限定して行うのではなく、SQL文を構成する全てのリテラル生成に対して行うべき。
  • ◆保険的対策
    • データベースアカウントに適切な権限を与える
    • ウェブアプリケーションがデータベースに接続する際に使用するアカウントの権限が必要以上に高い場合、攻撃による被害が深刻化する恐れがあります。
    • ウェブアプリケーションからデータベースに渡す命令文を洗い出し、その命令文の実行に必要な最小限の権限をデータベースアカウントに与えてください。
    • ※文字列リテラルのエスケープ処理
      • 文字列リテラル中にシングルクォートが現れる場合には、シングルクォートを重ねて記述することで文字としてのシングルクォートを表すというのがSQLの文法

• 2.OSコマンドインジェクション
  • ◆根本的解決
    • シェルを起動できる言語機能の利用を避ける
      • 例）Perlのopen関数は引数として与えるファイルパスに「｜」を使うことでOSコマンドを実行できるため、外部かの入力値を引数として利用する実装は危険。
      • sysopen関数であればシェルを起動することはない
  • ◆保険的対策
    • シェルを起動できる言語機能を利用する場合は、その引数を構成する全ての変数に対してチェックを行い、あらかじめ許可した処理のみを実行する。

• 3.ディレクトリ・トラバーサル

外部からのパラメータにウェブサーバ内のファイル名を直接指定している場合、
ファイル名指定の実装に問題がある場合、攻撃者に任意のファイルを指定され、
ウェブアプリケーションが意図しない処理を行ってしまう可能性がある。

• • ◆根本的解決
    • 外部からのパラメータでウェブサーバ内のファイル名を直接指定する実装を避ける
    • ファイルを開く際は、固定のディレクトリを指定し、かつファイル名にディレクトリ名が含まれないようにする
    • これを回避するために、basename()等の、パス名からファイル名のみを取り出すAPIを利用して、open(dirname+basename(filename))のような形でコーディングして、filenameに与えら　れたパス名からディレクトリ名を取り除くようにする
  • ◆保険的対策
    • ウェブサーバ内のファイルへのアクセス制限の設定うぃ正しく管理する
    • ファイル名のチェックを行う

• 4.セッション管理の不備

・セッションIDの生成規則を割り出し、有効なセッションIDを推測する
・罠を仕掛けたり、ネットワークを盗聴したりして、利用者のセッションIDを盗む
・セッションIDの固定化
　└何らかの方法で自分が取得したセッションIDを利用者に送り込み、
    利用者のログインを狙って、その利用者になりすます。

• • ◆根本的解決
    • セッションIDを憶測が困難なものにする
      • セッションIDの生成アルゴリズムに暗号論的擬似乱数生成器を用いるなど。
    • セッションIDをURLパラメータに格納しない
      • 利用者のブラウザがReferer送信機能によってセッションIDの含まれたURLをリンク先のサイトへ送信してしまう。
      • セッションIDはCookieに格納するか、POSTメソッドのhiddenパラメータに格納して受け渡しするようにする
      • ウェブアプリケーションサーバ製品によっては利用者がCookieの受け入れを拒否している場合、セッションIDをURLパラメータに格納する実装に自動的に切り替えてしまうものがある。そのような機能は、製品の設定変更を行う等によって自動切り替え機能を無効化する。
    • HTTPS通信で利用するCookieにはsecure属性を加える
      • ウェブサイトが発行するCookieにはsecure属性という項目があり、これが設定されたCookieはHTTPS通信のみで利用されます。
      • Cookieにsecure属性がない場合、HTTPS通信で発行したCookieは、経路が暗号化されていないHTTP通信でも利用されるため、このHTTP通信の盗聴によりCookie情報を不正に取得されてしまう可能性があります。
      • HTTPS通信で利用するCookieにはsecure属性を必ず加えてください。かつ、HTTP通信でCookieを利用する場合は、HTTPSで発行するCookieとは別のものを発行してください。
    • ログイン成功後に新しくセッションを開始する
    • ログイン成功後に、既存のセッションIDとは別に秘密情報を発行し、ページの遷移ごとにその値を確認する(※セッションIDをログイン前に発行している場合)
    • セッションIDとは別に、ログイン成功時に秘密情報を作成してCookieにセットし、この秘密情報とCookieの値が一致することを全てのページで確認するようにします。
  • ◆保険的対策
    • セッションIDを固定値にしない
      • 発行するセッションIDが利用者ごとに固定の値である場合、この情報が攻撃者に入手されると、時間の経過に関係なく、いつでも攻撃者からセッション・ハイジャックされてしまいます。セッションIDは、利用者のログインごとに新しく発行し、固定値にしないようにしてください。
    • セッションIDをCookieにセットする場合、有効期限の設定に注意する
      • Cookieは有効期限が過ぎるまでブラウザに保持されます。このため、ブラウザの脆弱性を悪用する等何らかの方法でCookieを盗むことが可能な場合、その時点で保持されていたCookieが盗まれる可能性があります。
      • Cookieを発行する場合は、有効期限の設定に注意してください。たとえば、Cookieの有効期限を短い日時に設定し、必要以上の期間、Cookieがブラウザに保存されないようにする等の対策をとります。
      • なお、Cookieをブラウザに残す必要が無い場合は、有効期限の設定（expires=）を省略し、発行したCookieをブラウザ終了後に破棄させる方法もあります。しかし、この方法は、利用者がブラウザを終了させずに使い続けた場合にはCookieは破棄されないため、期待する効果を得られない可能性があります。

• 5.クロスサイトスクリプティング

ウェブアプリケーションにスクリプトを埋め込むことが可能な脆弱性がある場合、
これを悪用した攻撃により、利用者のブラウザ上で不正なスクリプトが実行されてしまう可能性がある

HTMLテキストの入力を許可しない場合の対策

• • ◆根本的解決
    • ウェブページに出力する全ての要素に対して、エスケープ処理を施す
      • 脆弱性防止の観点からエスケープ処理が必須となるのは、外部からウェブアプリケーションに渡される「入力値」の文字列や、データベースやファイルから読み込んだ文字列、その他、何らかの文字列を演算によって生成した文字列等です。
      • しかし、必須であるか不必要であるかによらず、テキストとして出力するすべてに対してエスケープ処理を施すよう、一貫したコーディングをすることで、対策漏れ17を防止することができます。
      • なお、対象となる出力処理はHTTPレスポンスへの出力に限りません。JavaScriptのdocument.writeメソッドやinnerHTMLプロパティ等を使用して動的にウェブページの内容を変更する場合も、上記と同様の処理が必要です。
    • URLを出力する際は「http://」「https://」で始まるURLのみを許可する
      • URLには、「http://」や「https://」から始まるものだけでなく、「javascript:」の形式で始まるものもあります。
      • ウェブページに出力するリンク先や画像のURLが、外部からの入力に依存する形で動的に生成される場合、そのURLにスクリプトが含まれていると、クロスサイト・スクリプティング攻撃が可能となる場合があります。
      • たとえば、利用者から入力されたリンク先のURLを「」の形式でウェブページに出力するウェブアプリケーションは、リンク先のURLに「javascript:」等から始まる文字列を指定された場合に、スクリプトを埋め込まれてしまう可能性があります。
      • リンク先のURLには「http://」や「https://」から始まる文字列のみを許可する、「ホワイトリスト方式」で実装してください。
    • 要素の内容を動的に生成しない
    • スタイルシートを任意のサイトから取り込めるようにしない
      • スタイルシートには、expression()等を利用してスクリプトを記述することができます。
      • このため任意のサイトに置かれたスタイルシートを取り込めるような設計をすると、生成するウェブページにスクリプトが埋め込まれてしまう可能性があります。
  • ◆保険的対策
    • 入力値の内容チェックを行う
      • 入力チェック機能をウェブアプリケーションに実装し、条件に合わない値を入力された場合は、処理を先に進めず、再入力を求めるようにします。
      • ただし、この方法ではチェックを通過した後の演算処理の結果がスクリプト文字列を形成してしまう場合等には対処できないため、この対策のみに頼ることはお勧めできません。

HTMLテキストの入力を許可する場合の対策

• • ◆根本的解決
    • 入力されたHTMLテキストから構文解析木を作成し、スクリプトを含まない必要な要素のみを抽出する
  • ◆保険的対策
    • 入力されたHTMLテキストからスクリプトに該当する文字列を排除する

全てのアプリケーションに共通の対策

• • ◆根本的解決
    • HTTPレスポンスヘッダのContent-Typeフィールドに文字コード(charset)を指定する
      • Content-Typeフィールドで文字コードの指定を省略した場合、攻撃者が、この挙動を悪用して、故意に特定の文字コードをブラウザに選択させるような文字列を埋め込んだ上、その文字コードで解釈した場合にスクリプトのタグとなるような文字列を埋め込む可能性があります。
  • ◆保険的対策
    • Cookie情報の漏洩対策として、発行するCookieにHttpOnly属性を加え、TRACEメソッドを無効化する
      • 「HttpOnly」は、Cookieに設定できる属性のひとつで、これが設定されたCookieは、HTMLテキスト内のスクリプトからのアクセスが禁止されます。これにより、ウェブサイトにクロスサイト・スクリプティングの脆弱性が存在する場合であっても、その脆弱性によってCookieを盗まれるという事態を防止できます。
      • 具体的には、Cookieを発行する際に、「Set-Cookie:(中略)HttpOnly」として設定します。
      • なお、この対策を採用する場合には、いくつかの注意が必要です。
      • まず、ウェブサーバにおいて「TRACEメソッド」を無効とする必要があります。
      • 「TRACEメソッド」が有効である場合、サイトにクロスサイト・スクリプティングの脆弱性があると、「Cross-Site Tracing」と呼ばれる攻撃手法によって、ブラウザから送信されるHTTPリクエストヘッダの全体が取得されてしまいます。
      • HTTPリクエストヘッダにはCookie情報も含まれる20ため、HttpOnly属性を加えていてもCookieは取得されてしまいます。
      • また、HttpOnly属性は、ブラウザによって対応状況に差がある21ため、全てのウェブサイト閲覧者に有効な対策ではありません。
      • 本対策は、クロスサイト・スクリプティングの脆弱性のすべての脅威をなくすものではなく、Cookie漏えい以外の脅威は依然として残るものであること、また、利用者のブラウザによっては、この対策が有効に働かない場合があることを理解した上で、対策の実施を検討してください。

• 6.CSRF（クロスサイト・リクエスト・フォージェリ）

ログインした利用者からのリクエストについて、その利用者が意図したリクエストであるかどうかを
識別する仕組みを持たないウェブサイトは、外部サイトを経由した悪意のあるリクエストを受け入れてしまう場合が
あります。このようなウェブサイトにログインした利用者は、悪意のある人が用意した罠により、
利用者が予期しない処理を実行させられてしまう可能性があります。
このような問題を「CSRF（Cross-Site Request Forgeries／クロスサイト・リクエスト・フォージェリ）の脆弱性」
と呼び、これを悪用した攻撃を、「CSRF攻撃」と呼びます。

• • ◆根本的解決
    • 処理を実行するページをPOSTメソッドでアクセスするようにし、その「hiddenパラメータ」に秘密情報が挿入されるよう、前ページを自動生成して、実行ページではその値が正しい場合のみ処理を実行する
      • 具体的な例として、「入力画面→確認画面→登録処理」のようなページ遷移を取り上げて説明します。
      • まず、利用者の入力内容を確認画面として出力する際、合わせて秘密情報を「hidden パラメータ」に出力するようにします。
      • この秘密情報は、セッション管理に使用しているセッションIDを用いる方法の他、セッションIDとは別のもうひとつのID（第2セッションID）をログイン時に生成して用いる方法等が考えられます。
      • 生成するIDは暗号論的擬似乱数生成器を用いて、第三者に予測困難なように生成する必要があります。
      • 次に確認画面から登録処理のリクエストを受けた際は、リクエスト内容に含まれる「hiddenパラメータ」の値と、秘密情報とを比較し、一致しない場合は登録処理を行わないようにします23。
      • このような実装であれば、攻撃者が「hiddenパラメータ」に出力された秘密情報を入手できなければ、攻撃は成立しません。
      • なお、このリクエストは、POSTメソッドで行うようにします24。これは、GET メソッドで行った場合、外部サイトに送信されるRefererに秘密情報が含まれてしまうためです。

• • • 処理を実行する直前のページで再度パスワードの入力を求め、実行ページでは、再度入力されたパスワードが正しい場合のみ処理を実行する
    • Refererが正しいリンク元かを確認し、正しい場合のみ処理を実行する
  • ◆保険的対策
    • 重要な操作を行った際に、その旨を登録済みのメールアドレスに自動送信する

• 7.HTTPヘッダ・インジェクション

ウェブアプリケーションの中には、リクエストに対して出力するHTTPレスポンスヘッダのフィールド値を、
外部から渡されるパラメータの値等を利用して動的に生成するものがあります。
たとえば、HTTPリダイレクションの実装として、パラメータから取得したジャンプ先のURL情報を、
Locationヘッダのフィールド値に使用する場合や、掲示板等において入力された名前等をSet-Cookieヘッダの
フィールド値に使用する場合等が挙げられます。このようなウェブアプリケーションで、HTTPレスポンスヘッダの
出力処理に問題がある場合、攻撃者は、レスポンス内容に任意のヘッダフィールドを追加したり、
任意のボディを作成したり、複数のレスポンスを作り出すような攻撃を仕掛けること。
※HTTPレスポンス分割とキャッシュ汚染
分割されたレスポンスがキャッシュサーバにキャッシュされ、このサイトの利用者が差し替えられた
嘘のウェブページを閲覧してしまうこと

• • ◆根本的解決
    • ヘッダの出力を直接行わず、ウェブアプリケーションの実行環境や言語に用意されているヘッダ出力用APIを使用する
    • 改行コードを適切に処理するヘッダ出力用APIを利用できない場合は、改行を許可しないよう、開発者自身で適切な処理を実装する
  • ◆保険的対策
    • 外部からの入力の全てについて、改行コードを削除する

• 8.メールヘッダ・インジェクション

メール送信機能を持つウェブアプリケーションに問題がある場合、
管理者が設定した本来固定のメールアドレスではない宛先にメールを送信され、
迷惑メールの送信に悪用される可能性がある。

• • ◆根本的解決
    • メールヘッダを固定値にして、外部からの入力は全てメール本文に出力する
    • メールヘッダを固定値にできない場合、ウェブアプリケーションの実行環境や言語に用意されているメール送信用APIを使用する
    • HTMLで宛先を指定しない
  • ◆保険的対策
    • 外部からの入力の全てについて、改行コードを削除する

• 9.アクセス制御や認可制御の欠落

アクセス制御の欠落

• • ◆根本的解決
    • アクセス制御機能による防御措置が必要とされるウェブサイトには、パスワード等の秘密情報の入力を必要とする認証機能を設ける。

認可制御の欠落

• • 認証機能に加えて認可制御の処理を実装し、ログイン中の利用者が他人になりすましてアクセスできないようにする。

第2章「ウェブサイトの安全性向上のための取り組み」

• ◆ウェブサーバのセキュリティ対策
  • OSやソフトウェアの脆弱性情報を継続的に入手し、脆弱性への対処を行う
  • ウェブサーバをリモート操作する際の認証方法として、パスワード認証以外の方法を検討する（公開鍵認証など）
  • パスワード認証を利用する場合は、十分に複雑な文字列を指定する
  • 不要なサービスやアカウントを停止、削除する
  • 公開を設定していないファイルをウェブ公開用のディレクトリ以下に置かない
• ◆DNS情報の設定不備
  • ドメイン名およびそのDNSサーバの登録状況を調査し、必要に応じて対処を行う
• ◆ネットワーク盗聴への対策
  • 重要な情報を取り扱うウェブページでは、通信経路を暗号化する
    • 通信を暗号化する主な手段として、SSL（Secure Socket Layer）やTLS（Transport Layer Security）を用いたHTTPS通信の利用があります。
    • 個人情報の登録ページや認証情報をリクエストするログインページ等、保護するべき情報を扱うウェブサイトでは、通信経路を暗号化することをお勧めします。
  • 利用者へ通知する重要情報は、メールで送らず、暗号化されたhttps：//のページに表示する
  • ウェブサイト運営者がメールで受け取る重要情報を暗号化する
    • ウェブページに入力された個人情報等の重要情報を、ウェブアプリケーションに実装されたメール通知機能を利用して、ウェブサイト運営者がメールで受け取る場合は、S/MIMEやPGP等を利用してメールを暗号化するようにしてください。
    • S/MIMEやPGPを利用できない場合には、その他の方法でメール本文を暗号化するようにします。
    • なお、盗聴対策として、メールサーバ間の通信の暗号化（SMTP over SSL）やメールサーバとウェブサイト運営者との通信の暗号化（POP/IMAP over SSL）等も考えられますが、ネットワーク構成によっては、途中経路が暗号化されない可能性があるため、安全とは言えません。

• ◆パスワードの不備
  • 初期パスワードは、憶測が困難な文字列で発行する
  • パスワードの変更には、現行パスワードの入力を求める
  • 入力後の応答メッセージが認証情報の憶測のヒントとならない工夫をする
  • パスワード入力のフォームでは、入力文字列を伏字で表示する

• ◆フィッシング詐欺を助長しないための対策
  • 実在証明書付きのSSLサーバ証明書を取得し、サイトの運営者が誰であるかを証明する
  • フレームを利用する場合、子フレームのURLを外部パラメータから生成しないように実践する
  • 利用者がログイン後に移動するページをリダイレクト機能で動的に実装しているウェブサイトについて、リダイレクト先のURLとして使用されるパラメータの値には、自サイトのドメインのみを許可するようにする

• ◆WAF（WebApplicationFirewall）によるウェブアプリケーションの保護

WAFは、ウェブアプリケーションを含むウェブサイトと利用者の間で交わされるHTTP（HTTPS通信を含む32）を検査し、
攻撃等の不正な通信を自動的に遮断するソフトウェア、もしくはハードウェアです。
WAFを使用することで以下の効果を期待できます。
1. 脆弱性を悪用した攻撃からウェブアプリケーションを防御する
2. 脆弱性を悪用した攻撃を検出する
3. 複数のウェブアプリケーションへの攻撃をまとめて防御する

WAFにおけるHTTP通信の検査

• • • WAFはWAFを導入したウェブサイト運営者が設定する検出パターンに基づいて、ウェブサイトと利用者の間で交わされるHTTP通信内のHTTPリクエスト、HTTPレスポンスそれぞれの中身を機械的に検査します。
    • WAFは、検査の結果からHTTP通信がウェブサイト、利用者にとって「悪いもの」かどうかを判定します。
    • 検出パターンには、「ウェブアプリケーションの脆弱性を悪用する攻撃に含まれる可能性の高い文字列」や「ウェブアプリケーション仕様で定義されているパラメータの型、値」といったものを定義します。
    • WAFがHTTP通信を「正常である」と判定した場合（陰性判定）、検査したHTTP通信を利用者またはウェブサイトにそのまま送信します。
    • 一方、WAFがHTTP通信を「悪質である」と判定した場合（陽性判定）には、WAFは検査したHTTP通信を送信せずに設定された処理（管理者への警告、該当通信の遮断等）を実行します。
    • WAFはHTTP通信を機械的に検査しているため、人の目で見ると間違った判断となる陰性判定、陽性判定（以降、判定エラー）が生じる場合があります。

HTTP通信の検査における判定エラー

• • • HTTP通信の中身によっては、判定エラーが生じる場合があります。判定エラーには偽陽性・偽陰性の2種類があります。
    • 偽陽性とは、本来「正常である」にもかかわらず、「悪質である」と判定されるエラーです。英語では一般的にfalse positiveと呼ばれます。
    • 偽陰性とは、本来「悪質である」にもかかわらず、「正常である」と判定されるエラーです。英語では一般的にfalse negativeと呼ばれます。
    • WAFを使用する場合、偽陽性（false positive）、偽陰性（false negative）の判定が生じる可能性を考慮する必要があります。

WAFの導入検討における留意点

• • • WAFを導入するに際して、偽陽性と偽陰性の判定が生じる可能性を低くするためには、まず、WAFが検出パターンに合致するHTTP通信を検出してもHTTP通信を遮断しないように設定し、HTTP通信を監視するだけのテスト期間を設けます。
    • このテスト期間にWAFの保護対象ウェブアプリケーションを実際に使用して正当なHTTP通信が遮断されないか、また保護対象ウェブアプリケーションにあわせてWAFの検出パターンを適切に設定しているか、といったWAFの動作確認を実施します。
    • この動作確認を実施するには、保護対象ウェブアプリケーションの理解やHTTP通信に関連したプロトコルの専門的知識が要求され、かつ十分な作業工数が必要です。そのため、外部の専門家にWAFの導入を依頼することも検討してください。

携帯ウェブ向けのサイトにおける注意点

• ◆セッション管理に関する注意点
  • Cookie機能がない機種では、セッション管理のためセッションIDをURLに格納せざるを得ませんでした。
  • 一般的には、セッションIDをURLパラメータに格納していると、利用者のブラウザが、Referer送信機能によって、セッションIDの含まれたURLをリンク先のサイトへ送信してしまい、セッション・ハイジャック攻撃につながる危険があります。
  • そのため、携帯ウェブ向けのサイトでは、外部サイトへのリンクを作らないようにするか、外部サイトへのリンクを作る場合であっても、URLにセッションIDを含まないページを間に挟むようにする等の対策が取られているようです。
  • しかし、その場合でも、利用者が自らURLを公開したこと等が原因となって、そのURLのページが検索エンジンに登録されることによる個人情報漏洩事故が発生していることから、根本的な解決にはなっていません。
  • 可能な限りこのような実装は避けるべきであり、Cookie機能に非対応のキャリアにだけ上記の回避策をとり、それ以外のキャリアに対してはCookie機能を用いて通常の一般的なPC向けウェブサイトと同様に実装するのが適切でした。
  • しかし、2009年5月以降、同じキャリアでもCookie機能に非対応の機種と対応する機種が混在するようになったため、キャリア単位ではなく、機種ごとに実装方法を分けるべきと言えます。

• ◆クロスサイト・スクリプティングに関する注意点
  • 今日では携帯ウェブのブラウザによるJavaScript対応も進みつつあることから、PC向けウェブサイトと同様に、クロスサイト・スクリプティング対策が必要です。

• ◆携帯ID（個体識別番号）の使用に関する注意点
  • 携帯IDの正式名称はキャリアによって異なり、代表的なものに「iモードID」、「EZ番号」、「ユーザID」、「FOMA端末製造番号」、「FOMAカード製造番号」、「端末シリアル番号」などがあります。
  • 携帯IDには、次のような特徴があります。
    • すべてのウェブサイトに同じ携帯IDが通知される。
    • キャリアの公式サイトでなくとも通知される。
    • HTTPリクエストヘッダ（User-Agentヘッダまたは、キャリア独自の拡張ヘッダ）に格納されて、ウェブサイトに通知される。
    • 利用者の設定変更により、通知を停止することができるが、初期設定では通知される。

• ◆携帯IDによる脆弱な認証
  • ウェブサイトによっては、携帯IDだけで利用者を認証する設計のものがあります。このような認証方式は、しばしば「かんたんログイン」と呼ばれます。
  • しかし携帯IDは、すべてのウェブサイトに送信されるものですので、いわば公開情報です。このため、携帯IDを照合するだけでは、利用者を認証したことにはなりません。
  • かつて、携帯ウェブは次の2つの前提が成り立つと考えられていたことから、携帯IDを用いて利用者の認証が可能と考えられていました。
    • 1. ウェブサイトへのアクセスは、携帯ウェブのブラウザからのみ行われる。または、携帯ウェブのブラウザ以外からのアクセスをウェブサイト側で識別できる。
    • 2. 携帯ウェブのブラウザから、利用者による操作で、送信するHTTPリクエストのヘッダを任意に変更することができない。
  • しかし、近年、このような前提は実際には成り立たなくなってきました。
  • 上の前提を満たすために、キャリアが提供しているIPアドレスリストを使用し、アクセス元IPアドレスに基づく制限をする方法が、しばしば用いられます。
  • しかし、このようなリストは、キャリアが正しさを保証していなかったり、安全な取得方法が提供されていなかったり、更新のタイミングを適切に追うことができない等、様々な問題を抱えています。
  • その上、近年では一部のキャリアにおいて、PCを用いてそれらのIPアドレスからのアクセスが可能になっています。
  • 携帯IDによる利用者認証が安全であるためには、ウェブアプリケーションに届く携帯IDが偽装されないことが必要ですが、上記の通り、上の前提が崩れているため、あるキャリアでは端末に割り振られた携帯IDの偽装を回避できないこと、また、契約者に割り振られた携帯IDも、一部のキャリアではウェブアプリケーションの実装によっては偽装されてしまうことが知られています。
  • また、一般にスマートフォンでは簡単に偽装されてしまいます。
  • このように、携帯IDを用いて利用者を認証することは簡単ではありません。
  • パスワードやCookie等を使用した、PC向けサイトと同様の認証方式を採用するか、キャリアが提供する安全な認証方式を採用してください。
  • キャリアによって認定された、いわゆる公式サイトでは、キャリアから携帯IDの安全な使い方に関する情報の開示を受けられることがあります。
  • しかしそれ以外のサイトでは、その情報を得られないため、安全な使い方を把握できず、結果としてウェブサイトの安全性が損なわれる場合があります。

• ◆認証情報に関する注意点
  • 秘密ではないものを認証情報として使用
    • 認証情報は、「パスワード」や「暗証番号」など、ウェブサイトと利用者の間だけで共有される秘密情報でなくてはなりません。生年月日などは本人以外も知っている可能性があるため、ダメ。
  • 認証強度が足りない場合
    • 認証情報が、第三者による推測や試行によって破られることがないよう、ウェブサイトは、利用者が十分に複雑な認証情報を使用できるようにする必要があります。
    • 携帯電話の入力インターフェースはPCと異なる方式で、長い文字列の入力には向いていません。
    • このため携帯電話向けウェブサイトにおいては、入力する認証情報を数字のみにするといった設計がなされがちです。しかし、数字のみによる認証は、簡単に破られてしまう場合があります。
    • ウェブでは多くの場合、試行回数を確実に制限することは困難です。
    • たとえば、試行回数を制限する単純な方法として、あるユーザIDに対するパスワードの間違いが一定回数を超えた場合には、アカウントをロックするといった対策が考えられますが、このような単純な対策では、パスワードを固定してユーザIDを変更する方式の試行（リバースブルートフォース）に効果がありません。
    • ウェブにおける利用者の認証では、認証情報だけが頼りになります。認証情報を数字だけに制限したりせず、英数字を織り交ぜた桁数の多いパスワードを使用できるようにしてください。
  • 利便性との両立
    • パターン数の多いパスワードは、利用者から見れば入力の手間を要するものです。このためウェブサイトを設計する際、利便性を優先してパスワードのパターン数を少なくする方向性の設計に傾くことがあるかもしれません。
    • しかし、利用者の安全性も考慮し、パターン数を確保したまま入力頻度を減らす設計を検討してください。
    • 入力頻度を減らす方法は幾つかありますが、代表的なものは、Cookie機能を用いて一定期間有効なセッションIDを発行し、そのセッションIDが有効な間は認証済みとみなす手法です。
    • PC向けのウェブサイトではしばしば、「次回から自動的にログイン」「ログイン状態を保持する」等の説明の下、利用者の選択でこの機能を使用できる仕組みが提供されています。
    • セッションIDの有効期間を長くするほど、パスワードの入力頻度を抑えることができます。具体的な有効期間はウェブサイトのサービス内容に応じて個別に検討してください。
  • パスワードに用いる文字の種類とパターン数の関係
    • PC向けのウェブサイトでは、英数字と記号文字を織り交ぜたパスワードを使用するよう、しばしば推奨されます。
    • このようなパスワードには高い強度がありますが、携帯電話で入力することは現実的ではない場合があります。
    • 携帯電話においては、数字のみをパスワードにすることが現実的な方法として考えられますが、その場合は桁数を多くして、十分なパターン数を確保する必要があります。

これらの内容をもとに「体系的に学ぶ 安全なWebアプリケーションの作り方　脆弱性が生まれる原理と対策の実践」を読んで、知識を定着させていきたいと思っています。

体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践

最後までお読み頂き、ありがとうございました。