1. uryyyyyyy

    No comment

    uryyyyyyy
Changes in body
Source | HTML | Preview
@@ -1,189 +1,189 @@
## 概要
[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を管理したらどうか」という声を上げたりします。あまり聞いたことはないですが、その場合は以下の制約があると思います。
- ~~対応してないブラウザあるかも~~
- 対応してた http://caniuse.com/#search=SessionStorage
- 認証の前にjsが読まれていないと値を取れない。
- 外部ドメインからのCORSはできない。
- ブラウザで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
```js
//pre flight飛ばない
//application/x-www-form-urlencodedが飛びます。
$.ajax({
type: "POST",
url: "http://localhost:8080/pre_flight",
data: "key=value",
success: function(msg){
console.log( "Data Saved: " + msg );
}
});
//pre flight飛ぶ
$.ajax({
type: "POST",
url: "http://localhost:8080/pre_flight",
data: { name: 'norm' },
contentType: "application/json",
success: function(msg){
console.log( "Data Saved: " + msg );
}
});
```
---
まとめとしては、独自ヘッダを付けるか、Content-TYpeをapplication/jsonにして、サーバー側でバリデーションをかけてもらう(かつ、サーバー側でOPTIONメソッドの呼び出しでリソース編集をしない)とCSRFを防げるかと思います。
---
## CORS
---
(すみませんがあまり理解しきれていないです)
ブラウザでは、上述の外部ドメインのリソースの操作だけでなく、リソースの取得にも同様にセキュリティ対策がされています。
(例えば、怪しいサイトに訪れた時に自分のFacebookのCookieを利用してアカウント情報を取られたら嫌ですよね。)
なのでブラウザでは、自分が訪れたドメイン(A)から外部ドメイン(B)へGETしてきたデータを扱う場合には、Bのデータのヘッダに「Aのサイトを許可する」という情報を与えられていない場合は、そのGETした情報を無視します。
---
逆に、この仕組を使えば静的ファイルとAPIサーバとを別ドメインに置くことも出来ます。
SPAのコードはS3に置いて、サーバーはEC2とかですね。
詳しくはこのあたりを見ればいいのではと思います。
[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
+- サーバーサイドのツラミを知ろう。
---
## 宣伝(後で消す)
- 上記の内容を細かく書いた記事を弊社技術マガジンで公開中です。
- [社内勉強会でCookieの仕様とセキュリティについて話しました ](http://tech-magazine.opt.ne.jp/entry/2016/09/12/112048)
- オプトではフロントエンジニアも絶賛募集中です。
- 既に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/