\[:contents]
1.SQLインジェクション ①SQLインジェクションとは
過去問では、SQLインジェクションに関して、以下のように述べられている。
| 「Webアプリケーションに悪意ある入力データを与えてデータベースの問合せや操作を行う命令文を組み立てて、データを改ざんしたり不正に情報取得したりする攻撃」（H22AP秋 午前問43）より |
SQLインジェクションは、SQL文を操作する文字列をWebフォームなどに注入（Injection）し、データベースに不正にアクセスする攻撃。
例えば、以下のようなフォームがある。
 |
サーバの認証プログラムとして、以下のSQL文が入っているとします。
SELECT user_id,passwd FROM users WHERE user_id='$user_id' AND passwd='$passwd';
ここで、フォームに 1' or '1' = '1'; -- と入力すると
SELECT user_id,passwd FROM users WHERE user_id='1' or '1' = '1'; -- ' AND passwd='$passwd';
となります。コメントを意味する「--」を付ければ、それ以降が無視されます。結果、どんなユーザを入れても成立してしまいます。
コマンドを成功させるだけでなく、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
実際にやってみた様子は以下
http://sm.seeeko.com/archives/21554355.html
■参考（試験には全く関係がありません）：SQLインジェクションのCheat Seat
SQL構文のCheat Seat（カンペ）があります。SQLの構文がまとまっているので、開発や運用においても便利な情報です。
http://pentestmonkey.net/cheat-sheet/sql-injection/oracle-sql-injection-cheat-sheet
ただ、これらは攻撃者にとっても有用な情報で、SQLインジェクションをするときに、DBごとの構文を覚えるのは大変なので、攻撃者はこれらの情報を使って攻撃を仕掛けます。
2.SQLインジェクション ②対策の全体像
SQLインジェクションの対策は、IPAの以下の資料にまとめられています。
http://www.ipa.go.jp/files/000024396.pdf
その情報を参考にすると、主な対策は以下です。
（1）根本的解決
①バインド機構の利用
②プログラムでのエスケープ処理
入力フォームによる入口でのチェックも有用
（2）保険的対策
エラーメッセージは、攻撃者に情報を与えてしまう。
また、ブラインドSQLインジェクション（Blind SQL injection）という手法があり、入力値と応答結果から、脆弱性を把握する。たとえば、ID/Passを入力したときに、「IDが存在しません」「パスワードが間違っています」と丁寧にエラーを返せば、攻撃者にもIDが違うのかPassが違うのかの情報を与えてしまう。
〔2〕データベースアカウント
権限の見直し。必要最小限の権限しか与えておかなければ、被害も少なくなる。
| H21SC春午前Ⅱ問14 SQLインジェクション対策について、Webアプリケーションの実装における対策とWebアプリケーションの実装以外の対策の組合せとして、適切なものはどれか。
|
↓
↓
↓
↓
↓
今回の内容はとても難しい内容ですが、SQLインジェクションというキーワードから、「データベース」に関する対策を選ぶと、ウのみになります。
3.SQLインジェクション ③対策：静的プレースホルダ（バインド機構）
これを使えば、エスケープ処理は不要だ。
http://www.ipa.go.jp/files/000024396.pdf
静的プレースホルダは情報処理技術者試験で問われるキーワードです。バインド機構や、プリペアドステートメントという言葉を使う場合もあります。Prepared Statementなので「用意された構文」です。用意された構文が変化することなく、入力された文字は文字列として理解されるので不正な文字を入れるという攻撃を防げます。
過去問（H18秋SU午後Ⅱ問1）では、「バインド機構を利用する」ことの解説として、「プレースホルダと呼ばれる一時的な特殊文字を使用してSQL文のひな形を用意しておき,後で実際の値(変数)を割り当ててSQL文を完成させる方法です。変数は自動的にエスケープ処理されるので,DBMSの種類によって異なるエスケープ処理を意識する必要がなくなります」とあります。
具体例をみましょう。以下は、上記サイトの引用であるが、入力されたデータは「？」で表わされます。そして、入力されたデータが文字として直接実行されるのだ。
| $sth = $dbh->prepare( "SELECT id, name, tel, address, mail FROM usr WHERE uid=? AND passwd=?"); $sth->execute($uid, $passwd); |
わかったような…
これまでは、上記のuidのところに、以下のように入力されると、構文が変わってしまう。
1' or 'a'='a' --
しかし、？で処理し、値だけを判断するので、 「1' or 'a'='a' --」という文字列で処理される。
4.SQLインジェクション ④対策：サニタイジング（エスケープ）処理
（1）サニタイジング（エスケープ）処理とは
SQL インジェクション対策はサニタイジング（エスケープ）処理が一般的です。
過去問では、SQLインジェクション攻撃を防ぐ方法として、「入力値から，データベースへの問合せや操作において特別な意味をもつ文字を解釈されないように保護する。（H20SU 午前問題 問26より）」と述べられている。
また、過去問（H18秋SU午後Ⅱ問1）では、「SQLインジェクション対策のためのエスケープ処理とは,利用者から入力される値が、SQL文にとって特別な意味をもつ記号文字の場合に,例えば,"'"であれば"''"のように"'"を二つ続けた文字列に置換する処理のことです。」とあります。
Webフォームなどに、<script> のようなスクリプトが埋め込まれた場合、HTMLではスクリプトと判断してスクリプトが実行されます。単純な例を挙げます。以下の記載をしたとします。
<script>alert("こんにちは");</script>
すると、画面に以下のようなポップアップ画面（アラート）が表示されます。あなたが掲示板の管理者だとして、このような書き込みをされたとすると、その掲示板を開くたびにこのアラートが出てしまいます。困りますよね。
掲示板でのポップアップレベルならいいですが、個人情報を抜かれたり、サーバを乗っ取るようなコマンドを仕掛けられることもあります。これは防がなければいけません。
（2）サニタイジング（エスケープ）処理の方法１
対策（エスケープ処理）として、<script>などの文字を、Webサーバ上ではプログラム用の言葉ではなく、単なる文字として認識させます。具体的には「<」を「<」としてエスケープ処理をします。すると、Webサーバ側では、<script> となりますので、これはプログラム用の言葉ではないと判断されるのです。
<script> 書いたとしても、
ブラウザ上では <script> と表示されるのですね。
はいそうです。ブラウザがきちんと自動で認識をしてくれます。掲示板などに<script>と書き込んで試してみるといいでしょう。
エスケープ処理（サニタイジング処理）における、文字の変換例は以下です。
表2 文字の置換
| 元の文字 | 置換後の文字列 |
| ＆ | & |
| < | < |
| > | > |
| ‘ | ' |
| “ | " |
（H18年SV午後Ⅰ問1表2より引用）
これを丸暗記しようとすると難しいが、意味を理解すると覚えやすい。例えば「&」であれば、本来の名称であるampersand、「<」であれば、less than(～より小さい）のltである。
セキュアプログラミングに関しては、IPAのサイトに充実した解説がされている。http://www.ipa.go.jp/security/awareness/vendor/programming/index.html
（3）サニタイジング（エスケープ）処理の方法２
別の例を見ましょう。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の構文として不適切であり、この部分は「文字列」として扱われる。
なおかつ、データベース側では、''は'という文字列として自動認識してくれるので、入力した通りの文字として正常に処理される。
サニタイジングとエスケープ処理との違いはなんですか？
同じですか？
まあ、一緒と思ってもいいだろう。
サニタイジング（無害化）の方法の一つが文字の変換などによるエスケープ処理。サニタイジングの方法は、エスケープ処理以外に、特殊文字は入力させない、処理を強制終了させるなどがある。
又は、もっと単純に、’などの特殊文字をそもそも受け付けず、入力フォームにてエラーを出すことも方法の一つ。
◆参考：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 ←これをつけるだけ
ただ、万能ではないし、実装されていることも少ない（気がする）。
5.OSコマンドインジェクション
（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コマンドを渡します。そうして、不正にコマンドやファイルを実行します。
（3）OSコマンドインジェクションの過去問
H30春SC午前Ⅱ問2
| 問2 Webサーバのログを分析したところ，Webサーバヘの攻撃と思われるHTTPリクエストヘッダが記録されていた。次のHTTPリクエストヘッダから推測できる，攻撃者が悪用しようとしている脆弱性はどれか。ここで，HTTPリクエストヘッダはデコード済みである。 〔HTTPリクエストヘッダの部分〕 GET /cgi-bin/submit.cgi?user=;cat /etc/passwd HTTP/1.1 Accept:＊/＊ Accept-Language: ja UA-CPU: ｘ86 Accept-Encoding: gzip, deflate User-Agent:（省略） Host: test, example.com Connect ion: Keep-Alive ア HTTPヘッダインジェクション イ OSコマンドインジェクション ウ SQL インジェクション エ クロスサイトスクリプティング |
↓
↓
↓
↓
↓
注目すべきは、「;cat /etc/passwd HTTP/1.1」の部分です。catは、指定されたファイルの内容を表示するコマンドです。これにより、サーバのパスワードを取得しようとしています。OSのコマンドを不正に入力しているので、OSコマンドインジェクションが正解です。
正解：イ
補足します。OSコマンドインジェクションは、一例として、OSのコマンドを入力できる関数（例、system）などを利用している場合に危険が高くなります。
以下も参照
http://sm.seeeko.com/archives/15877027.html
問題文の以下の構文を見てみましょう。
GET /cgi-bin/submit.cgi?user=;cat /etc/passwd HTTP/1.1
このとき、?の後ろが、ユーザから入力される引数で、それが、OSコマンドが実行されるsystem関数やopen関数に引き渡されているとします。
たとえばuserにyamadaと入れた場合に、yamadaのディレクトリにあるファイル一覧が見れるようなコマンドが渡されるとします。
system("ls $user")
user=yamadaなら
実行されるコマンドは "ls yamada" になります。
そして、user=yamada;cat /etc/passwdなら
実行されるコマンドは "ls yamada;cat/etc/passwd"となり、passwdファイルの中身が表示されてしまいます。
6.ディレクトリトラバーサル
（1）ディレクトリトラバーサルとは
トラバーサル（traversal)とは「横断」という意味である。
横断歩道は、本来は車のために縦方向にある流れを歩行者のために横に断ち切る。ディレクトリトラバーサルも同様で、横断的にファイルにアクセスする。
具体例で見てみましょう。以下のディレクトリ構造を見てください。
例えば、htmlディレクトリは公開していいファイル、secretディレクトリは非公開のファイルが格納されているとします。
また、現在のディレクトリが上記のhtmlだったとします。
ここで、相対パスとして「../../secret/secret.txt」を指定します。「../」は、上位のディレクトリを意味する文字列です。
こうすると、非公開のファイルであるsecret.txtファイルにアクセスすることができるのです（ただし、アクセス権が許可されている場合）。
過去問（H27秋AP）では、「入力文字列からアクセスするファイル名を組み立てるアプリケーションに対して，攻撃者が，上位のディレクトリを意味する文字列を入力して，非公開のファイルにアクセスする。」とあります。
「入力文字列からアクセスするファイル名を組み立てるアプリケーションに対して」ってどういう意味ですか？
IPAの以下の資料の「ディレクトリトラバーサル攻撃 」の部分が参考になります。https://www.ipa.go.jp/security/awareness/vendor/programmingv1/b07_07.html
以下のサイトがかなり重要。他にもたくさん大切なページがある
http://www.ipa.go.jp/security/vuln/vuln_contents/dt.html
では、過去問を見てみよう。
| 問45 ディレクトリトラバーサル攻撃に該当するものはどれか。 ア Webアプリケーションの入力データとしてデータベースへの命令文を構成するデータを入力し,想定外のSQL文を実行させる。 イ Webサイトに利用者を誘導した上で, Webサイトの入力データ処理の欠陥を悪用し,利用者のブラウザで悪意のあるスクリプトを実行させる。 ウ 管理者が意図していないパスでサーバ内のファイルを指定することによって,本来は許されないファイルを不正に閲覧する。 エ セッションIDによってセッションが管理されるとき,ログイン中の利用者のセッションIDを不正に取得し,その利用者になりすましてサーバにアクセスする。 （H24FE春 午前問45）」 |
↓
↓
↓
↓
↓
正解はウである。
もう一問。これの正解は「ディレクトリトラバーサル」であるが、以下を見ると、どのように不正な操作をするのかが分かると思う。
［ ］に入れる適切な字句を15字以内で答えよ
パケットに含まれる文字列からすると、CGIプログラムに含まれる［ ］の脆弱性を利用して、パスワードファイルを取得することをねらったもののようです。（H22SC春午後Ⅱ問2設問3(1)より） |
有名な事件として、2003年に、某協会のホームページから個人情報1184人分が流出した。
http://www.itmedia.co.jp/enterprise/0401/23/epn14.html
原因は、サイト側の脆弱性ではあったが、そこをついて情報を公開した大学の研究者は、不正アクセス禁止法で逮捕されることになった様子。
（2）絶対パスと相対パス
過去問（H25年秋FE午後問11）では、絶対パスと相対パスに関して、以下の記載があります。
「パスは，木構造をもつファイルシステムにおいてディレクトリを特定するために利用される文字列であり，ディレクトリの名前を“/”で区切って並べて表す。“/”で始まるパスを絶対パスという。絶対パスはルートディレクトリを起点として表したパスである。“/”で始まらないパスを相対パスという。相対パスは任意のノードを起点として表したパスである。」
相対パスは、現在の場所を起点としてファイルの場所を示す書き方です。
たとえば、status.cgiの場所を示す絶対パスが以下とします。
http://192.168.0.1/images/status.cgi
現在、imagesフォルダにいる場合、status.cgiの相対パスは以下です。
./status.cgi
7.HTTPヘッダインジェクション
(1)HTTPヘッダインジェクションとは
インジェクションは「注入」という意味ですから、HTTPのヘッダに悪意のコードを注入（インジェクション）するのですね。
そう考えてよい。
情報処理振興機構（IPA）の「安全なウェブサイトの作り方 改訂第７版」には、HTTPヘッダ・インジェクションについて次のように説明されている。
| ウェブアプリケーションの中には，リクエストに対して出力する HTTP レスポンスヘッダのフィールド値を，外部から渡されるパラメータの値等を利用して動的に生成するものがあります。たとえば，HTTPリダイレクションの実装として，パラメータから取得したジャンプ先の URL 情報を，Location ヘッダのフィールド値に使用する場合や，掲示板等において入力された名前等を Set-Cookie ヘッダのフィールド値に使用する場合等が挙げられます。このようなウェブアプリケーションで，HTTP レスポンスヘッダの出力処理に問題がある場合，攻撃者は，レスポンス内容に任意のヘッダフィールドを追加したり，任意のボディを作成したり，複数のレスポンスを作り出すような攻撃を仕掛ける場合があります。このような問題を「HTTP ヘッダ・インジェクションの脆弱性」と呼び，この問題を悪用した攻撃手法は「HTTP ヘッダ・インジェクション攻撃」と呼びます。 （http://www.ipa.go.jp/security/vuln/websecurity.htmlより引用） |
ここにあるに「掲示板等において入力された名前等を Set-Cookie ヘッダのフィールド値に使用する場合」に関して、過去問（H27春SC午後Ⅰ問１）では具体的な例が掲載されている。
具体的に書くと、入力欄の文字列に以下を入れる
%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> ←このようにスクリプトが実行できる |
すると改行コードにより、レスポンスヘッダではなくレスポンスボディとブラウザは認識する。ヘッダにはスクリプトが書かれても実行はされないが、レスポンスボディに配置されれば、ブラウザにてスクリプトが実行される。
こうやって、攻撃者は任意の攻撃コードをクライアント側で実行することができる。
(2)HTTPヘッダインジェクションの攻撃事例
HTTPヘッダインジェクションを使って不正なURLを作ることができる。脆弱性があるサイトを利用するので、たとえばそのサイトが大手サイトであれば、ドメインは大手になる。利用者は、URLの後半を確認することはまずない。
そして、そのURLを掲示板であったり、メールで送信してクリックさせる。そうすれば、フィッシングサイトに誘導することや、攻撃者がSet Cookieも改ざんしてセッションIDを指定し、セッション固定攻撃にも悪用できる。
具体的なサンプルプログラムについては、以下に記載がある。
❶Capm Network
http://capm-network.com/?tag=HTTP%E3%83%98%E3%83%83%E3%83%80%E3%82%A4%E3%83%B3%E3%82%B8%E3%82%A7%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%B3
❷徳丸氏の記事
https://xtech.nikkei.com/it/article/COLUMN/20070422/269134/
(3)HTTPヘッダインジェクションの対策
対策に関しても、同じ情報処理安全確保支援士試験の過去問（H27春SC午後Ⅰ問1）で述べられている。
| U主任：仮に問題があるとした場合，Set-Cookieヘッダの値をセットするサーバ側の処理において，どのような対策が考えられますか。 T君：幾つかの対策があります。例えば，HTTPレスポンスヘッダを適切に出力するために，Webアプリの実行環境やプログラム言語が用意している，ヘッダ出力用の関数やAPIを使用する方法が考えられます。それが使用できない場合は，[ c ]するといった処理を開発者が自身で実装する方法も考えられます。 |
↓
↓
↓
↓
↓
空欄cは穴埋め問題であり、解答例は以下である。
・出力文字列に改行コードがあるとエラー画面を出力
・出力文字列の改行コード以降の文字列を削除
8.メールヘッダインジェクション攻撃
(1)攻撃概要
具体的な攻撃事例を紹介します。たとえば、店舗が以下の問い合わせフォームを用意していたとします。利用者が名前やメールアドレス、タイトルなどを入れると、右のメールが店舗に自動送信されます。
ではここで、問い合わせフォームのタイトルに、改行コードである%0D%0Aを加え、「お買い得%0D%0ABcc:<user1@example.com」と入力したとします。
すると、メールヘッダは以下のようになり、Bccに指定した宛先にメールを送信することが可能です。
| MIME-Version: 1.0 Message-ID: <xxx@mail.gmail.com> Subject: お買い得 Bcc:<user1@ example.com> From: <malware@gmail.dom> To: <support@shop.dom> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 名前：お買い得ショップ 問い合わせ：以下、お買い得情報をお知らせします。是非リンクをクリックしてね ・・・・・ |
攻撃者は、BCCにSPAMメール送りたい宛先を入れ、このようなフォームを踏み台にしてSPAMメールを送信できます。
(2)対策
情報処理安全確保支援士の過去問（R3春午後１問１）をもとに整理します。
参考までに、表１の「メールヘッダインジェクション」に関するその他の対策を解説します。
①メールヘッダを固定値にする
メールヘッダを固定値にすれば、メールヘッダインジェクションにより、不正なコードを入力することができません。
②外部からの入力を適切に処理する
メール送信用APIを使用するインジェクションを引き起こすような文字がないかをチェックする安全なAPI（＝プログラム、と考えましょう！）を用意し，そのAPIを用いてメール送信処理を行います。
③外部からの入力の全てについて、改行コードを削除する
改行コードを削除することで、攻撃者のよる不正な処理を防ぎます。具体的な攻撃例は先に述べたようなBccを自由に設定するような攻撃です。
