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

Size: px

Start display at page:

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

さいぞうたけくま
5 years ago
Views:

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

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

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

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

5 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 をバインドデータベース =user1 =ai5$p SELECT * FROM user WHERE userid =

6 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 実行結果

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

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

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

ブラウザが保存している Cookie を取得される Cookie に保存されているセッション ID( )

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

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

データベースやファイルから読み込んだ文字列や演算によって生成した文字列等も対象とする変換前変換後 &

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

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

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

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

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

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

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

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

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

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

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

$_GET[ from ]); リクエスト改行コード from=test%40example.

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

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

25 参考文献 IPA 情報処理推進機構安全なウェブサイトの作り方

SQL インジェクションの脆弱性

別紙脆弱性体験学習ツール AppGoat ハンズオンセミナー演習解説 SQL インジェクションの脆弱性 [ 演習 ] AppGoat を用いた疑似攻撃体験 SQL インジェクションのテーマ不正なログイン ( 文字列リテラル ) 画面上に Congratulations!! と表示されると演習クリアです 3 脆弱性のある箇所を特定するログイン ID またはパスワードにシングルクォート ' を入力し