n階層システム設計の考慮点

第8回 セキュリティ設計について

この記事を読むのに必要な時間:およそ 5.5 分

表4 サニタイジングでの入力時チェック

問題点 考慮点とノウハウ
SQLインジェクション

ほとんどの RDBMS が準拠している「SQL92」での特殊文字のほかにも,各RDBMSが個別に拡張している文字もあるので,それらの特殊文字の確認も必要となります。主な「SQL92」での特殊文字の例は以下のものがあります。

  • 「空白,( )」⁠文字列やコマンドの区切り)
  • 「⁠⁠,⁠,,」⁠文字列の区切り)
  • 「-」⁠負の数を表すため)
  • 「.」⁠フィールドの指定)
  • 「&,+,/,|」⁠演算子)
  • 「:」⁠変数の設定)
  • 「;」⁠コマンドの区切り)
  • 「<,=,>」⁠演算子)
  • 「%,?,*,_」⁠正規表現)
OSコマンドインジェクション

.NET Frameworkが稼働する環境でのOSコマンドの例は以下のものがあります。

  • 「;,|,&」⁠コマンドの実行など)
  • 「x00」⁠NULL 文字 文字列やファイル名の中断など)
  • 「x20」⁠空白文字 パラメータの区切りなど)
  • 「x04」⁠EOT 文字 ファイルの終わりなど)
  • 「x0A,x0D」⁠改行文字 追加コマンドの実行,メールの偽造,ファイルの変更など)
  • 「x1b」⁠エスケープ文字)
  • 「x08」⁠バックスペース文字 ログファイルの偽造,ファイルの変更など)

  • 「x7f」⁠削除文字)
  • 「⁠⁠」⁠文字列の区切りなど)
  • 「/,-」⁠パラメータの指定など)
  • 「*,?」⁠正規表現など)
  • 「.,\」⁠ディレクトリ指定など)
  • 「<,>」⁠ファイル操作など)
  • 「%」⁠環境変数の参照など)
クロスサイトスクリプティング

クロスサイトスクリプティング脆弱性対策においても入力データの無効化(サニタイジング)を行います。主なサニタイジング対象文字とサニタイジング後の文字の例は以下のものがあります。

  • 「<⁠⁠→⁠&lt;」
  • 「>⁠⁠→⁠ &gt;」
  • 「&⁠⁠→⁠&amp;」
  • 「⁠⁠→⁠&quot;」
  • 「⁠⁠→⁠&#39」
URLリクエストへの無効文字挿入

URL 内に「%00」が含まれていた場合,⁠%00」をNULL 文字と解釈されないようにするため,⁠%00」についても入力データチェックを行うようにします。

メールヘッダ改ざん

メールヘッダの改竄を防止するため,メール送信を行う際のメールヘッダへの入力データ埋め込みは避けるようにします。メールヘッダはできるだけ固定化し,ユーザからの入力データはメール本文に埋め込む方式を採用します。

運用上の特徴や問題などから,メールヘッダを固定化できずメールヘッダへ入力データを埋め込む必要がある場合は,ユーザからの入力データに対して不適切な文字列が含まれていないか,メールヘッダとして適切な文字列となっているかチェックを行います。また,特殊文字に対して,無効化(サニタイジング)を行います。

おもな特殊文字の例は以下のものがあります。

「%」+ 16 進数文字列を使用して文字列を操作することができるためチェックするもの

  • 「%20」⁠スペース)
  • 「%25」⁠パーセント)
  • 「%0A」⁠改行)
  • 「%2520」⁠スペース)など

別プログラムの動作や,プログラム,OSコマンドの挿入,ファイル名の取扱時などに不適切なパラメータの挿入を防ぐためチェックするもの

  • 「!」⁠感嘆符)
  • 「&」⁠アンド)
  • 「|」⁠パイプ)
  • 「`」⁠バッククオート)
  • 「;」⁠セミコロン)
  • 「:」⁠コロン)
  • 「*」⁠アスタリスク)
  • 「,」⁠カンマ)
  • 「?」⁠疑問符)
  • 「/」⁠スラッシュ)
  • 「\」⁠バックスラッシュ)
  • 「-」⁠マイナス)
  • 「.」⁠ドット)
  • NULL(x00)
  • 「⁠⁠,⁠,{},[]など」⁠各種括弧文字)など

HTMLタグの埋め込みや,クロスサイトスクリプティングなどを防ぐためチェックするもの

  • 「<」
  • 「>」
  • 「⁠⁠」
  • 「⁠⁠」
  • 「&」など

H) ディレクトリトラバーサル

ディレクトリトラバーサルとは,相対パス記法(../~,../../~)などを利用して,本来アクセスできない(アクセス権を与えていない)はずのWebページやファイルへのアクセスを許してしまう脆弱性のことです。

これを防ぐには各ディレクトリに適切なアクセス権を与えるとともに,できる限り絶対パスを外部ファイルなどで指定し,相対パスでのアクセスを使用しないように設計します。

入力文字に「../」が含まれていないかチェックするとともに相対パスを使用するする必要がある場合にはパス名を正規化して使用します。また,指定されたパス名の存在チェックおよび対象ファイルが予約デバイス名などを含んでおらず一般ファイルであるかどうかのチェックを行います。パス名を正規化した例は以下のものがあります。

「//」を含むパス名の場合:
「/apphome//user/data⁠⁠→⁠/apphome/user/data」
「/./」を含むパス名:
「/apphome/./user⁠⁠→⁠/apphome/user」
「/../」を含むパス名:
「/apphome/user/../xml/⁠⁠→⁠/apphome/xml」

I) 不要なデコードの防止

WebアプリケーションのURL文字列中に,URLエンコーディングされた文字列「%252e%25e」が含まれていると複数回デコードすると「..」となります。これにより,意図しない階層のディレクトリやファイルへアクセスされる危険性があります。

これを防ぐためには不要なデコードはしないように設計します。また,アプリケーションで公開したくないディレクトリへのアクセス権を適切に設定します。

J) 予約デバイス名

Windows OSでは以下の文字列が予約語として使用されています。これらを入力された場合,指定されたデバイスが開かれ,最悪の場合,処理が中止される場合があります。そのため,これらの文字列を使用したディレクトリやファイル名を使用しないこととともに,入力チェックでエラーとする必要があります。

「AUX⁠⁠,⁠CON⁠⁠,⁠NUL⁠⁠,⁠PRN⁠⁠,⁠CLOCK$⁠⁠,⁠COM1~9⁠⁠,⁠LPT1~9」

K) レースコンディション

マルチスレッドアプリケーションにおいて発生する可能性があります。複数のスレッド間で同期が図られていないときに,共通のグローバル変数やファイルに対して参照・更新を行っていることにより,意図しない変数やファイル内容の更新が行われ,データの破壊やデータの正確性が損なわれる可能性があります。

そのため,これらの共通変数,データ類の操作にはスレッド同期や業務排他の仕組みを利用し,設計時に細心の注意が必要です。

しかし,スレッド同期は多用すると必要以上にオブジェクトをロックするため処理性能が落ちる可能性があります。このようなことも意識した上で,必要最小限の部分のみにスレッド同期を使用するように設計を行う必要があります。

著者プロフィール

露木敏博(つゆきとしひろ)

1966年神奈川県横浜市生まれ。1990年,株式会社日立システムアンドサービス(旧日立システムエンジニアリング株式会社)に入社。

流通系SE,営業所駐在SEなどを経て,2003年から生産技術部門で.NET技術に関する技術支援業務に携り,.NET技術に関する各種基準書および標準化,設計ガイドなどを作成。

マイクロソフトMVPアワードプログラムよりDevelopment Platforms - ASP/ASP.NETのカテゴリで2008年7月よりMVPアワードを受賞。