情報処理安全確保支援士(情報セキュリティスペシャリスト)試験に合格するためのサイトです。
過去問を多数引用しながら、基礎知識をしっかり学んでもらうように作ってあります。
また、情報処理安全確保支援士(情報セキュリティスペシャリスト)を楽しく学べるように工夫したいと思います。
カテゴリ:

9.サーバセキュリティ > 9.2 インジェクション攻撃

過去問では、SQLインジェクションに関して、以下のように述べられている。
「Webアプリケーションに悪意ある入力データを与えてデータベースの問合せや操作を行う命令文を組み立てて、データを改ざんしたり不正に情報取得したりする攻撃」(H22AP秋 午前問43)より

SQLインジェクションは、SQL文を操作する文字列をWebフォームなどに注入(Injection)し、データベースに不正にアクセスする攻撃。
例えば、以下のようなフォームがある。
login画面_情報セキュリティスペシャリスト試験

サーバの認証プログラムとして、以下のSQL文が入っているとします。

 SELECT * FROM USER WHERE UserName = '(フォームのユーザ名が入る)'

ここで、フォームに a' or '1'='1 と入力すると
 SELECT * FROM USER WHERE UserName = 'a' or '1'='1'
となり、どんなユーザを入れても成立してしまう。または、コメントを意味する「--」を付ければ、それ以降が無視される。

コマンドを成功させるだけでなく、SQLのUNION句を使って別のSQL文をくっつければ、DBの中身を表示することも可能だ。

対策に関しては、IPAのサイトから以下が公開されています。
http://www.ipa.go.jp/security/vuln/documents/200811_JOGA.pdf
http://www.ipa.go.jp/security/vuln/vuln_contents/sql.html

SQLインジェクションの対策は、IPAの以下の資料にまとめられています。
http://www.ipa.go.jp/files/000024396.pdf

その情報を参考にすると、主な対策は以下です。

1.根本的解決
(1)エスケープ処理
①バインド機構の利用
②プログラムでのエスケープ処理
 入力フォームによる入口でのチェックも有用
 
2.保険的対策
(1)エラーメッセージを非表示
 エラーメッセージは、攻撃者に情報を与えてしまう。
 また、ブラインドSQLインジェクション(Blind SQL injection)という手法があり、入力値と応答結果から、脆弱性を把握する。たとえば、ID/Passを入力したときに、「IDが存在しません」「パスワードが間違っています」と丁寧にエラーを返せば、攻撃者にもIDが違うのかPassが違うのかの情報を与えてしまう。
(2)データベースアカウント
権限の見直し。必要最小限の権限しか与えておかなければ、被害も少なくなる。

H21SC春午前Ⅱ問14
SQLインジェクション対策について、Webアプリケーションの実装における対策とWebアプリケーションの実装以外の対策の組合せとして、適切なものはどれか。

Webアプリケーションの実装における対策

Webアプリケーションの実装以外の対策
Webアプリケーションの中でシェルを起動しない。chroot環境でWebサーバを実行する。
セッションIDを複雑なものにする。SSLによって、通信内容を秘匿する。
バインド機構を利用する。データベースのアカウントのもつデータベースアクセス権限を必要最小限にする。
パス名やファイル名をパラメタとして受け取らないようにする。重要なファイルを公開領域に置かない。
 
今回の内容はとても難しい内容ですが、SQLインジェクションというキーワードから、「データベース」に関する対策を選ぶと、ウのみになります。

これを使えば、エスケープ処理は不要だ。
http://www.ipa.go.jp/files/000024396.pdf

静的プレースホルダは情報処理技術者試験で問われるキーワードです。バインド機構や、プリペアドステートメントという言葉を使う場合もあります。Prepared Statementなので「用意された構文」です。用意された構文が変化することなく、入力された文字は文字列として理解されるので不正な文字を入れるという攻撃を防げます。

具体例をみましょう。以下は、上記サイトの引用であるが、入力されたデータは「?」で表わされます。そして、入力されたデータが文字として直接実行されるのだ。
$sth = $dbh->prepare(
"SELECT id, name, tel, address, mail FROM usr WHERE uid=? AND passwd=?");
$sth->execute($uid, $passwd);
1

わかったような…
これまでは、上記のuidのところに、以下のように入力されると、構文が変わってしまう。
1' or 'a'='a' --
 しかし、?で処理し、値だけを判断するので、 「1' or 'a'='a' --」という文字列で処理される。


1.サニタイジング(エスケープ)処理とは
SQL インジェクション対策はサニタイジング(エスケープ)処理が一般的です。
過去問では、SQLインジェクション攻撃を防ぐ方法として、「入力値から,データベースへの問合せや操作において特別な意味をもつ文字を解釈されないように保護する。(H20SU 午前問題 問26より)」と述べられている。これはサニタイジングを意味している。

Webフォームなどに、<script> のようなスクリプトが埋め込まれた場合、HTMLではスクリプトと判断してスクリプトが実行されます。単純な例を挙げます。以下の記載をしたとします。

<script>alert("こんにちは");</script>

すると、画面に以下のようなポップアップ画面(アラート)が表示されます。あなたが掲示板の管理者だとして、このような書き込みをされたとすると、その掲示板を開くたびにこのアラートが出てしまいます。困りますよね。
alert_情報セキュリティスペシャリスト試験
掲示板でのポップアップレベルならいいですが、個人情報を抜かれたり、サーバを乗っ取るようなコマンドを仕掛けられることもあります。これは防がなければいけません。

2.サニタイジング(エスケープ)処理の方法1
対策(エスケープ処理)として、<script>などの文字を、Webサーバ上ではプログラム用の言葉ではなく、単なる文字として認識させます。具体的には「<」を「&lt;」としてエスケープ処理をします。すると、Webサーバ側では、&lt;script&gt; となりますので、これはプログラム用の言葉ではないと判断されるのです。
7a536a8a

 &lt;script&gt; 書いたとしても、
ブラウザ上では <script> と表示されるのですね。



はいそうです。ブラウザがきちんと自動で認識をしてくれます。掲示板などに&lt;script&gt;と書き込んで試してみるといいでしょう。

エスケープ処理(サニタイジング処理)における、文字の変換例は以下です。

表2 文字の置換
元の文字置換後の文字列
 &&amp;
 < &lt;
 > &gt;
&#39;
&quot;
(H18年SV午後Ⅰ問1表2より引用)

これを丸暗記しようとすると難しいが、意味を理解すると覚えやすい。例えば「&」であれば、本来の名称であるampersand、「<」であれば、less than(~より小さい)のltである。

セキュアプログラミングに関しては、IPAのサイトに充実した解説がされている。http://www.ipa.go.jp/security/awareness/vendor/programming/index.html

3.サニタイジング(エスケープ)処理の方法2
別の例を見ましょう。SQLインジェクション対策としてのエスケープ処理の具体的な処理としては、 ' を '' に変換します。サニタイジングをしない場合、UserNameに a' or '1'='1' と入力すると、データベース側では、
 SELECT * FROM USER WHERE UserName = 'a' or '1'='1'
と判断され、'1'='1'は正しいことから、不正なアクセスが可能だ。
一方で、サニタイジングをすると、同じ入力をした場合、以下になる。
 SELECT * FROM USER WHERE UserName = 'a'' or ''1''=''1'
こうなると、SQLの構文として不適切であり、この部分は「文字列」として扱われる。
なおかつ、データベース側では、''は'という文字列として自動認識してくれるので、入力した通りの文字として正常に処理される。
情報セキュリティスペシャリスト試験を目指すSE成子

サニタイジングとエスケープ処理との違いはなんですか?
同じですか?
まあ、一緒と思ってもいいだろう。
サニタイジング(無害化)の方法の一つが文字の変換などによるエスケープ処理。サニタイジングの方法は、エスケープ処理以外に、特殊文字は入力させない、処理を強制終了させるなどがある。
又は、もっと単純に、’などの特殊文字をそもそも受け付けず、入力フォームにてエラーを出すことも方法の一つ。

参考:Taintモード
Perlの場合、Taintモード(汚染検出用のモード)がある。
IPAの以下の資料には、次のような効果が記載されている。http://www.ipa.go.jp/security/awareness/vendor/programmingv1/pdf/a04_03.pdf

このモードでは,フォームからのデータのみでなく,コマンドライン引数,環境変数,ロカール情報 ,幾つかのシステムコール(readdir,readlink,getpw* 呼び出しのgecos フィールド)の結果,すべてのファイル入力などを汚染データとして扱い,これらのデータをサブシェルを起動するコマンド(system,exec など)や,ファイルやディレクトリ,プロセスに変更を加えるようなコマンド(unlink,umask など)の引数として使用した場合,エラーとしてくれる。

設定は簡単
#!/usr/bin/perl -T ←これをつけるだけ
ただ、万能ではないし、実装されていることも少ない(気がする)。

1.OSコマンドインジェクションとは
SQLインジェクションと同様に、脆弱性のあるサーバに対し、OSのコマンドをインジェクション(injection:注入)します。これによる脅威として、IPAの資料(https://www.ipa.go.jp/files/000017316.pdf)では以下のように記載されています。OSコマンドが自由に実行されると何が起こるかを考えると、理解しやすいでしょう。
■ 発生しうる脅威
OS コマンド・インジェクション攻撃により、発生しうる脅威は次のとおりです。
- サーバ内ファイルの閲覧、改ざん、削除
 重要情報の漏えい、設定ファイルの改ざん 等
- 不正なシステム操作
 意図しないOS のシャットダウン、ユーザアカウントの追加、変更 等
- 不正なプログラムのダウンロード、実行
 ウイルス、ワーム、ボット等への感染、バックドアの設置 等
- 他のシステムへの攻撃の踏み台
 サービス不能攻撃、システム攻略のための調査、迷惑メールの送信 等

2.OSコマンドインジェクションの対策
対策としては、同じくIPAの上記サイト(https://www.ipa.go.jp/files/000017316.pdf)に、以下の2点が記載されています。
①シェルを起動できる言語機能の利用を避ける。
②シェルを起動できる言語機能を利用する場合は、その引数を構成する全ての変数に対してチェックを行い、あらかじめ許可した処理のみを実行する。
少し補足します。①に関しては、Perlでファイルを開く場合、シェルを起動できてしまうopen関数ではなく、sysopen関数を利用します。
②に関しては、「|」、「<」、「>」等、問題となりうる文字をチェックし、それが見つかった場合には処理を中断します。

では、過去問を解いてみましょう。 
問15 Webアプリケーションの脆弱性を悪用する攻撃手法のうち,Perlのsystem関数やPHPのexec関数など外部プログラムの呼出しを可能にするための関数を利用し,不正にシェルスクリプトや実行形式のファイルを実行させるものは,どれに分類されるか。
ア HTTPヘッダインジェクション
イ OSコマンドインジェクション
ウ クロスサイトリクエストフォージェリ
エ セッションハイジャック
(H26SC午前Ⅱ問15)
正解はイです。「外部プログラムの呼出しを可能にするための関数を利用し」とあります。これは、たとえば、Perlのopen関数を使い、引数に「|」を活用してOSコマンドを渡します。そうして、不正にコマンドやファイルを実行します。

1.ディレクトリトラバーサルとは
トラバーサル(traversal)とは「横断」という意味である。
横断歩道は、本来は車のために縦方向にある流れを歩行者のために横に断ち切る。ディレクトリトラバーサルも同様で、横断的にファイルにアクセスする。
以下のサイトがかなり重要。他にもたくさん大切なページがある
http://www.ipa.go.jp/security/vuln/vuln_contents/dt.html

では、過去問を見てみよう。
問45 ディレクトリトラバーサル攻撃に該当するものはどれか。
ア Webアプリケーションの入力データとしてデータベースへの命令文を構成するデータを入力し,想定外のSQL文を実行させる。
イ Webサイトに利用者を誘導した上で, Webサイトの入力データ処理の欠陥を悪用し,利用者のブラウザで悪意のあるスクリプトを実行させる。
ウ 管理者が意図していないパスでサーバ内のファイルを指定することによって,本来は許されないファイルを不正に閲覧する。
エ セッションIDによってセッションが管理されるとき,ログイン中の利用者のセッションIDを不正に取得し,その利用者になりすましてサーバにアクセスする。 (H24FE春 午前問45)」
正解はウである。
もう一問。これの正解は「ディレクトリトラバーサル」であるが、以下を見ると、どのように不正な操作をするのかが分かると思う。
[ ]に入れる適切な字句を15字以内で答えよ
 GET /cgi-bin/enquete.cgi view=../../../../../../../../../../../../../../../../../../../etc/passwd HTTP/1.1
図5 5021番の脅威と判定したパケットに含まれていた文字列

パケットに含まれる文字列からすると、CGIプログラムに含まれる[  ]の脆弱性を利用して、パスワードファイルを取得することをねらったもののようです。(H22SC春午後Ⅱ問2設問3(1)より)

有名な事件として、2003年に、某協会のホームページから個人情報1184人分が流出した。
原因は、サイト側の脆弱性ではあったが、そこをついて情報を公開した大学の研究者は、不正アクセス禁止法で逮捕されることになった様子。

2.絶対パスと相対パス
過去問(H25年秋FE午後問11)では、絶対パスと相対パスに関して、以下の記載があります。
「パスは,木構造をもつファイルシステムにおいてディレクトリを特定するために利用される文字列であり,ディレクトリの名前を“/”で区切って並べて表す。“/”で始まるパスを絶対パスという。絶対パスはルートディレクトリを起点として表したパスである。“/”で始まらないパスを相対パスという。相対パスは任意のノートを起点として表したパスである。」

HTTPヘッダインジェクションとは
情報セキュリティスペシャリスト試験を目指す女性SE

インジェクションは「注入」という意味ですから、HTTPのヘッダに悪意のコードを注入(インジェクション)するのですね。
そう考えてよい。
情報処理振興機構(IPA)の「安全なウェブサイトの作り方 改訂第7版」には、HTTPヘッダ・インジェクションについて次のように説明されている。
ウェブアプリケーションの中には,リクエストに対して出力する HTTP レスポンスヘッダのフィールド値を,外部から渡されるパラメータの値等を利用して動的に生成するものがあります。たとえば,HTTPリダイレクションの実装として,パラメータから取得したジャンプ先の URL 情報を,Location ヘッダのフィールド値に使用する場合や,掲示板等において入力された名前等を Set-Cookie ヘッダのフィールド値に使用する場合等が挙げられます。このようなウェブアプリケーションで,HTTP レスポンスヘッダの出力処理に問題がある場合,攻撃者は,レスポンス内容に任意のヘッダフィールドを追加したり,任意のボディを作成したり,複数のレスポンスを作り出すような攻撃を仕掛ける場合があります。このような問題を「HTTP ヘッダ・インジェクションの脆弱性」と呼び,この問題を悪用した攻撃手法は「HTTP ヘッダ・インジェクション攻撃」と呼びます。
http://www.ipa.go.jp/security/vuln/websecurity.htmlより引用)

ここにあるに「掲示板等において入力された名前等を Set-Cookie ヘッダのフィールド値に使用する場合」に関して、過去問(H27春SC午後Ⅰ問1)では具体的な例が掲載されている。

具体的に書く
入力欄の文字列に以下を入れる

%0d%0a%0d%0a%3chtml%3e%3cbody%3e%3cscript%3ealert%28%221%22%29%3c%2fscript%3e%3c%2fbody%3e%3c%2fhtml%3e

これをデコードすると以下になる
「改行コード」「改行コード」<html><body><script>alert("1")</script></body></html>

すると、Webサーバに対するHTTPリクエストは以下のようになる
GET /search?kensaku=jewelry「改行コード」「改行コード」<html><body><script>alert("1")/script></body></html>
HTTP/1.1
Accept: text/html, application/xhtml+xml, */*
Accept-Language: ja-JP
Accept-Encoding: gzip, deflate
Host: www.example.co.jp
Cookie: SESSIONID=134D96E470da240421svr5B019

これに対し、WebサーバからクライアントへのHTTPレスポンスは以下になる。
HTTP/1.1 200 OK
Date: Tue, 10 Jun 2014 05:45:58 GMT
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache
Set-Cookie:kensaku=jewelry

<html><body><script>alert("1")</script></body></html> ←このようにスクリプトが実行できる
すると改行コードにより、レスポンスヘッダではなくレスポンスボディとブラウザは認識する。ヘッダにはスクリプトが書かれても実行はされないが、レスポンスボディに配置されれば、ブラウザにてスクリプトが実行される。
こうやって、攻撃者は任意の攻撃コードをクライアント側で実行することができる。

HTTPヘッダインジェクションの対策
対策に関しても、同じ過去問(H27春SC午後Ⅰ問1)で述べられている。
U主任:仮に問題があるとした場合,Set-Cookieヘッダの値をセットするサーバ側の処理において,どのような対策が考えられますか。
T君:幾つかの対策があります。例えば,HTTPレスポンスヘッダを適切に出力するために,Webアプリの実行環境やプログラム言語が用意している,ヘッダ出力用の関数やAPIを使用する方法が考えられます。それが使用できない場合は,[ c ]するといった処理を開発者が自身で実装する方法も考えられます。

空欄cは穴埋め問題であり、解答例は以下である。
・出力文字列に改行コードがあるとエラー画面を出力
・出力文字列の改行コード以降の文字列を削除

このページのトップヘ