Web技術者が知っておくべき9つの脅威とその対策

インターネット上には様々な脅威が溢れていますが、特に、ネット上でサービスを提供する側にとって恐ろしいのは、自分たちのサービスから利用者の個人情報を抜き取ろうという悪意の第三者による不正情報アクセスです。

Webでサービスを提供するシステムを構築した経験がある人ならわかると思いますが、セキュリティへの感度が低いアプリ技術者が開発したWebシステムというのは、本当に抜け穴だらけです。入力フォームひとつとっても、まともなバリデーションが設定されておらず、フォーム欄にSQLコマンドを入力すると、コマンド結果をきっちり返してしまうという杜撰なシステムが数多とあります。

しかし、予算をあまり割くことができないWeb開発において、Webセキュリティに優れた技術者を確保しろと言われても、コスト的に無理だと言わざるを得ない現場も多いことでしょう。

そんなジリ貧な現場で頑張らざるを寝ない皆さんにとって朗報なのが、IPA（情報処理機構）が公開している「安全なウェブサイトの作り方」というPDFファイルです。

『脆弱性対策：安全なウェブサイトの作り方』
http://www.ipa.go.jp/security/vuln/websecurity.html

以下、目次をご覧ください。

 ＜ウェブアプリケーションのセキュリティ実装＞

１） SQL インジェクション
２） OS コマンド・インジェクション
３） パス名パラメータの未チェック
／ディレクトリ・トラバーサル
４） セッション管理の不備
５） クロスサイト・スクリプティング
６） CSRF
（クロスサイト・リクエスト・フォージェリ）
７） HTTP ヘッダ・インジェクション
８） メールヘッダ・インジェクション
９） アクセス制御や認可制御の欠落

Web開発技術者にとって一度は聞いたことのあるセキュリティ用語がずらっと並んでいます。良識ある技術者なら「これくらい知っていて当然」と思うのかもしれませんが、では中身を他の人にちゃんと説明できるでしょうか。具体的な実装対策、リスクを軽減するための方法も含めるなら、説明できる人は一握りの人しかいないと思われます。

このPDFファイルには、それらが図や構文入りで記載されていますし、実装の失敗例も構文付きで解説されているので、はじめてWeb開発に取り組む人でも、いきなりセキュリティ専門家に近い目線で実装していくことが可能です。

せっかくなので、前述した『Web開発における9つの脅威』について解説します。

１） SQL インジェクション
データベースと連携したウェブアプリケーションの多くは、利用者からの入力情報を基にSQL 文（データベースへの命令文）を組み立てています。ここで、SQL 文の組み立て方法に問題がある場合、攻撃によってデータベースの不正利用をまねく可能性があります。

脅威の例：
- データベースに蓄積された非公開情報の閲覧
- データベースに蓄積された情報の改ざん、消去
- 認証回避による不正ログイン
- ストアドプロシージャ等を利用したOS コマンドの実行

根本解決：
・SQL 文の組み立ては全てプレースホルダで実装する。
・SQL 文の組み立てを文字列連結により行う場合は、エスケープ処理等を行うデータベースエンジンのAPI を用いて、SQL 文のリテラルを正しく構成する。
・ウェブアプリケーションに渡されるパラメータにSQL 文を直接指定しない。

２） OS コマンド・インジェクション
ウェブアプリケーションによっては、外部からの攻撃により、ウェブサーバのOS コマンドを不正に実行されてしまう問題を持つものがあります。

脅威の例：
- サーバ内ファイルの閲覧、改ざん、削除
- 不正なシステム操作
- 不正なプログラムのダウンロード、実行
- 他のシステムへの攻撃の踏み台

根本解決：
・シェルを起動できる言語機能の利用を避ける。
・シェルを起動できる言語機能を利用する場合は、その引数を構成する全ての変数に対してチェックを行い、あらかじめ許可した処理のみを実行する。

３） パス名パラメータの未チェック／ディレクトリ・トラバーサル
ウェブアプリケーションの中には、外部からのパラメータにウェブサーバ内のファイル名を直接指定しているものがあります。このようなウェブアプリケーションでは、ファイル名指定の実装に問題がある場合、攻撃者に任意のファイルを指定され、ウェブアプリケーションが意図しない処理を行ってしまう可能性があります。

脅威の例：
- サーバ内ファイルの閲覧、改ざん、削除

根本解決：
・外部からのパラメータでウェブサーバ内のファイル名を直接指定する実装を避ける。
・ファイルを開く際は、固定のディレクトリを指定し、かつファイル名にディレクトリ名が含まれないようにする。

４） セッション管理の不備
ウェブアプリケーションの中には、セッションID（利用者を識別するための情報）を発行し、セッション管理を行っているものがあります。このセッションID の発行や管理に不備がある場合、悪意のある人にログイン中の利用者のセッションID を不正に取得され、その利用者になりすましてアクセスされてしまう可能性があります。
また、推測や盗用以外に、セッション管理の不備を狙ったもう一つの攻撃手法として、「セッションID の固定化（Session Fixation）」と呼ばれる攻撃手法があります。悪意ある人があらかじめ用意したセッションID を、何らかの方法で利用者に送り込み、利用者がこれに気付かずにパスワードを入力するなどしてログインすると起こりうる問題です。悪意のある人がこの攻撃に成功すると、あらかじめ用意したセッションID を利用し、利用者になりすましてウェブサイトにアクセスすることができてしまいます。

脅威の例：
- ログイン後の利用者のみが利用可能なサービスの悪用
- ログイン後の利用者のみが編集可能な情報の改ざん、新規登録
- ログイン後の利用者のみが閲覧可能な情報の閲覧

根本解決：
・セッションID を推測が困難なものにする。
・セッションID をURL パラメータに格納しない。
・HTTPS 通信で利用するCookie にはsecure 属性を加える。
・ログイン成功後に、新しくセッションを開始する。
・ログイン成功後に、既存のセッションIDとは別に秘密情報を発行し、ページの遷移ごとにその値を確認する。

５） クロスサイト・スクリプティング
ウェブアプリケーションの中には、検索のキーワードの表示画面や個人情報登録時の確認画面、掲示板、ウェブのログ統計画面等、利用者からの入力内容やHTTP ヘッダの情報を処理し、ウェブページとして出力するものがあります。ここで、ウェブページへの出力処理に問題がある場合、そのウェブページにスクリプト等を埋め込まれてしまいます。

脅威の例：
- 本物サイト上に偽のページが表示される
- ブラウザが保存しているCookie を取得される
- 任意のCookie をブラウザに保存させられる

根本解決：
（HTML テキストの入力を許可しない場合）
・ウェブページに出力する全ての要素に対して、エスケープ処理を施す。
・URL を出力するときは、「http://」や 「https://」で始まるURL のみを許可する。
・<script>...</script> 要素の内容を動的に生成しない。
・スタイルシートを任意のサイトから取り込めるようにしない。

（HTML テキストの入力を許可する場合）
・入力されたHTMLテキストから構文解析木を作成し、スクリプトを含まない必要な要素のみを抽出する

（全てのウェブアプリケーションに共通の対策）
・HTTPレスポンスヘッダのContent-Typeフィールドに文字コード（charset）を指定する。

６） CSRF （クロスサイト・リクエスト・フォージェリ）
ウェブサイトの中には、サービスの提供に際しログイン機能を設けているものがあります。ここで、ログインした利用者からのリクエストについて、その利用者が意図したリクエストであるかどうかを識別する仕組みを持たないウェブサイトは、外部サイトを経由した悪意のあるリクエストを受け入れてしまう場合があります。このようなウェブサイトにログインした利用者は、悪意のある人が用意した罠により、利用者が予期しない処理を実行させられてしまう可能性があります。

脅威の例：
- ログイン後の利用者のみが利用可能なサービスの悪用
- ログイン後の利用者のみが編集可能な情報の改ざん、新規登録

根本解決：
・処理を実行するページをPOST メソッドでアクセスするようにし、その「hidden パラメータ」に秘密情報が挿入されるよう、前のページを自動生成して、実行ページではその値が正しい場合のみ処理を実行する。
・処理を実行する直前のページで再度パスワードの入力を求め、実行ページでは、再度入力されたパスワードが正しい場合のみ処理を実行する。
・Referer が正しいリンク元かを確認し、正しい場合のみ処理を実行する。

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

脅威の例：
- クロスサイト・スクリプティング攻撃により発生しうる脅威と同じ脅威
- 任意のCookie 発行
- キャッシュサーバのキャッシュ汚染

根本解決：
・ヘッダの出力を直接行わず、ウェブアプリケーションの実行環境や言語に用意されているヘッダ出力用API を使用する。
・改行コードを適切に処理するヘッダ出力用API を利用できない場合は、改行を許可しないよう、開発者自身で適切な処理を実装する。

８） メールヘッダ・インジェクション
ウェブアプリケーションの中には、利用者が入力した商品申し込みやアンケート等の内容を、特定のメールアドレスに送信する機能を持つものがあります。一般に、このメールアドレスは固定で、ウェブアプリケーションの管理者以外の人は変更できませんが、実装によっては、外部の利用者がこのメールアドレスを自由に指定できてしまう場合があります。

脅威の例：
- メールの第三者中継

根本解決：
・メールヘッダを固定値にして、外部からの入力はすべてメール本文に出力する。
・メールヘッダを固定値にできない場合、ウェブアプリケーションの実行環境や言語に用意されているメール送信用API を使用する。
・HTML で宛先を指定しない。

９） アクセス制御や認可制御の欠落
ウェブサイトの中には、運営者のセキュリティに対する認識のなさから、不適切な設計で作成されたウェブサイトが運用されていることがあります。

脅威の例：
- 不正ログイン助長

根本解決：
・アクセス制御機能による防御措置が必要とされるウェブサイトには、パスワード等の秘密情報の入力を必要とする認証機能を設ける。
・認証機能に加えて認可制御の処理を実装し、ログイン中の利用者が他人になりすましてアクセスできないようにする。

今回紹介したPDFファイルには、前述の脅威に対するセキュリティ対策（ウェブサーバ、DNSサーバ、ネットワーク）などが続いています。導入している企業も増えたWAF（Web Application Firewall）についても取り上げられているので、Webセキュリティ実装の現状を具体的に把握するのに有用です。

Webアプリケーション開発の皆様、特にインターネット上で利用されるサービスを開発している方は、この文書をいますぐダウンロードして、穴が開くまで読み込むことをお勧めします。