2014年02月

CSRF対策用トークンに関するメモ

使ってはいけない理由の一、「セッション cookie を HttpOnly 付きで発行している場合」については、高木さんの書かれている「3. cookieは漏れないが、HTMLテキスト(hiddenパラメタを含む)は漏れる脆弱性」であり、「hiddenパラメタにcookieと同じセッションIDを入れておくことが新たな脅威を生むことはない」。

使ってはいけない理由の二、「BREACH attack の影響を受ける場合」については、「4. cookieは漏れないが、hiddenパラメタは漏れ、しかしそれ以外のHTMLテキストは漏れない脆弱性」にあたる。この脆弱性を放置するのであれば、『「セッションIDをそのままhiddenに入れないほうがよい」という理屈は成り立つ』。

ただ、海老原さんの書かれているように、「この場合はまず BREACH への対策をするべき」だ。セッションIDと同じでなかろうと、漏れてしまっては、CSRF対策用トークンの意味がない。

そのうえで、また「著しく特殊な脆弱性が将来生ずる可能性があると心配するならば」、「セッション ID を SHA-2 ファミリのハッシュ関数あたりを通して」使えばよい。


2014-02-19

HTMLに埋め込まれたCSRF対策用トークンが漏れやすいのであれば、セッションIDと同じでなかろうと、そもそも埋め込むべきではない。「ソーシャルエンジニアリング的な手法」経由のCSRF攻撃なら受けても仕方がない、という判断もありえるだろうが、僕はいやだ。

対策は簡単だ。フォーム送信時に、Cookieに保存されたセッションIDをJavaScriptで参照し、パラメータに加えるだけでよい。「Kazuho@Cybozu Labs: CSRF 対策 w. JavaScript」に書かれているとおり。スクリプトが無効のクライアントには申し訳ないが、それ以外の対策が思いつかない。

「CSRF対策用トークンをHTMLに埋め込んでもいい時代は終わりつつある」。と、まとめてみた。


2014-02-20

Webアプリの開発者が気にすべき点は以下の通り。

  1. CookieにHttpOnlyを付けるべきかどうか
    1. XSSへの保険的対策として付けるべき
    2. XSS脆弱性がなければ問題ないのだから付けなくてよい
  2. HTMLへのセッションID埋め込みを避けるべきかどうか
    1. 漏れやすいから避けるべき
    2. 漏れにくいから埋め込んで構わない
  3. HTMLへのCSRF対策用トークン埋め込みを避けるべきかどうか
    1. 漏れやすいから避けるべき
    2. 漏れやすいが影響度は低い(あるいは軽減できる)から埋め込んで構わない
    3. 漏れにくいから埋め込んで構わない

1-1を採るなら、2-1、3-1または3-2を採るのが自然だ。教科書的には、こちらを選ぶしかないように思う。

1-2を採る場合、XSS以外によるHTML漏洩の可能性をどのくらい見積もるかによって、2と3の選択肢が変わってくる。漏れやすいと思えば2-1、3-1または3-2、漏れにくいと思えば2-2、3-3。


2014-02-20 #2

まだ論点があるのか。

  1. Cookieが漏洩した場合に備えて保険的対策を講じておくべきかどうか
    1. 漏れやすいから講じるべき
    2. 漏れやすいが根本的対策はないから(あるいはユーザの利便性を損なうから)講じなくて構わない
    3. 漏れにくいから講じなくて構わない

もう、どうしたらいいのかね。1-1、2-1、3-2、4-2あたりが時代の趨勢なのか。

1-1.
CookieにはHttpOnly属性を付ける
2-1, 3-2
CSRF対策用トークンはHTMLに埋め込むが、セッションIDそのままは不可
4-2
CookieからのセッションID漏洩は気にしない

2014-02-21

セキュリティの専門家の間でも見解が分かれてしまうのだから、セキュリティにばかりかまけていられないWebアプリ開発者は、えいや、と自らの信じるところを選ぶしかない。Webセキュリティ、実にめんどうくさい。

自宅PCのバックアップ構成を変えた

NASに置いているデータはGoogleドライブに定期バックアップ

写真、電子書籍、音楽ファイルなど、PC上になくても困らないデータは、NASに置き、そこからGoogleドライブに定期バックアップすることにした。

NASは、QNAPのTS-112WD Red(1TB)。この構成にしてから1年ほど経つが、何の問題も起きていない。

Googleドライブへのバックアップには、NAS管理ツールのアドオン「Google Drive Sync」を使う(参考:「Turbo NASのデータをGoogle Driveにバックアップします」)。現状、スケジュールが1つしか保存できないのが難点だが、同じ共有フォルダにデータをまとめてしまえば問題ない。データが増える頻度は少ないので、週1度、月曜の午前4時にバックアップすることにした。

バックアップ先にGoogleドライブを選んだのは、上記のアドオンが使えるのと、価格の安さ(100GBで月4.99ドル)、さらにはサービスの持続可能性を考慮してのことだ。セキュリティについては、漏れてもさほど困らないデータしかないので、まあ問題ないだろう。

ちなみに、写真はGoogle+にも保存している。スマホで撮った写真はアプリで自動バックアップ、デジカメで撮った写真はNASとGoogle+に手動バックアップ、という寸法。これだけバックアップしていれば、なくなる心配はない。

PC上のデータは、NASとSpiderOakへ

日々使っているPC上のデータは、NASへ手動バックアップし、さらにNASからSpiderOakへ自動バックアップすることにした。

NASへの手動バックアップには、BunBackupを使い、バックアップ対象フォルダを2つの形式でミラーリングする。1つはBunBackupの機能で暗号化したもの、もう1つは生データだ。バックアップ対象のデータは頻繁に増減するので、毎晩就寝前に必ずバックアップする。BunBackupには完了後にWindowsを終了する機能があるので便利だ。

NAS上の暗号化データは、SpiderOakのアプリで自動バックアップされる。アプリ側でも暗号化されるとはいえ、その前に暗号化しておくほうが、より安全だろう。

生データもNASにバックアップするのは、復号化せずにすぐ開きたいこともありそうだから。暗号化データのみの場合より、バックアップに要する時間も容量も増えてしまうが、仕方ない。

バックアップ先にSpiderOakを選んだのは、セキュリティ面と、価格の手頃感から(100GBで月10ドル)。Amazon S3にしようかとも思ったのだが、ファイル数が多くてフォルダ構成を頻繁に変える僕の場合、かえって高くつきそうなのでやめた(思い違いがあればすみません)。


SpiderOakを使ってみたい方は、https://spideroak.com/download/referral/74fce446e2b8803f997de5a4dd4d47a3から登録していただくと、無料分の容量が2GBから3GBに増えるかもしれません。よろしければどうぞ。


追記(2014-03-27)

先日、Googleドライブが値下げされ、100GBで月4.99ドルから1.99ドルになった。年間で36ドルも安くなったことになる。

また本日、SpiderOakのキャンペーンが始まり、永年無制限容量プランが年125ドルで申し込めるようになった。3月31日までなので、気になる方はお急ぎを。僕はさっそく切り替えました。

記事検索
Twitter