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

(1)

WEBシステムの

セキュリティ技術

(2)

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

(3)

SQLインジェクションとは①

 データベースと連動したWebサイトで、データベースへの問い合わせや操作を行うプログラムにパラメータとしてSQL文の断片を与えることにより、データベースを改ざんしたり不正に情報を入手する攻撃をいう。作成されるSQL

SELECT * FROM user

WHERE userId = ‘user1’ and passwd = ‘ ‘ 画面ユーザーID パスワード user1 不正なログインができてしまう user1 ログイン ‘ or ‘1’ = ‘1 ‘ or ‘1’ = ‘1

(4)

SQLインジェクションとは②

 SQLインジェクションによる攻撃で、不正データの取得

以外にも、データ更新・削除を行うこともできる。

作成されるSQL

SELECT * FROM user

WHERE userId = ‘user1’ and passwd = ‘ ’ 画面ユーザーID パスワードデータが消せてしまう user1 ログイン

‘;DELETE FROM

(5)

user;--データベース

SQLインジェクションの対策①

 SQL文の呼び出しに、「静的プレースホルダ」方式を用いる

と、SQLの構文がパラメータバインド前に確定するため、 SQLインジェクションの発生を防げる。

SELECT * FROM user WHERE userId = ‘●’ and passwd =‘▲’

WEB アプリ

●=user1 ▲=aI5$p SELECT * FROM user

WHERE userId = ‘●’ and passwd =‘▲’

●=user1 ▲=aI5$p

SELECT * FROM user

WHERE userId = ‘user1’ and passwd =‘aI5$p’

実行結果実行結果

SQLの構文がこの時点で確定する

(6)

データベース

SQLインジェクションの対策②

 SQL文の呼び出しに、「動的プレースホルダ」方式を用いると、ライブラリにバグが無ければ、SQLインジェクションの発生を防げる。 WEBアプリ

SELECT * FROM user WHERE userId = ‘●’ and passwd =‘▲’

●=user1 ▲=aI5$p

SELECT * FROM user

実行結果 SELECT * FROM user

ライブラリ内で SQLをバインド

(7)

SQLインジェクション対策③

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

(8)

SQLインジェクションの対策④

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

(9)

クロスサイトスクリプティングとは①

 ユーザーのWebブラウザ上で、不正なHTMLタグや JavaScript等が動いてしまう攻撃をいう。画面ユーザーID 送信不正なJavaScript ダイアログが表示される <script>alert(document.cookie);</script>

(10)

クロスサイトスクリプティングとは②

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

(11)

クロスサイトスクリプティングとは③

 クロスサイトスクリプティングで取得・設定した

セッションIDを用いると、以下の「セッション・ハイジャック」が行えてしまう。

(12)

クロスサイトスクリプティングの対策①

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

(13)

クロスサイトスクリプティングの対策②

HTMLテキストの入力を許可しない場合（続き）

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

(14)

クロスサイトスクリプティングの対策③

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

(15)

クロスサイトスクリプティングの対策④

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

(16)

OSコマンドインジェクションとは

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

(17)

OSコマンドインジェクションの対策①



OSコマンドを起動できる言語機能の利用を

できるだけ避ける。

例えば、メールの送信を行うプログラムを作

成するには、OSコマンド（例：sendmail）

を利用せず、開発言語やフレームワークで用

意されているメール送信の関数やメソッド

（例：JavaMail）を利用するようにする。

(18)

OSコマンドインジェクションの対策②

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

(19)

ディレクトリ・トラバーサルとは

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

(20)

ディレクトリ・トラバーサルの対策

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

(21)

HTTPヘッダ・インジェクションとは

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

(22)

HTTPヘッダ・インジェクションの対策

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

(23)

メールヘッダ・インジェクションとは

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

(24)

メールヘッダ・インジェクションの対策

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

(25)

参考文献

 IPA 情報処理推進機構

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