1. uryyyyyyy

    Posted

    uryyyyyyy
Changes in title
+SPAでのセッション管理とセキュリティ
Changes in tags
Changes in body
Source | HTML | Preview
@@ -0,0 +1,156 @@
+
+
+## 概要
+
+[Frontend Meetup vol.1 - SPAを語り尽くす会!](http://connpass.com/event/38112/)のLT資料です。
+
+フロントエンドのガチ勢には当たり前の内容になるかもしれません。
+ご指摘あればコメントなどで頂ければと思います。
+
+---
+
+## 自己紹介(後で消す)
+
+- 名前:しばたこ/uryyyyyyy
+- 所属:株式会社オプト
+- 得意分野:Scala/Play2/Spark/React
+- 最近はReact/Redux/TypeScriptで書いてます。
+- materializeを導入したのですがjQueryなかなか辛い。。。
+
+![](https://avatars.githubusercontent.com/u/5005858?v=3)
+
+---
+
+## この資料で話すこと
+
+- SPAでのセッション管理
+- CSRF対策
+- CORS
+
+---
+
+## SPAでのセッション管理
+
+---
+
+### Cookie
+
+- ブラウザの状態管理のためのもの。
+- もちろん主要ブラウザはどこも付いてます。
+- railsでもplayでもとりあえずこれでセッション管理されています。
+- secure属性があると、httpsのときだけやりとりされます。
+- HttpOnly属性があると、jsから読み取れないようにできます。
+
+基本、フロントエンド側では特に意識しなくてもサーバーサイドの人がよろしくやってくれるでしょう。
+
+---
+
+### SessionStorage
+
+Cookieは、過去の脆弱性の話とか後述するCSRFの話があり、「危ないのではないか」と思う人もいるかもしれません。
+ここで、「SessionStorageでTokenを管理したらどうか」という声もたまに聞きます。その場合は以下の制約があると思います。
+
+- 対応してないブラウザもある。
+- 認証の前にjsが読まれていないと値を取れない。
+- ユーザーがCookieを消しても認証されるという状態になる。
+- 外部の悪いJSを読むとTokenが抜かれる危険がある。
+- Tokenのexpireを自前で設定する必要がある。(サーバーにお任せできない。)
+
+逆に言えば、このあたりがクリアできればアリかもしれないです。
+(僕は使ったことはないです。ご意見求めます。。。)
+
+---
+
+## CSRF対策
+
+---
+
+### CSRF Token
+
+SPAでないWebアプリだと、Form画面の中にCSRF Tokenを仕込んで、リクエスト時にそれでチェックする方式がよく用いられます。
+
+しかしSPAでは、フロントのコードがサーバーを経由せずに送られてきたり、Formが後から動的に作られうるので、仕込むタイミングが少し難しいかもしれません。
+
+### ブラウザのpre flightを利用する
+
+後述のCORSに関わってきますが、ブラウザは訪れたドメインでないドメイン(3rd party)へのリクエストに対しては、セキュリティのためにpre flightという仕組みを持っています。
+
+---
+
+まず、普通のCSRFの仕組みから。
+攻撃者は以下のことは外部ページから普通に行えてしまえます。
+
+- 全てのGET
+ - REST的にはGETでリソース編集をすべきでないので無視
+- POSTのContent-typeが以下のとき(他にあるのか把握してないですが十分かと)
+ - application/x-www-form-urlencoded
+ - multipart/form-data
+ - text/plain
+
+---
+
+しかし、以下のリクエストを投げるためには、事前にpre flightが飛ぶようになっています。
+
+- POSTのContent-typeが上記以外(application/jsonなど)のとき
+- 独自ヘッダが付与されているとき
+
+---
+
+このあたりは以下に詳しく書かれています。
+
+- [Protecting against Cross Site Request Forgery](https://www.playframework.com/documentation/2.4.x/ScalaCsrf)
+- [独自ヘッダをチェックするだけのステートレスなCSRF対策は有効なのか?](http://blog.a-way-out.net/blog/2015/03/23/stateless-csrf-protection/)
+- [XMLHttpRequestを使ったCSRF対策](http://d.hatena.ne.jp/hasegawayosuke/20130302/p1)
+
+---
+
+ちなみに、(Chrome環境でですが)動作を試したサンプルを置いておきます。
+
+https://github.com/uryyyyyyy/cookieTrackingSample
+
+---
+
+まとめとしては、独自ヘッダを付けるか、Content-TYpeをapplication/jsonにして、サーバー側でバリデーションをかけてもらう(かつ、サーバー側でOPTIONメソッドの呼び出しでリソース編集をしない)とCSRFを防げるかと思います。
+
+---
+
+## CORS
+
+---
+
+### CORS
+
+(すみませんがあまり理解しきれていないです)
+
+ブラウザでは、上述の外部ドメインのリソースの操作だけでなく、リソースの取得にも同様にセキュリティ対策がされています。
+(例えば、怪しいサイトに訪れた時に自分のFacebookのCookieを利用してアカウント情報を取られたら嫌ですよね。)
+
+なのでブラウザでは、自分が訪れたドメイン(A)から外部ドメイン(B)へGETしてきたデータを扱う場合には、Bのデータのヘッダに「Aのサイトを許可する」という情報を与えられていない場合は、そのGETした情報を無視します。
+
+詳しくはこのあたりを見ればいいのではと思います。
+
+[CORS(Cross-Origin Resource Sharing)によるクロスドメイン通信の傾向と対策](http://dev.classmethod.jp/cloud/cors-cross-origin-resource-sharing-cross-domain/)
+[CORSまとめ](http://qiita.com/tomoyukilabs/items/81698edd5812ff6acb34)
+
+---
+
+## まとめ
+
+- ざっくりでもセキュリティの話を知っておくのは大事。
+- ブラウザの制約などは意味のあることなので、ちゃんと理解して使う。
+- SPA
+
+---
+
+## 宣伝(後で消す)
+
+- オプトではフロントエンジニアも絶賛募集中です。
+ - 既にAngular2も実戦投入しつつある
+ - TypeScriptやReactも導入が進んでいる
+ - どんな技術もしれっとぶち込める。[参考](http://www.slideshare.net/yasuyukisugitani/scalascrumdddgatlingtalk#145)
+ - そのくせ、社内にフロント専業マンはほぼ居ない
+
+興味を持った方はぜひお話を。
+
+![](https://www.opt.ne.jp/opttechnologies/assets/images/home/about.png)
+https://www.opt.ne.jp/opttechnologies/