安全な Web アプリケーションの作り方

ブログ枠で入り込みました。
2018年9月10日（月）19：00～20：30 @ EGセキュアソリューションズ株式会社
Connpass から引用:

弊社代表 徳丸の著書であり、ウェブエンジニアのみなさまのバイブルとして親しんでいただいております『安全なWebアプリケーションの作り方』。6月21日に待望の第2版が発売されました。
今回の勉強会では少しカジュアルに、『安全なWebアプリケーションの作り方』第2版執筆にあたっての想いや、初版との違い、お勧めの読み方等を著者徳丸自らがお伝えします。 さらに、第2版で新規に追加された以下の脆弱性のデモもご覧いただきます。

表紙

初版の表紙と第二版の表紙で微妙に向きが変わっている、特に意味はないけど。逆向きの矢印も検討したんだけど、座りが悪った。
初版（amazon） 第二版（amazon）

第二版で改訂しました: メジャー編

• webapi + javascript の問題もいれた。
• html5 対応とも言いたかったんだけど、大々的には謳っていない。
• cors （Cross-Origin Resource Sharing）というのが初版を書いた後にできたので、それをいれている。
• クリックジャッキング、詳しくしている
• ファイルアップロードは大きく追加、PDF ファイルにFormCalc 言語で書かれたスクリプト
• 安全じゃない Deserialization（気合入れて書いた）、XXE （XML External Entity）を eval injection に使っている 、これほんまにあるんかいな、でも OWASP 2017 top10 にランクインしている
• 7 章弱性診断性入門は、頑張って書いたけど、あまり注目されず。
• OWASP 2017 top10 との対照表をつけた
• OWASP 2017 top10 にはないんだけど、トランジャクションとか SQL の排他制御の問題を書きたかった、時間切れで適当なサンプルが作れず、断念。

第二版で改訂しました: マイナー編

• ファイルアップロードフォームでの CSRF
• OS コマンドに環境変数でパラメータを渡す
• ログインフォーム（ID、パスワードの二段階入力）、今どきの記述を見て改変しました
• アジャイル開発へのセキュアプログラミングの適用

第二版で消えたもの

削った箇所は思い入れが深いもので、初版を手に入れ読み物としてどうでしょうか（中古で買うと安いですよ）

• 画像ファイルによる XSS はばっさり切った、好きな画像ファイルを upload する機能ってのがあるよね、それ。
• javascript を画像の中に入れて、IE が中身をみてしまって、コンテントタイプを見ていなかったということに起因している。
• 今では必要ないのでマジックバイトチェックは外した。セキュリティ界隈では賛同を受けたので、思入れはあるけどね。
  • 今時必要ないのに、徳丸本に書いてあるからマジックバイトをチェックしないのは脆弱性といわれるのは本望ではない。過剰なセキュリティを組み込むべきではないと私は思う（徳丸先生からの註あり、コメントを参照すること）。
• dns リバインディングの説明を消す。
• レインボーテーブルの原理も消す。レインボーテーブルの時代ではない現在は GPU で計算きるし。今でも売っているけど何 T もある大きなファイルを購入してもあんまり意味ないと思う。
• 以前の IE のみ影響する問題を削除、Feature phone 関連も削除

自習環境の変更

初版

• Windows のみ。なぜならば SB クリエイティブの担当者がぺちぱー（PHPer）入門対応でいいといっていたから。
• 入門者は mac なんか使わんだろということで、Windows VMWare player となった（mac の VMWare は有料）。

第二版

• burp でもよかったんだけど owasp zap
• macos の VMWare は有料なので Virtualbox にした
• 脆弱性診断士に最初に渡される本になってしまったので、macos もサポートした
• 一応 virtual イメージは、32 bit で動く
• nginx を入れているのは reverse proxy に対応したいから
• postgres は複文（select + update）が動くので postgres にしていたけど mariadb の pdo 版は複文が動くので mysql とした。mysql はセキュリティネタとしては楽しい（つまり、あぶねーってことを意味する）。postgres 界隈からはなんでーといわれたけど、シェアも多いし mysql とした。
• メールサーバーの準備を楽にするためにRoundcubeをいれた。これでブラウザだけでできる。
• php 5 と 7 に対応させるため、二通りのバージョンの libxml をいれた。
• これだけ入っていて、自作するのは大変だからお買い得かもね。

徳丸本の読みかた

• 3 章と手を動かしてください。エラーメッセージが出るところまで確認すること。
• 4.3 章はからの 4 章は、必要なところだけ手を動かしながら読んでください。

レビュアー

• 初版は、あえて初心者にもお願いしました
• 二版は初心者はいいだろということで、その道のスペシャリストにお願いしています。

FormCalc 言語のPDF ファイル埋め込み

FormCalc はサイトの脆弱性とはいいがたい。IE はまあよくなってはいるんですけど、adobe reader の仕様が良くない。

対策:

• PDF の upload を禁止（まあ禁止しようがないね）
• IE （など攻撃ができるブラウザ）の禁止（これも現実的ではない）
• adobe reader plugin の禁止、これはできるかも
• こういう攻撃は get リクエストなで、post リクエストの強制でいいんじゃない? あんまり凝ってもしょうがないし。

php serialize deserialize の実演、まあ本見て

攻撃用の cookie をシリアライズして入れる。シリアライズせず json で行きましょう。

XSS 外部実態参照

• 本当は java のほうが面白い（影響を受けやすい）んですけど
• java でデモします（いつものようにデモを実演される）
• xml 使わない json 使う
• どーしても xml を使いたければ、libxml の 2.2.9 以降を使う。2.2.9 以前でもメジャーどころだとパッチ当たっている。

5章 代表的なセキュリティ機能

• ログインまわりのはなし。
• 伝統的ポリシーは SP800-63-3 の逆張りである
• SP800-63-3「異なる文字種を組み合わせる規則や定期変更の強制は推奨しない」
• 省庁などのポリシーは、伝統的ポリシーから簡単には変更できないが、伝統的かSP800-63-3どちらに振るのかは決めてください
• バージョン番号を apache などで公開するか?
  • 当社では明らかに脆弱性があるバージョンがあれば High にするが、問題がなければ Low にする。
  • バージョン見て攻撃するやつらもまあいるだろうけど、そんなもの見ずにいきなり攻撃が多いと思われる。業界内でも意見が分かれるところ。
• パスワードはマスクするべきか
• IE はボタン表示ボタンを実装できる
• paypal はパスワードを表示する機能がある、パスワードが表示されないので、簡単はパスワードを選ぶ傾向になるのを避けるためではないか。
• google ログインについて「アカウントは見つかりませんでした」と表示するのは従来だとダメといわれているやりかた。アカウントが存在するのがわかるので。
  • しかし、「アカウントは見つかりませんでした」と指摘されないと、アカウントが間違っているのか、パスワードが間違っているのか、わからない（特に長いパスワードを使っている場合）。恐らくユーザーフレンドリー側に振ったのではないか? ユーザーフレンドリーとセキュリティのバランスをどこに持っていくかが大事、だけど、おいそれと真似をするできるものではない。恐らく、google には何回か間違えるとダメになる機能が実装されていると思える。

よい脆弱性のサンプル

• 何かしら役に立つ機能があること。
• 現場で、いかにもやってしまいそう、こりゃーやらんだろというのは良くない
• 実害のある脆弱性が発現すること
• 一つの例で見せるには一種類だけ。複数組み込まない。
• 「Bad Todo List」

サンプルで添付した「Bad Todo List」

• 「Bad Todo List」徳丸本2のための完全書下ろし。
• 非常に多くの脆弱性があり、本に載せていないものもある。
• やられサイトも要件定義が必要。例えば XEE を組み込むには xml をどこかで使わないとならない
• http://example.com/hoge.php#<img src=1 onerror=alert();>
  • 古い jquery は問題ありという記述はよくあるが、実例が掲載されているというのは珍しいのではないか。 Bad Todo List も 1.8.3 を使っているので、古くはあるが、診断をしていると 1.5 ってのもふつーにあるので古い jquery と遭遇するのはありえない話ではない。

9 章 安全なWebアプリケーションのための開発マネジメント

• セキュア開発プロセスの説明
• 初版から大きくかわっていないんですけど、アジャイル向けだとどうなんのよく聞かれる。でもアジャイルだとセキュア開発プロセスが重いってよくいわれるけど、やったほうがいいですよね。「重い」を、どうすれば効率的に実施するかに変えればいいではないか。
• 本見て頂戴
• 機能を増やすにしたがってリリース毎にセキュリティ逐次投入という手もあるが、これやるとコストがかかるので最初から入れるという手もある。
• あとから直すのは手戻りが発生するので、簡単でクリティカルのものであれば、早いうちから自動ツールで自ら診断する（内製化）という方策もあると思う、脆弱性診断の自動化もあり。
• モダンなフレームワークを選ぶ。
• テストの自動化、継続性に特化したツール、サービスを用いる
• ソースコード診断ツールをもちいるのもいいが、誤検知が多いのが欠点ではある。