injection-encoding

脆弱性はどこで発生するのか Webアプリ機能と脆弱性の関係

前回はWeb自身が持つ脆弱性とその対策について学んだ。しかし、脆弱性の発生原因とその対策方法にはどのようなものがあるのだろうか。ここでは、Webアプリ機能と脆弱性の関係や入力処理と脆弱性の関係についてまとめる。

1 Webアプリの機能と脆弱性の関係

脆弱性はどこで発生するか

Webアプリケーションでよく用いられるスクリプト出力と、混入しやすい脆弱性の例を以下に挙げる。

  • HTMLの出力(クロスサイト・スクリプティング)
  • HTTPヘッダの出力(HTTPヘッダ・インジェクション)
  • SQLの呼び出し(SQLインジェクション)
  • シェルコマンドの呼び出し(OSコマンド・インジェクション)
  • メールヘッダおよび本文の出力(メールヘッダ・インジェクション)

 

個別の脆弱性の詳細は後述するが、脆弱性の特徴として以下の3つのことが言える。

  1. 脆弱性には処理に起因するものと出力に起因するものがある
  2. 入力に起因する脆弱性はない
  3. 出力に起因する脆弱性には「インジェクション」という単語がつくものが多い

このように、Webアプリケーションの脆弱性は、機能との関連性が強いため、設計やプログラミングをしている時点で注意すべき脆弱性は自動的に判断できる。

 

インジェクション系脆弱性

インジェクション系脆弱性とは、データの中に引用符やデリミタなど「データの終端」を示すマークを混入させて、その後の文字列の構造を変化させるものである。例えば、SQLインジェクションではSQL命令(’など)の注入、クロスサイト・スクリプティングではJavaScript(<“など)の注入で行われる。

 

2 入力処理とセキュリティ

ここでは「入力値」に着目した処理をセキュリティの観点からどう位置づけるかを説明する。入力値のチェックだけでは脆弱性は対策できないが、根本的な対策に穴があった場合の実害を防いだり軽減できる場合があるからだ。

 

Webアプリケーションの「入力」では何をするか

Webアプリケーションの入力には、HTTPリクエストとして渡されるパラメータ(GET、POST、クッキーなど)がある。この入力処理では、アプリケーションロジックの処理が始まる前にデータを準備する段階に当たる。

入力処理では入力値に対して以下の3つの処理を行う。

  1. 文字エンコーディング(符号化)の妥当性検証
  2. 文字エンコーディングの変換(必要な場合のみ)
  3. パラメータ文字列の妥当性検証

 

文字エンコーディングの検証

PHPの場合、文字エンコーディングの検証にはmb_check_encoding関数が利用できる。

bool mb_check_encoding(string $var, string $encoding)

 

文字エンコーディングの変換

文字エンコーディングの変換手段は言語によって異なる。大まかな分類として、文字エンコーディングを自動的に変換する言語と、スクリプトで変換ロジックを明示する言語がある。PHPは、pnp.iniなどの設定によって自動変換と明示的な変換を選択できる。また、文字エンコーディングを変換するには、mb_convert_encodingを使う。

  • PHP:php.ini mb_convert_encoding
  • Perl:× Encode::decode
  • Java:setCharacterEncoding Stringクラス
  • ASP.NET:Web.config ×

 

入力値の検証

  • 目的:ユーザビリティとシステムの信頼性の向上
  • セキュリティとの関係:実害に至らなくするために役立つ。例えばSQLインジェクション対策が漏れていたパラメータがあるが、英数字のみ許可していた
  • バイナリセーフとヌルバイト攻撃:値ゼロのバイト(ヌルバイト、PHP言語では\0と表記)が現れても正しく処理できる。バイナリセーフとは、入力値がどんなバイト列であっても正しく扱えることを意味する
  • 基準はアプリケーション要件:制御文字(ASCIIコード0x20未満および0x7F(DELETE)の文字)、文字数(最大文字数の設定)
  • 対象:すべてのパラメータ(hidden、ラジオボタン、select要素など)
  • 実装:PHPの正規表現ライブラリが便利。pregあるいはmb_ereg
  • 実装例(1)英数字1文字〜5文字:preg_match関数。u修飾子、i修飾子、全体一致は\Aと\zで示す、文字クラス、量指定子、mb_eregを使う場合
  • 実装例(2)住所欄:[[:^cntrl:]]というPOSIX文字クラスにより「制御文字以外」という指定をする

 

最後に

脆弱性の発生場所とその種類の関連性について、そしてWebアプリケーションの入口で行われる入力の文字エンコーディング検証と変換、入力値のチェックの実施についてまとめた。

正直に言って、細かな方法論については覚えきれていない。しかし、Webアプリ機能の「入力−処理−出力」の各過程において、有効な対策が行われていることがイメージできる。著書では今後、機能ごとに発生しやすい脆弱性について説明がなされていく。地道にたどりながら、理解を深めていこうと思う。

次回は、表示処理、SQL呼び出しおよび「重要な処理」に伴う脆弱性についてまとめる。

体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践


コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

次のHTML タグと属性が使えます: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>