1K Views
October 27, 11
スライド概要
徳丸本ができるまで 2011年10月27日 徳丸 浩
言い出しっぺの法則1 WASF2008での発表資料 http://www.hash-c.co.jp/archive/wasf2008.html Copyright © 2011 HASH Consulting Corp. 2
できました(1) 独立行政法人 情報処理推進機構 安全なSQLの呼び出し方 http://www.ipa.go.jp/security/vuln/websecurity.html 3
言い出しっぺの法則2 書評 - ウェブアプリケーションセキュリティ http://www.tokumaru.org/d/20070724.html#p01 Copyright © 2011 HASH Consulting Corp. 4
できました(2) Copyright © 2011 HASH Consulting Corp. 5
年表 • 2010年 – 5月6日 ソフトバンククリエイティブ社より執筆の打診 – 5月10日 ソフトバンククリエイティブ社にて打ち合わせ。執筆の受諾 – 5月28日 執筆の宣言、レビュアーの募集開始 – 6月6日 レビュアー決定、執筆開始 – 12月21日 初稿完成 • 2011年 – 1月15日 第2稿完成 – 3月1日 初版第1刷発行 – 1月23日 第3稿完成、脱稿 – 3月25日 初版第2刷発行 – 2月6日 著者校終了 – 5月11日 初版第3刷発行 – 2月10日 再校終了 – 7月28日 初版第4刷発行 – 2月15日 三校終了、制作終了 – 9月28日 電子版発行 Copyright © 2011 HASH Consulting Corp. 6
きっかけは一通のメール 書籍の執筆をお願いできませんでしょうか [email protected] To hiroshi2009 徳丸様 詳細を表示 10/05/06 はじめまして。 ソフトバンククリエイティブという出版社で書籍の編集を担当しております、友保と申します。 このたびは、徳丸様に「Webアプリケーションのセキュリティ」に関する書籍のご執筆をお願いできないかと思 い、メールを送らせていただきました。 Webアプリケーションのセキュリティについては、過去に『PHPサイバーテロの技法』(2005年12月刊)等よく 売れた書籍もありますが、最近は定番と呼べるような書籍が刊行されていない状況です。 携帯電話、スマートフォンへの対応はじめ、Webの状況も大きく変化しておりますので、よくまとまった信頼で きる情報源としてWebアプリを企画・開発する人にとっての新たな決定版となる書籍を提供したいと考えてお ります。 私自身、徳丸様のブログでセキュリティの知識を学習させていただいており、今回の企画をぜひ徳丸様にお 願いしたいと考えた次第です。 本件につき、お願いする余地がございましたら、具体的な内容についてお話しをしにお伺いしたいと考えてお ります。 お忙しい中に突然のお願いで大変恐縮ですが、ご検討いただけますと幸いです。 どうぞよろしくお願いいたします。 Copyright © 2011 HASH Consulting Corp. 7
レビュアーの募集 Copyright © 2011 HASH Consulting Corp. 8
Copyright © 2011 HASH Consulting Corp. 9
レビュアーの紹介(1) 10
レビュアーの紹介(2) 11
レビュアーの紹介(3) 12
レビュアーの紹介(4) Copyright © 2011 HASH Consulting Corp. 13
レビュアーの紹介(5) 14
豪華すぎるレビュアーという悩み Copyright © 2011 HASH Consulting Corp. 15
16
※あくまで徳丸の脳内での 妄想です こんなValidで ないHTMLは 認められない! 想定が HTML4.01な のかXHTMLな のか明確にし てください 17
18
こんなRESTful でないHTTPは 認められない! ※あくまで徳丸の脳内での妄想です 19
Googleグループを用いたレビューの様子 Copyright © 2011 HASH Consulting Corp. 20
先行書籍の調査 Copyright © 2011 HASH Consulting Corp. 21
Copyright © 2011 HASH Consulting Corp. 22
先行書籍の調査(1) • 日本で一番売れたWebアプ リケーションセキュリティ本 • 簡潔でスピード感のある説 明がすばらしい • PHPと銘打ったから売れた という説もあり • 2005年12月発行ということ もあり、今となっては古さが 目立つ Copyright © 2011 HASH Consulting Corp. 23
「PHPサイバーテロの技法 攻撃と防御の実際」 GIJOE著、ソシム、2005 24
先行書籍の調査(2) • ご存じ「金床本」 • 以下が特に詳しい – XSS – CSRF (ワンタイムトークンの本家) – SQLインジェクション – DNSに対する攻撃 – WAF • 網羅的なWebアプリケーショ ンセキュリティの本ではない Copyright © 2011 HASH Consulting Corp. 25
先行書籍の調査(3) • 佐名木本 • 書名の示すようにTipsが豊 富 • OSコマンドインジェクション、 CrLfインジェクションなど、割 とどうでもよいテーマがやた ら詳しい • 名文句: ぜひ読者諸氏には今一度、 自分の使っているデータベ ース・ソフトウェアのSQLリフ ァレンスを通読することを推 奨する(同書P213)。 Copyright © 2011 HASH Consulting Corp. 26
SQLインジェクションから 書き始めたものの Copyright © 2011 HASH Consulting Corp. 27
第1回原稿のレビュアーへの送付 第一回原稿を送付します レビュアー各位 徳丸です。お世話になります。かなり日数が空いてしまいましたが、第一回目の原稿を 送付致します。中身はSQLインジェクションの項の説明となります。Word形式とPDFの 両方をお送りしますので、都合の良い方でご覧ください。レビュー結果は、テキストな ど、やりやすい方法でお返しください。 レビュー方法についての提案も歓迎致します。 ここから書き始めている理由は、Webアプリケーションセキュリティの入門書として、ど のような内容を書けばよいのか、そこを模索するためです。 結果として、twitter上でのアドバイスなども参考にさせていただき、できるだけ実用的な 内容をあつくしたつもりです。 というものの、攻撃手法がかなり詳しく書いてあったりしますが、これは、読者の知的好 奇心を満足させるための配慮と、攻撃の影響度を実感していただくための配慮です。 28
レビュアーからの指摘の例 徳丸さま、皆さま ○○です。レビューが遅くなり、申し訳ありません。 気になった点を以下に挙げさせていただきました。 細かい指摘については、他の方からも多くあったように思いますので、外しています。 他の方の指摘と被っているところもあると思いますが、参考になりましたら幸いです。 1. 全体的な指摘 (1) レビュー観点 a. 想定読者と目的 レビューの際に、想定読者と目的(読者に何を理解してもらいたいか)が分かっていると、説明 すべき内容やバランス、分かりにくい場所の指摘がしやすいと思います。 私は、今回、以下の想定で読ませていただくことにしました。 想定読者: SQL の基本知識がある開発者 目的1 : SQL インジェクションの危険性を理解してもらう 目的2 : SQL インジェクションを許さないために、プレースホルダを利用して開発してもらう b. 説明の範囲 この章で説明すること、および、説明しないことがまとまっていると指摘するかどうかで考える ことを減らせます。 SQL インジェクションに限らず、脆弱性は、他の脆弱性と関連することが多いように思います。 どこまで説明するかは、他の章にも依存しますので、意図して説明を省略してる箇所があれ ば、先に教えていただけると、不要な箇所まで考慮する必要がなくなるように思います。 29
レビュアーからの指摘の例(続き) 個人的には、目次や見出しだけで、文書の概要が分かる書籍は内容も洗練されているように感じ ます。 以下に、今回の文書の見出しだけ抜き出してみたのですが、これだけでは文書全体の内容が分か りにくいように感じました。 ------------------------------------------------1. 概要 2. 攻撃手法と影響範囲 (1) 画面改ざんだけでなく情報漏えいも コラム(表名・列名の取得方法) (2) UNION攻撃による情報漏えい ~ ~ ~ ~ ~ 略~ ~ ~ ~ ~ できれば、2階層目(節レベル)以降にも適切な見出しを付けることを検討いただけると嬉しいです。 ~ ~ ~ ~ ~ 略~ ~ ~ ~ ~ (4) 表現 a. 「~のような」という表現 多いような気がします。 あまりにも多いと、文書の信頼度が落ちるように感じますので、多くなり過ぎないように注意した 方が良いと思います。 30
「レビュアーのみなさまへ」を追加 レビュアーのみなさまへ ○想定読者 ・PHP等でHTML組み立てによる表示のプログラミ ングができる開発者 ・HTMLとJavaScriptの基本的な知識がある ○この節で説明すること、しないこと 説明すること ・XSSの概要 / 影響 / 原因 ・HTMLエスケープによる対策 ・スキームのチェックによる対策 ・JavaScriptのエスケープによる対策 ・文字エンコーディングのチェック 説明しないこと ・AjaxのXSS(別の章で説明する可能性はある) ○表記上の注、変更点 ・プログラムリストは、原則として、即実行可能な形 で示すことにしました。 ・見出しの記号(体裁は編集で直すので現時点で は気にしないでください) □ レベル1 ○ レベル2 △ レベル3 ・同様に、図表番号は現時点では入れていません ・画面キャプチャは仮のもので、必要に応じて取り 直します ・参照は、Wordの相互参照機能を利用していま す。見栄えは編集時に調整いただく予定です 検討事項(未稿) ・コラム「XSSを巡る誤解」 Copyright © 2011 HASH Consulting Corp. 31
XSSについて ○○です。 大変遅くなってしまいましたが、XSSの章のレビューを送りします。 まず、大変ざっくりとした感想になりますが、スクリプトが実行されるとなぜ脆弱になるの かという説明が欲しいと思いました。 SQLインジェクションの場合は、第三者の書いたSQLが実装者の意思に関わらず勝手に 実行されるという状況はありえないのでそれが異常なことなのは自明ですがが、 JavaScriptはそうではありません。サイト側はユーザーの意思に関わらず勝手にJSを実 行しますし、ユーザーはブックマークレット等でサイト側が把握していないJSを実行した り、ブログパーツで別のサイト上にあるJSを組み込んだりします。自分の意思に関わらず 他人が書いたJSが実行される状況は普通に存在するのにXSSで実行されるのはなぜい けないのか、という疑問に答えられると良いと思います。 そうすると same origin policyの話をしなければならなくなるのでまた話が長くなってし まいますが、XSSの根本的な原因はウェブアプリケーションがsame origin policyを破れ る実装になっているということであり、普通はクッキーを盗んだり出来ないのはsame origin policyのおかげなので、この説明は避けられないし、避けるべきではありません。 XSSの話が長くなるのはJSのセキュリティ全般の話になるからなので、もう覚悟を決めて 長々と書くべきなんじゃないかなと思ったりします。 32
やりましょう! Copyright © 2011 HASH Consulting Corp. 33
Same Origin Policyの説明を決意 第4回原稿(OSコマンド・インジェクション)を送付します レビュアー各位 徳丸です。お世話になります。またまたかなり日数が空いてしまいましたが、第4回目の 原稿を送付致します。中身はOSコマンド・インジェクション脆弱性の説明になります。 頂戴しているコメントのうち、攻撃例が多くバランスが悪いという指摘については、 「PHPサイバーテロの技法」のようなコンパクトな書き方を参考にさせていただいて、い ちぶ簡潔にまとめようと思います。とくにXSSの節が該当します。 元々は、この後も脆弱性の項目毎の説明を書いていくつもりでしたが、XSSとCSRFを 書いたことで、セッション管理やSame Origin Policyの説明がないとわかりにくいと感じ ており、指摘も頂戴しています。 このため、当初予定を変更して、セッション管理とSame Origin Policyの説明を書き始 めようと思います。セッション管理は元々執筆予定でしたが、Same Origin Policyは目 次案にはないので、Cookieの後くらいにいれようと思います。 # Same Origin Policyの説明は難物だと思っており、分かりやすい説明・書籍をご存じ # のかたは教えていただけないでしょうか。参考にさせていただきたいと思います。 Copyright © 2011 HASH Consulting Corp. 34
進捗管理表 Copyright © 2011 HASH Consulting Corp. 35
徳丸本の“こだわり” Copyright © 2011 HASH Consulting Corp. 36
想定読者 • とにかく開発者に訴求したい – PHPなどを用いて独力でアプリが書ける人 – 「独力で」というところが意外にハードルが高いかも – PHPは書ける、Linuxのコマンドライン操作はできない(かも)という ライン • 専門家はどうでもいい(同業者だし) Copyright © 2011 HASH Consulting Corp. 37
取り上げた脆弱性 • 安全なウェブサイトの作り方の脆弱性9種類を包含する • 「ウェブ健康診断仕様」に含まれる12種類の脆弱性を包含す る • 実害がはっきりしているものを重視 – OPTIONSとか、バージョンが分かる系は割愛 • サンプルに対するこだわりに続く・・・ Copyright © 2011 HASH Consulting Corp. 38
サンプルに対するこだわり Copyright © 2011 HASH Consulting Corp. 39
脆弱性サンプルの四原則 – 何かしら役にたつ機能を備えること – 現場で「やってしまいそうな」想定であること – 実害のある脆弱性が発現すること – ターゲット以外の脆弱性を含まないこと Copyright © 2011 HASH Consulting Corp. 40
適切でないサンプルの例 正しくは "¥$c = $a/$b" http://www.ipa.go.jp/security/awareness/vendor/programmingv1/a04_02_main.html より引用 Copyright © 2011 HASH Consulting Corp. 41
サンプル作りで大変だったこと • 正常系のシナリオを考えるのが一番大変だった – OSコマンドを呼び出す必然性 – その他、eval、includeを使う必然性は? – 開発者に「そんなシナリオあり得ない」と思われたら負け • その上で、できるだけ実害の大きな攻撃パターンを考える – 開発者に「それは大変だ」と感じてもらいたい – 「それで、何か問題でも?」と思われたら負け • サンプルの品質管理 – コードの見栄え、一貫性(大文字・小文字の使い分けなど) – 正常系がちゃんと動くこと – 攻撃パターンが、きちんと攻撃になっていること – レビュアーからの指摘も結構あった(中には「恥ずかしい」指摘も) Copyright © 2011 HASH Consulting Corp. 42
その他困ったこと • 用語の選定 – 信頼できる用語辞典がない 例:「チケット」と「トークン」の違い – Google検索などで文脈ごとに用例を調べ、最終的には自分の語感を信じるしか なかった – Cookieか「クッキー」か→基本的にはカタカナに • 脆弱性の呼び方 – 基本的には保守的に、定着した用語を用いる – 定着した語がない場合は、CWEを参考に(例:File inclusion) • 前提知識をどの程度におくか(承前) – 当初は、開発初心者を想定していたが、少し高い目になったと思う • セキュリティとは…など基本的な概念をどう説明する? – 辞書的な説明は割愛することにした(例:ISOxxxでは…) – ついでに、「セキュリティのCIA」のような話題も割愛 – 但し、内容としてはCIAの話は出てくる(当然と言えば当然だが) Copyright © 2011 HASH Consulting Corp. 43
書かなかったこと • UTF-7のXSSはいったん書いたものの、Microsoftのアップテ ートで対策された(らしい)ので削った • hiddenに関する関する話題は少し削りました コラム「hiddenパラメータによる価格改ざんの神話」→ Copyright © 2011 HASH Consulting Corp. 44
主な「書けなかったこと」 • Ajax/JSON – これは最初から書かない予定だった – しかし、「なんとか書けなかったか」という思いは今でも強い – SOP、HTMLのXSS、evalインジェクションなどは書いているので、 実は後一歩という噂も – 第2版を出すチャンスがあればぜひ入れたい • WAFについて – 力尽きました • 「ウェブ健康診断」の具体的な方法 – これも力尽きました – そもそもスペース的に無理だったかも Copyright © 2011 HASH Consulting Corp. 45
まとめ • 徳丸本の「できるまで」と主な「こだわり」 • 1時間では語り尽くせません! • 「徳丸本」がすべて正しいとは思いませんが、今後のディスカ ッションの基準となればよいかなと希望します – 徳丸本では○○の理由で××と書いてあるが、△△の理由で□□ であると考える…など • 安全なアプリケーション開発手法普及の一助となれば幸いで す • リンク集 – サポートサイト http://www.hash-c.co.jp/wasbook – Amazon http://www.amazon.co.jp/dp/4797361190 – 電子版 http://bookpub.jp/books/bp/144 Copyright © 2011 HASH Consulting Corp. 46
ご清聴ありがとうございました