とある診断員とSQLインジェクション
•
176 likes•79,149 views
5/23に開催したssmjpでLTした資料です。一部内容の追記をしています。
Report
Share
とある診断員とSQLインジェクション
- 1. SQLインジェクション
- 2. 自己紹介 セキュリティエンジニアやってます。 脆弱性診断業務を担当しており、専門はWebセキュリティです。 趣味で脆弱性の検証したり、最近はCTFイベントなどに参加して たりします。 TwitterID: tigerszk
- 3. 本題に入るその前に
- 7. 通常のWebサーバとの通信 <html> <body> <form action=“register” method=“POST”> 氏名:vultest<BR> メールアドレス:vultest@example.jp<BR> 性別:男<BR> （以下略） </html> POST /confirm.php HTTP/1.1 Host: example.jp （以下略） Cookie: PHPSESSID=xxxxxxxxxx name=vultest&mail=vultest%40example.jp&gender=1 HTTP Response HTTP Request
- 8. 色々いじってみてどういう応答があるか確認 POST /confirm.php HTTP/1.1 Host: example.jp （以下略） Cookie: PHPSESSID=xxxxxxxxxx name=vultest&mail=vultest%40example.jp”>xss&gender=1 <html> <body> <form action=“register” method=“POST”> 氏名:vultest<BR> メールアドレス:vultest@example.jp”>xss<BR> 性別:男<BR> （以下略） </html> HTTP Response HTTP Request じゃあパラメータ値で こんなの送ったらどう なるの？ おお！出力時に「”」,「>」が エスケープされてないね。 XSSあるんじゃね？
- 11. 必須アイテム 手動での診断作業や通信解析時にはローカル Proxyを非常に良く利用します。 HTTP Response HTTP Request HTTP Response HTTP Request ローカルProxy ブラウザからの通信をローカルProxyを経由させることで下記が可能 です。診断だけじゃなく問題の切り分けとかにも非常に便利です。 通信内容の詳細を確認可能 通信内容を編集して送信することも可能
- 12. お勧めのローカルProxyツール Burp Suite http://portswigger.net/burp/ OWASP ZAP https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project Fiddler http://www.telerik.com/fiddler ※ちなみにこれらのツールはMan In the Middle（中間者攻撃）的な方法で HTTPSの通信にも対応しています。
- 13. 診断する時の注意点 セキュリティ診断を円滑に実施するためには担当者に対して以下の ような注意事項の説明など、事前調整を入念に行う必要があります。 （※これ超重要） 調整事項の例 診断による影響についてちゃんと担当者に事前に説明する。 Webアプリケーション診断は検査対象のWebサーバに通信を行い実際にアプリケーションを動作させて 行います。そのため以下のような事象が発生する可能性があります。 • DBへの大量のダミーデータの書き込み • 大量のメール送信 • アプリケーションの作りによっては、本来意図しない動作の発生 …etc 上記のようなことが、発生する可能性があるため、担当者の方には事前にテスト環境での診断 実施＆診断前のデータバックアップなどをお願いしています。 ホスティング環境やクラウド環境を利用している場合には、あらかじめインフラ提供者側に対して 診断実施をしてよいかの確認をしてもらう。（絶対勝手にやらない） IDSやIPSなどで監視している場合には、診断時の通信を非監視にしてもらうようにお願いする。
- 15. こんな条件の診断だった 昔々、ある所にまだ駆け出しのとある診断員がいました。 その診断員はある時以下のような条件のWebサイトを診断しました。 診断対象は本番環境だった。 ※もちろんとある診断員は事前に注意点を入念に説明し、テストサイトで の実施を勧めたが、「そんなもんねえから本番でやって」と一蹴された。 パッケージ利用とかではなく、自作のECサイトだった。 いわゆるLAMP環境で開発されたアプリだった。 （CENTOS,Apache,PHP,Mysql） かなり前に作られていたこともあり、どうやらあまり（というか全然）セキュリティ を考慮して作られていないサイトのようでした。 診断途中の段階で既にかなり多数の脆弱性が見つかっており、かわいそうな 診断員はヒイヒイ言いながら診断をしていました。
- 18. ＼(^o^)／
- 19. そりゃ当然こんな感じになるよね
- 21. 最終的には
- 25. SQLインジェクションって？
- 26. 例えばこんなWebアプリあったとします 会員制ECサイトの商品検索ページ的なもの 値段や名前を条件として検索が可能 条件にマッチした商品名を画面に表示するだけの機能
- 27. 通常のアプリの処理の流れ Webサイト側の内部処理 パラメータ値などが含まれた問い合わせを Ｗｅｂサイトに要求する 価格が100円の商品を検索 http://exmple.jp?cost = 100 Webアプリケーション データベース 受信したパラメータ値からＳＱＬ文(データベースへの命令 文)が組み立てられデータベースに命令を送信 SELECT name FROM goods WHERE cost = 100 ; データベース内でSQL文が実行された結果 が返る SQL文の実行結果を元にアプリケーション側で生成されたHTTPレスポン スの内容がサーバからの応答として返る 「価格が100円の商品は下記です。缶コーヒー、ガム、アメ」と表示する HTML <html><body>….. サイト利用者 ＨＴＴＰ通信 HTTP Request HTTP Response SQL命令 ① ② ③ 下記は検索ボタンを押してから検索結果がブラウザに表示される までの処理の流れのイメージです。 ④ name 缶コーヒー ガム アメ
- 28. ＳＱＬインジェクション攻撃 Webサイト側の内部処理 ユーザ情報を削除するようなSQL文を構成するような文字列を パラメータ値に入力して送信���る http://exmple.jp?cost=100; DELETE FROM users 脆弱な Webアプリケーション データベース 受信した値からパラメータ値からＳＱＬ文が組み立てられデータ ベースに命令を送信される。 この時、パラメータ値として入力した文字列の一部がそのまま SQL文として解釈され実行される。 これにより本来意図しない命令がデータベースで実行されてし まう。 SELECT name FROM goods WHERE cost = 100 ; DELETE FROM users ; 攻撃者 ＨＴＴＰ通信 HTTP Request HTTP Response 発生しうる脅威 データベースに蓄積された非公開情報閲覧、改ざん、消去 認証回避による不正ログイン ストアドプロシージャ等を利用したOSコマンドの実行 ユーザ情報 を削除 SQL命令 脆弱な作りのWebアプリケーションの場合、SQL文の断片を含んだ不正なHTTPリクエストを 送信されることによって、外部からデータベースを操作されてしまう。
- 29. どうやって直せばよいの？ Webアプリケーション開発時に脆弱性を作りこまないよう なコーディングをする必要があります。 SQLインジェクションの根本的対策 1. SQL文の実行方式にPrepared Statement(準備済みの命令文)を利用する。 2. SQL文の特殊記号となりうる入力値が存在しないか確認し、存在した場合 はエラーとするか適切なエスケープ処理を施す。（特殊文字はDBMSごとに異 なるのでそれぞれの環境に合わせた対策が必要。） ※詳細については徳丸本や「安全なSQLの呼び出し方」を参照するのが良いと思 います。
- 30. SQLインジェクションの見つけ方の例-その1- SQL文の断片を送信して、レスポンスにSQLエラー（DBMS等が 出力するエラーメッセージ）が出力されるか確かめたりする。 SELECT * FROM member WHERE name = 'tanaka'; 通常時 送信値：tanaka 構成されるSQL文 検索結果：1件 田中 SELECT * FROM member WHERE name ='''; 検査時 送信値：' 構成されるSQL文 SQL error
- 31. SQLインジェクションの見つけ方の例-その2- 送信した値ごとの応答結果の差分を見て判定したりもする。 SELECT * FROM member WHERE name = 'tanaka' AND 'a' = 'a'; 条件式が真 送信値：tanaka' AND 'a' = 'a 構成されるSQL文 検索結果：1件 田中 SELECT * FROM member WHERE name = 'tanaka' AND 'a' = 'b'; 条件式が偽 送信値：tanaka' AND 'a' = 'b 構成されるSQL文 検索結果：0件 なし SELECT * FROM member WHERE name = 'tanaka' BND 'a' = 'a'; 文法として逸脱しているもの 送信値：tanaka' BND 'a' = 'b 構成されるSQL文 エラー
- 33. 例えばor条件だと UPDATE member SET password = 'xxxx' WHERE id = 1; 本来の意図する処理 受け渡す値：1 UPDATE member SET password = 'xxxx' WHERE id = 1 OR 1 = 1; カラム名「id」が1の値となっているレコードのみ、カラム名 「password」の値をxxxxに更新する or条件のSQL文の断片を渡した場合 受け渡す値：1 OR 1 = 1 全てのレコードのカラム名「password」の値をxxxxに更新するこ とになってしまう！
- 34. 複文もヤバい場合がある UPDATE member SET password = 'xxxx' WHERE flag = 1 AND id = 1; 本来の意図する処理 受け渡す値：1 カラム名「flag」が1の値かつカラム名「id」が1の値となっているレ コードのみ、カラム名「password」の値をxxxxに更新する 複文となるSQL文の断片を渡した場合 受け渡す値： 1; SELECT 1;-- カラム名「flag」が1の値となっている全てのレコードのカラム名 「password」の値をxxxxに更新することになってしまう！ UPDATE member SET password = 'xxxx' WHERE flag = 1; SELECT 1;-- AND id = 1;
- 36. では何故こんなことが起きた？
- 39. ちなみにこの文字列の本来の用途 SQLインジェクションのシグネチャの一つで、SQL文における文字 列連結演算子を送信して応答結果から脆弱性があるかどうかを 判断するためのもの。ツールには「 '+' 」や「 '||' 」などの文字列を 送信するシグネチャが存在した。 ちなみに文字列連結演算子はDBMSごとに異なります。 || Oracle, DB2, Postgre等 + SQL Server, Sybase等 スペース、CONCAT() MySQL SELECT * FROM member WHERE name = 'tan'+'aka'; SQLインジェクションが存在する場合 送信値： tan'+'aka 構成されるSQL文 検索結果：1件 田中 挿入した文字列連結演算子がSQL文にて評価されている場合に脆弱性として検出
- 40. この事件の真相(推測)
- 43. 理由はMySQLの「暗黙の型変換」 MySQLの文字列連結演算子はスペースやCONCAT()関数です。MySQLでは「+」記号は、 数値の和算として解釈されます。 MySQLは数値が要求される文脈に文字列があった場合は数値（浮動小数点数）に暗黙 の型変換されます。数値として正しくない文字列の場合は 0 になるそうです。 そのため下記のように判定されたと判断しています。 この結果WHERE句についてはid = 0となりますが、idカラムは文字列なので、また暗黙の 型変換が行われてから比較されます。その結果、idカラムの値が数値に変換できない文 字列の場合は0に変換されるため条件が真となり、全件のレコードが該当してしまうと思 われます。 ※以下の徳丸さんのブログに「暗黙の型変換」についてのわかりやすい解説があり参考 にさせていただきました。 「SQLインジェクションゴルフ - なんと3文字で認証回避が可能に」 http://blog.tokumaru.org/2013/06/sql-injection-golf-3-letters-bypass-login-authentication.html 「SQLの暗黙の型変換はワナがいっぱい」 http://www.tokumaru.org/d/20090924.html 'aaa@vultest.com'+'' ⇒ 0 + 0 ⇒ 0
- 44. アプリ側で生成されるSQL文について リマインダ機能で生成されるSQL文について下記のような推測をしました。 1. 入力値（メールアドレスと誕生日）の照合とパスワードの更新はそれぞれ別のSQL文だった のではないか。 2. SELECT文でなんらかの結果が返ってきた場合に、UPDATE文を実行するような感じだった のではないか。 3. UPDATE文のWHEHE句はSELECT文の実行結果を利用したわけではなく、リマインダで入力 したメールアドレスのパラメータ値が使われたのではないか。 SELECT * FROM member WHERE id = 'test@vultest.com' AND birthday = 1999523; UPDATE vultest SET password = 'リセットするパスワード値' WHERE id = 'test@vultest.com'; 実行されるのはこんなＳＱＬ文だったのではないだろうか？ 例えばリマインダ機能で下記のような値を入力した場合 メールドレス：test@vultest.com 誕生日：1999年5月23日 メールアドレスと誕生日の値が一致するユーザがいるか検索 該当するメールアドレスのユーザのパスワードを初期化
- 45. そうであればこうなる SELECT * FROM member WHERE id = 'test@vultest.com'+'' AND birthday = 1999523; UPDATE member SET password = 'リセットするパスワード値' WHERE id = 'test@vultest.com'+''; 下記値をリマインダ機能で入力した場合 メールドレス：test@vultest.com'+' 誕生日：1999年5月23日 カラム名「birthday」の値 が1999523に該当するユーザのレコードが検索結果として返る 結果、全ユーザのパスワードが初期化される メールアドレスと誕生日の値が一致するユーザがいるか検索 該当するメールアドレスのユーザのパスワードを初期化 ※試しに同様の動きをするWebアプリを作ってみましたが、見事に再現されましたｗ
- 46. ちなみにこっちも注意 MySQLの場合には「'+'」だけではなく「'||'」も気をつけなくてはなら ない。 MySQLでは「||」は論理和として解釈されてしまい、なおかつ同様 に暗黙の型変換が行われるためこちらもMySQLを対象とした診 断では危険なので使わないほうが良い。 ※ 実はこの二つのシグネチャの危険性については下記のブログで随分前に指摘されていたの にとある診断員はこの件が起こった後に気づきました。。。（読んでたのにorz...）SQLイン ジェクションの検出方法についてすごく詳細な記載があるので興味がある方は必見です！ T.Teradaの日記 自作検査ツール - SQLインジェクション編 http://d.hatena.ne.jp/teracc/20090531 また、またまたabentさんの「Webアプリって奥が深いんです。」でMySQL での「||」の危険性に ついて詳しく検証されていますので詳しくはそちらを参照ください。 「Webアプリって奥が深いんです。」 http://www.slideshare.net/abend_cve_9999_0001/web-22186183
Editor's Notes
- 7
- 8
- ENT