.app 1 .dev 1 #11WeeksOfAndroid 13 #11WeeksOfAndroid Android TV 1 #Android11 3 #DevFest16 1 #DevFest17 1 #DevFest18 1 #DevFest19 1 #DevFest20 1 #DevFest21 1 #DevFest22 1 #DevFest23 1 #hack4jp 3 11 weeks of Android 2 A MESSAGE FROM OUR CEO 1 A/B Testing 1 A4A 4 Accelerator 6 Accessibility 1 accuracy 1 Actions on Google 16 Activation Atlas 1 address validation API 1 Addy Osmani 1 ADK 2 AdMob 32 Ads
概要 JWTを認証用トークンに使う時に調べたことをまとめます。 JWTとは JWTはJWSやJWEの構造の中にエンコードして埋め込まれるJSON形式のclaimのセットです。 一般的にはJWS形式のJWTが使われるのでそれを前提に進めます。 JWS形式のJWTは以下のフォーマットです。 {base64エンコードしたheader}.{base64エンコードしたclaims}.{署名} 以下の特徴があります。 発行者が鍵を使ってJSONを署名（or HMAC）し、トークンとして扱う。 暗号化ではないので、JSON の中身は誰でも見られる。 発行者は鍵を使ってメッセージの検証ができるので、改竄を検知できる。 以上の点からトークンとして向いているため、認証トークンとして用いられるようになってきました。 Cookieとの認証フロー比較 ref: Cookies vs Tokens. Getting
編集履歴 ※ SessionStorage→LocalStorage（永続化される方はこちらだった） ※ OPTIONメソッド→OPTIONSメソッド ※ JWTについて少し調べたのでLocalStorage欄を追記 概要 Frontend Meetup vol.1 - SPAを語り尽くす会!のLT資料です。 フロントエンドのガチ勢には当たり前の内容になるかもしれません。 SPA探り探りなので、ご指摘あればコメントなどで頂ければと思います。 自己紹介（後で消す） 名前：しばたこ/uryyyyyyy 所属：株式会社オプト 得意分野：Scala/Play2/Spark/React 最近はReact/Redux/TypeScriptで書いてます。 materializeを導入したのですがjQueryなかなか辛い。。。 この資料で話すこと SPAでのセッション管理 CSRF対策 CORS SPAで
gistfile1.md CVE-2016-7401 https://www.djangoproject.com/weblog/2016/sep/26/security-releases/ https://hackerone.com/reports/26647 pythonのcookie parserが ; 以外もpairsの区切り文字として解釈するので、google analyticsのreferrer経由でsetされるcookieを使ってCSRF tokenを上書き可能だったという問題。 django側でcookie parser自前で実装、python本体は直ってないようだ https://github.com/django/django/commit/d1bc980db1c0fffd6d60677e62f70beadb9fe64a 多くのcookie parserは、pairsの区
■ 共用SSLサーバの危険性が理解されていない さくらインターネットの公式FAQに次の記述があるのに気づいた。 [000735]共有SSLの利用を考えていますが、注意すべき事項はありますか？, さくらインターネット よくある質問（FAQ）, 2010年2月10日更新（初出日不明） Cookieは、パスなどを指定することができるため、初期ドメイン以外では共有SSLを利用している場合にCookieのパスを正しく指定しないと、同じサーバの他ユーザに盗まれる可能性があります。 （略） 上記については、「同サーバを利用しているユーザだけがCookieをのぞき見ることができる」というごく限定的な影響を示していています。また、Cookieの取扱いについて、問い合わせフォームやショッピングカート等、ビジネス向けのウェブコンテンツを設置されていなければ特に大きな問題とはなりませんが、個人情報を取り扱われる管
思いは言葉に。 はてなブログは、あなたの思いや考えを残したり、 さまざまな人が綴った多様な価値観に触れたりできる場所です。
こないだ、よくわからんので今度調べると書いたところについて。 CSRFの対応について、rails使いが知っておくべきこと - おもしろWEBサービス開発日記 まずクッキーとセッションの違いから。自分の認識はこんな感じ クッキーもセッションも、ブラウザにデータを保存させる仕組み。 クッキーはデータをそのままブラウザに保存させる。 セッションはセッションIDをブラウザに保存させ、データはサーバ側が保持する。サーバはセッションIDをキーにしてデータを取り出す。 railsでクッキーを設定するには railsでは、クッキーは基本的に使わないと思ってますが、一応使い方をメモ。 cookies[:hoge] = { :value => "value", :expires => "30.days.from_now", :path => "/store", :domain => "www.example.
ロードバランサーの機能のうち、セッション維持は重要な役割な一つです。セッション維持を実現するための方法としては主に4つあります。 ソースIPアドレス利用 Cookie利用 SSL Session ID利用 URL利用 一番手軽なのはソースIPアドレスを利用する方法なのですが、NAT(Network Address Translation)環境では全てのマシンが同じIPアドレスに見えてしまうのでこの方法が使えない場合も多いと思います。そんなわけで私はこれまでCookieを利用する方法をよく使っていました。しかし最近になってCookieを利用したセッション維持が失敗するケースが増えてきました。それはなぜでしょうか？ Cookieを利用する方法の問題点 Cookieを利用したロードバランスでは、セッション情報をCookieに書き込みます。ところでCookieの仕様をRFC2965で確認してみると
2007年11月29日07:15 カテゴリ書評/画評/品評 Immortal Session の恐怖 さすがの私も、今夜半の祭りにはmaitter。 私のtwitterが荒らされていたのだ。 荒らし発言は消してしまったが、にぽたんがlogを残してくれている。 nipotumblr - Dan the cracked man 一部で言われているように、本当にパスワードが抜かれたかどうかまでは解らない。が、状況としてはnowaがベータテスト段階で持っていたCSRF脆弱性をついた荒らしにそっくりだった。 にぽたん無料案内所 - こんにちはこんにちは！！ この時も、私のnowaのメッセージに荒らしが入った。パスワードを変更しても暫く荒らしが続いていた点も似ている。 ここでの問題は、 bulkneets@twitter曰く(直接リンクは避けます) 問題は本人が気付いてもパスワード変えてもセッション残
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く