WEBシステムのセキュリティ技術

WEB システムの セキュリティ技術 棚橋沙弥香

目次 今回は 開発者が気をつけるべきセキュリティ対策として 以下の内容について まとめました SQLインジェクション クロスサイトスクリプティング OSコマンドインジェクション ディレクトリ トラバーサル HTTPヘッダ インジェクション メールヘッダ インジェクション

SQL インジェクションとは 1 データベースと連動した Web サイトで データベースへの問い合わせや操作を行うプログラムにパラメータとして SQL 文の断片を与えることにより データベースを改ざんしたり不正に情報を入手する攻撃をいう 画面 ユーザー ID パスワード user1 or 1 = 1 ログイン 不正なログインができてしまう 作成されるSQL SELECT * FROM user WHERE userid = user1 and passwd = or 1 = 1

SQL インジェクションとは 2 SQL インジェクションによる攻撃で 不正データの取得以外にも データ更新 削除を行うこともできる 画面 ユーザー ID パスワード user1 ;DELETE FROM user;-- ログイン データが消せてしまう 作成される SQL SELECT * FROM user WHERE userid = user1 and passwd = ;DELETE FROM user;--

SQL インジェクションの対策 1 SQL 文の呼び出しに 静的プレースホルダ 方式を用いると SQL の構文がパラメータバインド前に確定するため SQL インジェクションの発生を防げる WEB アプリ SQL の構文がこの時点で確定する データベース SELECT * FROM user WHERE userid = and passwd = =user1 =ai5$p SQL 文をバインド 実行結果 SELECT * FROM user WHERE userid = and passwd = =user1 =ai5$p SELECT * FROM user WHERE userid = user1 and passwd = ai5$p 実行結果

SQL インジェクションの対策 2 SQL 文の呼び出しに 動的プレースホルダ 方式を用いると ライブラリにバグが無ければ SQL インジェクションの発生を防げる WEB アプリ SELECT * FROM user WHERE userid = and passwd = ライブラリ内で SQL をバインド データベース =user1 =ai5$p SELECT * FROM user WHERE userid = user1 and passwd = ai5$p SELECT * FROM user WHERE userid = user1 and passwd = ai5$p 実行結果

SQL インジェクション対策 3 SQL インジェクション対策としては 静的プレースホルダ 方式を用いるのが最も望ましいが どちらのプレースホルダを用いるかは プログラミング言語とデータベースの組合せで異なる 言語 Java Java PHP PHP データベース Oracle MySQL MySQL PostgreSQL プレースホルダの実装 静的のみ 静的または 静的または 静的のみ 動的 動的 デフォルト静的動的 ( ) 動的 ( ) 静的 ) 静的プレースホルダを利用するには DB 接続時のパラメータ変更が必要

SQL インジェクションの対策 4 その他 以下の対策がある SQL 文の組み立てを文字列連結により行う場合は エスケープ処理 ( ; 受理しない 等 ) を適切に行う ウェブアプリケーションに渡されるパラメータに SQL 文を直接指定しない ( 保険的対策 ) データベースアカウントに適切な権限を与える エラーメッセージをそのままブラウザに表示しない

クロスサイトスクリプティングとは 1 ユーザーの Web ブラウザ上で 不正な HTML タグや JavaScript 等が動いてしまう攻撃をいう 画面 ユーザー ID <script>alert(document.cookie);</script> 送信 不正な JavaScript ダイアログが表示される

クロスサイトスクリプティングとは 2 クロスサイトスクリプティングにより 以下の脅威が発生し得る 本物サイト上に偽のページが表示される 偽情報の流布による混乱や フィッシング詐欺による重要情報の漏えい等が起こる ブラウザが保存している Cookie を取得される Cookie に保存されているセッション ID( ) や個人情報等の機密情報が漏えいする 任意の Cookie をブラウザに保存させられる セッション ID ( ) が利用者に送り込まれる ( ) セッション ID を利用した攻撃については次項で説明する

クロスサイトスクリプティングとは 3 クロスサイトスクリプティングで取得 設定したセッション ID を用いると 以下の セッション ハイジャック が行えてしまう

クロスサイトスクリプティングの対策 1 HTML テキストの入力を許可しない場合は 以下の対策を行う ウェブページに出力する全ての要素に対して エスケープ処理を施す データベースやファイルから読み込んだ文字列や 演算によって生成した文字列等も対象とする 変換前 変換後 & & または & < < または < > > または > ( ダブルクォート ) " または " ( シングルクォート ) &apos; または &#39;

クロスサイトスクリプティングの対策 2 HTML テキストの入力を許可しない場合 ( 続き ) HTML タグを出力する場合は その属性値を必ず ( ダブルクォート ) で括るようにする URL を出力するときは http:// や https:// で始まる URL のみを許可する ( javascript: の形式で始まるものは許可しない ) <script> </script> 要素の内容を動的に作成しない スタイルシートを任意のサイトから取り込めるようにしない ( 保険的対策 ) 入力値の内容チェックを行う

クロスサイトスクリプティングの対策 3 HTML テキストの入力を許可する場合は 以下の対策を行う 入力された HTML テキストに対して構文解析を行い スクリプトを含まない必要な要素のみ抽出する ( 保険的対策 ) 入力された HTML テキストから スクリプトに該当する文字列を削除する 例えば <script> を <xscript> javascript: を xjavascript: へ置換する

クロスサイトスクリプティングの対策 4 HTML テキストの入力を許可する / しないに関わらず 以下の対策を行う HTTP レスポンスヘッダの Content-Type フィールドに文字コード (charset) を指定する ( 保険的対策 ) Cookie 情報の漏えい対策として 発行する Cookie に HttpOnly 属性を加え スクリプトからのアクセスを禁止する ブラウザには クロスサイト スクリプティング攻撃のブロックを試みる機能を備えたものがあるので なるべくそれを利用する

OS コマンドインジェクションとは 閲覧者からのデータの入力や操作を受け付けるような Web サイトで プログラムに与えるパラメータに OS に対する命令文を紛れ込ませて不正に操作する攻撃をいう 画面 メールアドレスを入力してください メール test@test.com; rm rf / 送信 不正なデータ削除が行われてしまう 実行される OS コマンド /usr/lib/sendmail test@test.com; rm rf /

OS コマンドインジェクションの対策 1 OS コマンドを起動できる言語機能の利用をできるだけ避ける 例えば メールの送信を行うプログラムを作成するには OS コマンド ( 例 :sendmail) を利用せず 開発言語やフレームワークで用意されているメール送信の関数やメソッド ( 例 :JavaMail) を利用するようにする

OS コマンドインジェクションの対策 2 やむを得ず OS コマンドを起動できる言語機能を利用する場合は その引数を構成する全ての変数に対してチェックを行い あらかじめ許可した処理のみを実行する パラメータは引用符 で囲み パラメータ内の引用符 はエスケープ ( 例 :Linux の場合 ) する また ファイル名を引数に指定する場合は ディレクトリの指定に注意する ( 詳細は次項で説明する )

ディレクトリ トラバーサルとは 読み込みや書き込みを行うファイル名を外部パラメータとして指定可能な場合に 意図しないファイルを Web システムの処理対象としてしまう攻撃をいう?file=../../etc/secret.txt 本来見えてはいけないファイルが閲覧できてしまう

ディレクトリ トラバーサルの対策 外部からのパラメータでウェブサーバ内のファイル名を直接指定する実装を避ける ファイルを開く際は 固定のディレクトリを指定し ファイル名にディレクトリ名が含まれないようにする ( 保険的対策 ) ウェブサーバ内のファイルへのアクセス権限の設定を正しく管理する ファイル名のチェックを行う

HTTP ヘッダ インジェクションとは HTTP を使って通信するシステムにおいて 動的に HTTP ヘッダを生成する機能の不備を突いてヘッダ行を挿入することで 不正な動作を行なわせる攻撃をいう HTTP ヘッダインジェクションのあるプログラム例 header( Location:.$_GET[ url ]); リクエスト 改行コード url=http://example.jp/ %0D%0ASet-Cokkie:+SESSID=ABC 生成されるレスポンスヘッダ Location:http://example.jp/ Set-Cokkie:SESSID=ABC 改行コードにより新たなヘッダができてしまう

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

メールヘッダ インジェクションとは 宛先 (To) や件名 (Subject) などのメールヘッダを外部から指定する際に 改行文字を使ってメールヘッダや本文を追加 変更してしまう攻撃をいう メールヘッダインジェクションのあるプログラム例 header( From:.$_GET[ from ]); リクエスト 改行コード from=test%40example.com%0d%0acc:admin%40hackr.jp 生成されるレスポンスヘッダ From:test@example.com Cc:admin@hackr.jp 改行コードにより新たな宛先が追加されてしまう

メールヘッダ インジェクションの対策 メールの宛先 (To,Cc,Bcc) 件名 (Subject) などのメールヘッダを固定値にして メール本文のみ入力できるようにする メールヘッダを固定値にできない場合 ウェブアプリケーションの実行環境や言語に用意されているメール送信用 API を使用する ( 保険的対策 ) 外部からの入力の全てについて 改行コードを削除する

参考文献 IPA 情報処理推進機構 安全なウェブサイトの作り方 http://www.ipa.go.jp/security/vuln/websecurity.html