「脆弱性があったとき、その責任は発注者？開発者－判決では開発者」という話を聞いてきた！

１０月３日に、PHPカンファレンス2015に行ってきた！話の続き

今どきのSQLインジェクションの話題総まとめ
（リンク先は、発表資料のスライドシェア）

をメモメモ

ちなみに、表題の件は「判決について」のこと

---

・内容
　判決
　入門書の問題
　O/Rマッパー、SQLジェネレーターのSQLインジェクションの問題

・判決について
　２００９年からPHPカンファレンスで話をしている
　そのとき話した内容
　　「静寂製の責任者は、発注者か開発者か」
　→米国：発注者
　　日本：判決が出た

　家具インテリアECサイト侵入事件
　　８８９万円で受注
　　セキュリティの指示はしていない
　　SQLインジェクション、クロスサイトスクリプティング
　　個人情報をログから閲覧できる

　判決結果
　　SQLインジェクションと判断
　　債務不履行
　　契約を認めるが、重過失
　　２２６２万円の損害賠償
　→開発会社に責任有
　　「お客様が言わないからしない」は危ない
　　安全なWebサイトのつくり方が変わった

・イマドキのPHP入門書のSQLインジェクション
　後回しでいいが、何時セキュリティを学ぶの？
　→SQLインジェクションはただのバグ

　「はじめてのPHPプログラミング」（２００８年）
　・バインドに？があると、誤動作
　→プレースホルダーを安易に自作すると、徳丸先生に怒られる

　「よく分かるPHPの教科書」
　・DELETE文で
　　エラーメッセージを使った個人情報漏洩
　　１ビットづつとってくる（２５シート目）

　「気づけばプロ並みPHP」
　・PDOを呼び出している

　PDO,プレースホルダーを使っている
　→SQLインジェクションに脆弱性がないのが当たり前
　クロスサイトスクリプティング
　　htmlspecialchars
　静的プレースホルダーのほうがあんぜん
　接続時に文字エンコーディング

・O/RマッパーやSQLジェネレーターとSQLインジェクション
　Rails SQLインジェクション　examples
　　対策はプレースホルダー
　　ZendFrameworkでも同じことが起こる（プレースホルダーを使わずに直接書くと）

　RailsのOrderメソッドには式が書ける
　　→ユーザー名とパスワードを連結させて
　　　integerをキャストさせれば、エラーが起こせる
　ブラインドSQLインジェクション
　　複文にして、unionでつける。列名をasで変える
　　→列名のバリデーションで防げる

　ZendFrameworkのZend_Db
　　式も書ける
　　→　()があれば、式とみなしている
　　→1.12.7で修正された
　　→どうすればよいかは、午後へ
　　ZendFramework2には、この問題がない

　JSON SQLインジェクション
　　JSONでなく、連想配列による攻撃
　　SQL::Maker(perl)の演算子がエスケープされない
　Drupageddon（どぅるーぱげどん）
　　Drupal（CMSの１つ）への攻撃
　　配列は考慮していたが、連想配列を考慮していなかった

・まとめ、Q&A
　パッチの提案
　経産省の注意喚起