wasbook reading #5

「体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践」読書会の第5回。
仕事が忙しくてしばらく空いてしまったけど再開する。来週は夏休みのひとがいたりして、また一回休みだけど。
今回読んだのは以下の範囲。

  • 4章 Webアプリケーションの機能別に見るセキュリティバグ
    • 4.7 リダイレクト処理にまつわる脆弱性
    • 4.8 クッキー出力にまつわる脆弱性
    • 4.9 メール送信の問題

4章 Webアプリケーションの機能別に見るセキュリティバグ

4.7 リダイレクト処理にまつわる脆弱性

オープンリダイレクタを実装するのであれば、クッションページをいれる。個人的にはクッションページがあると邪魔で嫌だけど、確かにフィッシングで騙されてしまうかもしれない。
オープンリダイレクタの根本対策は、「リダイレクト先のURLを固定にする」、「リダイレクト先のURLを直接指定せず番号指定にする」、「リダイレクト先のドメインをチェックする」とあるが、これらの対策を施したらオープンリダイレクタではなくクローズリダイレクタではないだろうかと思った。オープンリダイレクタの対策の解説では、間違い易い正規表現の例が載っていてわかりやすかった。
HTTPヘッダインジェクションは、普通にWebアプリケーションを作っている限りはあまり発生しなさそうだけど、ミドルウェア脆弱性などで発生しそうな気がした。
HTTPヘッダインジェクションに限らないけど、外部から受け取ったパラメータを、検証せず安易に変数にいれちゃだめだよね。とりあえず HttpServletResponse#addHeader とHttpServletResponse#setHeader を試してみたけど、value に改行を入れるとちゃんと出力されなかった。valueが空になっていた。ふうむ。

4.8 クッキー出力にまつわる脆弱性

最近はCookieに値をセットすることなくなったな、と思いながら読んでいた。逆に大学生のころをがんがんセットしていた気がするw
クッキーとセッション変数の比較表があった。セッションという言葉は、よく考えるといろんな意味に捉えることができて難しい。HTTPはステートレスだし。けっきょく値をセッションに格納すると、セッションIDがクッキーに入って、値はサーバ側にあるということを、理解しておく必要がある。まあ、Web開発であれば基本的なことだけど。
Cookieのdomain、path、secure属性は、知らない人も多い気がする。僕はシングルサインオンなシステムをごにょごにょやったときに勉強した。ログイン情報を引き回す必要があったので。
サーバ側でsecure属性つけると、HTTPヘッダーでは何が起こるんだ?と思ったら、Set-Cookieにsecureって付くだけだった。シンプル。
Twitterで常にHTTPSを利用するを選択すると、Cookieにsecure属性がついた。はずすと消えた。なるほど。
Cookieは確認しやすいからわかりやすい。
あとHttpOnly属性をつけても、ChromeのDevToolで console.log(document.cookie) とすると、普通にcookieが見えた。ローカルからは見れるのかもしれない。

4.9 メール送信の問題

メール処理は実装したことがない。実装したとしてもJavaMailとかを使うと思う。またメールサーバの構築は、全力で避けている。やったことがなく、できればやらずにいたい。
そんなわけで、いつかメールに関する処理を実装するときは、この章を読み返そうと思い、ななめ読みした。

今回のまとめ

リダイレクタやメールの処理は、ユーザとして利用することはよくあるけど、実装経験はあまりなかったので気をつけるポイント(対策)がわかってよかった。どんなところに注意しなくてはいけないのか、どんなところで問題が発生するのか、ということを知っておくことは大切だと思った。
もうちょっとで半分終わる。やっぱりディスカッションしながら読み進めると、普通に読んでいるよりも気付きが多い。もちろんその分大変だけど。頑張って読了したい。


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



電子書籍版はこちら。