wasbook reading #1

wasbook security

「体系的に学ぶ 安全なWebアプリケーションの作り方　脆弱性が生まれる原理と対策の実践」は500ページ近くある。とても読み通す自信がない。そんなわけで [twitter:@piyokango] と会社の後輩に声を掛けて、3人ばかりのちいさな読書会をすることにした。週1開催の全10回くらいで読み終えたいと思っている。
今日はその第1回だった。読書会には参加したことないので、とりあえず3章まで読んできて、みんなで感想を話し合った。
というわけで、今回読んだのは以下の範囲。

  • 1章 Webアプリケーションの脆弱性とは
    • 脆弱性とは、「悪用できるバグ」
    • 脆弱性があるとなぜ駄目なのか
    • 脆弱性が生まれる理由
    • セキュリティバグとセキュリティ機能　他
  • 2章 実習環境のセットアップ
  • 3章 Webセキュリティの基礎 ~HTTP、セッション管理、同一生成元ポリシー
    • HTTPとセッション管理
    • 受動的攻撃と同一生成元ポリシー

1章 Webアプリケーションの脆弱性とは

Gumblar は広まっていたけど、 実被害はどれくらいあったんだろう？SQLインジェクションによる被害は金額的なことも話題になるけど、それ以外はよくわからない。XSS系の被害は、実は少ないのかもしれない。
脆弱性を作らないようにするには、なるべく作らないのがいちばんかも。あとは不要な情報を持たないこと。
何も考えずに post とか get のサンプルプログラムを作ったら、XSSの脆弱性も付いてくるし。
セキュリティ機能で HTTPS がある。SSL を導入するのはいいけど、運用も大事だね。期限切れとかよくある。そういうのは要件として扱って、ちゃんとメンテンナンスしないといけない。

2章 実習環境のセットアップ

IISで動くサンプルも欲しいね。サンプルをIISで動かせばいいのだけど。
Fiddler 以外で良いツールある？→burp suite とか
僕は基本的に Chrome Developer Tool があればいい。リクエストの書き換えはあまり行わない。HTMLやCSSを書き換えたり、JSを実行したりできればいい。いちいちプロキシの設定をするのは面倒。これは開発者視点だからかも。
セキュリティの確認が目的だと、リクエストを書き換えらればいいのかも。

3章 Webセキュリティの基礎 ~HTTP、セッション管理、同一生成元ポリシー

HTTPとセッション管理

JavaでURLエンコード、デコードするときは注意が必要。標準の他の言語でエンコード/デコードしたものと、出来上がった文字列が異なることがある。Apache の commons codec とか使えば大丈夫。

Refererの制限でページが表示できないといらっとする。右クリックが禁止されているようなときのいらっと感と似ている。RefererはJSで書き換えられない(知らなかった！)。CSRF対策にも使える。CSRFって しーさーふ って読むことを教えてもらった。

GETはやっぱり一意なリソースを示すために使うのがいいと思う。Cool な URI を考えると、自然とそうなるかも。

最近だと hash (#!)の入ったURLも話題になった。

あと、GETだとbookmarkできることも開発者にとって重要かも。逆にPOSTはbookmarkできないし。

hidden と cookie の違いを理解しておくことは大事。でもこれからは Web Storage の sessionStorage なんかも同じように利用されるのかな。sessionStorage は hidden や cookie の代替となりうるのだろうか。興味深いテーマだけど、いろいろ難しいので、またいつか考える。

Basic認証の流れ、ちゃんと理解していなかった。昔から設定方法を知っていたけど、だからこそちゃんと理解せずに使っていた。毎回パスワードが送信されていたとは。
じゃあDigest認証はどうなんだ？パスワードのハッシュが毎回同じだったら、Basic認証とあまり変わらないよな、とか考えた。調べてみたら、ちゃんとランダムな文字列を付けていた。毎回違うsaltが付いてるような感じ。

認可と認証については、OpenIDとOAuthに関する以下のエントリを読んだら分かりやすかった。本の内容とエントリの内容を読んだあとでは、「OpenIDは認証でOAuthは認可だ」というのはすごくしっくりくる。

認証後にセッションIDを変更するというは大事。不死身のセッションは怖い。推測可能なセッションIDとかは問題外。

クッキーの domain 属性は、リバースプロキシ型のSSO(Single Sign On)を設定するときに指定した。リバースプロキシでクッキーを受け付けて、後ろのサーバにも渡さなきゃ行けないときとか。Secure とか HttpOnly という属性は知らなかった。
Java だと HttpOnly なクッキーってどうすればいいんだろう。Servlet 3.0 からサポートなのかな。

受動的攻撃と同一生成元ポリシー

XSSとCSRFの違いは、XSSとはブラウザでalert、CSRFはサーバで「こんにちは！こんにちは！」、と僕は思っている。
サンドボックスの効果を感じたことがない。→Adobeのゼロディで、脆弱性があったけど新しいバージョンではサンドボックスのおかげで変な命令は動かなかった。
Same Origin Policy → そっぷ
XML Http Request Level 2 とか、 CORS(Cross-Origin Resource Sharing)とかも押さえておきたい。XHR L2 でCross Domain な通信するときは HTTP Header に Access-Control-Allow-Origin が必要ですよ。

クリックジャッキング対策で X-FRAME-OPTIONS を指定した場合、クリックジャッキングを行ったら画面上はどんなことがおきるのだろうか？「なんとかかんとかは許可されていません」ってアラートでも上がるのかな。

img の src はクロスドメインな指定が可能だけど、これを利用した攻撃とかってできるのかな。img の onerror を使ったXSSはあるけど、クロスドメインとは関係なさそうだし。画像を使ったカウンターとかは、この仕組みを利用していると思う。

JSONPはかなり便利。scriptタグを作れば、外部のjsを読み込むことができる。

CSSを利用したXSSってたまに聞くけどやったことない。こういうサンプルがあると、ちょっと面白いかも。IEの脆弱性以外でもたまに聞くような気がするけど、ちょっと違うものなのかな。

画像ファイルによるXSSなんてものもあったのか。

今回のまとめ

今回読んだのは実質的には第3章の40ページくらいだが、話が脱線したこともあり2時間くらい掛かった。もうちょっとスピードアップしなくては。少数精鋭(?)でやってもこれだけ時間がかかるので、人が多いと全然進まなくなりそう。small start でよかった。
立場やスキルの違うひとと話しながら読み進めるのは、想像以上に勉強になる。自分の気付かなかったことを考えるきっかけになる。これ難しくてわかんねーとか言いながら、教えてもらったり教えたりできる。
いろいろと抜けている知識があって、それを補完できるのがよかった。知らなかったことが、ちょこちょこあるので、読んでいて楽しい。来週も頑張らなくては。


wasbookに関するものは、こちらのタグで。


体系的に学ぶ 安全なWebアプリケーションの作り方　脆弱性が生まれる原理と対策の実践
体系的に学ぶ 安全なWebアプリケーションの作り方　脆弱性が生まれる原理と対策の実践
posted with amazlet at 11.05.17
徳丸 浩
ソフトバンククリエイティブ
売り上げランキング: 3997
Amazon.co.jp で詳細を見る


電子書籍版はこちら。