Rails SessionにCookieStore使った時の問題点 - OAuth.jp
今日 @mad_p さんからRT来てたこのツイートに関して、ちょっと調べたのでまとめときます。 Security Issue in Ruby on Rails Could Expose Cookies http://t.co/JlsXVEn4rZ — Ruby on Rails News (@RubyonRailsNews) September 25, 2013 前提条件 Railsではデフォルトでsessionをcookieにのみ保存して、DBなりmemcacheなりのserver-side storageには何も保存しません。 これがCookieStoreとか呼ばれてるやつです。 この場合のsession cookieは、Railsのsession object (Hash object) をMarshal.dumpしてそれに署名を付けたtokenです。 rails 4では署名付ける代
Railsでのサインイン・サインアウトの実装 - プログラミング的なSomething
サインインを永続化する サインインを永続化して、サインアウトしたときにセッションを削除するシステムを考えます。 cookieと認証のためのモジュールであるSessionsHelperを用います。 SessionsHelperモジュールをアプリケーションコントローラにインクルードする アプリケーションコントローラとはapp/controller/application_controller.rbです。 すべてのヘルパーはビューで使用できますが、コントローラで使用するため、アプリケーションコントローラにincludeします。 include SessionsHelper 伝統的なセッション保持方法 HTTPはステートレスなプロトコルです。そのため、ページ遷移を追跡してセッションを保持します。以下のように固有のIDをcookieに保存します。 session[:remember_token] =
RailsのCookieStoreの脆弱性について
RailsのCookieStoreの脆弱性についていくつか報告記事が出ていたので、内容を検討してみました。 Ruby on Railsにcookie保存関連の脆弱性、2000サイトで放置状態 http://www.itmedia.co.jp/enterprise/articles/1311/27/news041.html Rails SessionにCookieStore使った時の問題点 http://oauth.jp/blog/2013/09/26/rails-session-cookie/ 読み合わせていくと、以下のような問題があるようです。 -Cookieの情報が抜かれることによって、セッションをハイジャックされる可能性がある --Rails 2系にはXSS脆弱性からCookieの情報が抜かれる可能性がある --Rails 3/4系でもCookieが盗聴される場合は危険 -セッション
Ruby on Rails4のSessionをJSON形式にした時にハマったこと
HOMEchevron_right技術chevron_rightRuby on Rails4のSessionをJSON形式にした時にハマったこと 状況 Ruby on RailsとNode.jsでセッションデータを共有したい状況がありました。 Session StoreにはRedisを使っています。 普通に考えると、クッキーからセッションID取って当てに行けばいけるだろうと考えるのですが、Railsは一筋縄ではいきません。 中身覗くとすぐ分かるんですが、セッションデータ自体がMarshalでシリアライズされた状態で保持されている為。 Node側でデータとってもJSONでパースできないし、なんだこりゃ？となります。 さてどうするか、となった時に参考にさせていただいた記事がこちら(感謝)↓ Rails sessionのシリアライズにJSONが使われない理由: なぜMarshal? JSON/Y
アプリケーション・サーバのセッションの保存先の話 - プログラマでありたい
Webシステムの方式設計をする際に、わりと悩むのがアプリケーション・サーバのセッション（session）の保存先です。アプリケーションサーバとは、TomcatやJBoss,IISやRuby on Railsなどで利用するUnicornやPassengerなどです。そもそもHTTPの基本仕様がステートレスな為、状態を保持する為にはどこかに状態を保持する必要があります。その解決策がセッションになります。そこでセッションの保存戦略を考える必要があるのですが、アプリケーションサーバやサイトの用途や性格、扱うデータの気密性・重要性によっても変わってきます。 それ以前にセッションの保存先のことの呼び方の定番が何かすら解らなかったりします。セッション・ストアとかセッション・ストレージとか、はたまたセッション・マネージャーとか。今回は、セッション・ストアで統一します。 主なセッションストアの種類と保存戦略
Rails で、Controller に定義されている action を一度に取得する方法はありますか？ - QA@IT
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
Railsのセッションの仕組みと使い方(session[:hoge]) Ruby on Rails Pro
次のページ カテゴリへ戻る Railsのセッションの仕組みと使い方(session[:hoge]) 更新日 2009/07/17 作成日 2008/07/17 セッションとは、サーバーがリクエストしてきた相手を特定する為の技術です。Webサイトには複数の人がアクセスしてきます。 ショッピングサイトでは商品を買い物かごに入れたのが誰なのか管理できている必要があります。ログインが必要なサイトでは、すでにユーザーID、PASSが正しく入力されログインされているユーザーなのか判断できる必要があります。 このようなサイトではセッションを使い管理します。 セッションの仕組みを簡単に説明します。サーバー側がセッションを開始するプログラミングをすると、ユニークなIDがサーバー側に記憶され、同時に同じIDでクライアント側に返されます。このIDはその後の同サイトのリクエストに必ず送信されるようになり、
【連載】Railsとnode.jsを繋ぐ認証 作戦編 -cookie sessionのおさらい-
ガリレオスコープ開発チームによる �最新Web動向、技術メモ ( Ruby, Rails, node.js ) です 最近、我々の開発はrubyのRailsだけでなくてcoffeescriptでのnode.jsでの開発のウェイトも高くなってきています。 そこで、Rubyとnode.jsを繋ぐ上での問題になった箇所をまとめて、今後同じような問題に当たる人へのメモにしようと思います。 まず始めに、認証編ということで、全3回でまとめます。 認証編の第一回目はcookie sessionのおさらいと作戦立てです。 cookie sessionのメリット まずは、cookie sessionのおさらいをしながらメリットを。 Railsでは2.0からcookie sessionを標準にしています。 cookie sessionの良い点は、 1. スケールアウトしやすい2. session管理の簡便さ3
セッションの意味とRailsでのセッションの使い方：プログラミングの基礎知識 - 久保清隆のブログ
セッションとは セッションとは、サイトに訪問してから離脱(＝セッションが切れる)するまでの一連の行動のこと。 ここでいう「行動」とは、サイトを訪問してから離脱するまでのサイト内のページの閲覧や遷移などを指す。 セッションの使い方（Rails） セッションを使うと、ユーザーが画面遷移してもユーザー特有の情報を失わないようにできる。 現在のセッション情報を得る →sessionメソッドを使う session #=> #<CGI::Session:0x40a1df48... セッションIDを取得する →session_idメソッドを使う session.session_id #=> "f1174c1766ejifjojpsjifjojgbiojsj" セッションにデータを保存する session[:user_id] = @user.id違うページでユーザーデータを取得するには、 @user =
Session IDの作り方 - 放牧日記
どんな風に作ったりするのか疑問だったのでちょっと調べた。 Kahuaの場合 Kahua-1.0.7.3/src/kahua/session.scm Sessionクラス()を取り扱うファイル Kahua-1.0.7.3/src/kahua/gsid.scm SessionIDを取り扱うファイル 継続サーバということで、継続のためのContinuation ID、通常のSession IDとして使うState IDの二つのIDを利用するらしい。Continuation IDは再利用するらしい。 gsid.scm 46行 グローバルセッションの形 (define (make-gsid worker-id body) (format "1-~a-~a" worker-id body)) こんな感じで、1はバージョン、bodyにはContinuation IDもしくはState IDが入るらしい。
RamazeさんのセッションIDの作り方 - ¬¬日常日記
2008-07-05 という記事を読みました。Kahua, Rails, Ethna の各フレームワークのセッションIDの作り方が大変良くまとまっていて、素晴らしいと思いました。でもこれを読んで「そういえば！」と思い出したのは Ramaze さんのセッションIDの作り方です。前に読んだ時にも気になったんですが、現在のところ次のようになっています(ramaze/current/session.rb)。 def self.random_key h = [ Time.now.to_f.to_s, rand, Current.request.hash, rand, Process.pid, rand, object_id, rand ].join Digest::SHA256.hexdigest(h) end つまり、現在の時間、乱数、現在のリクエストのハッシュ値、乱数、PID、乱数、クラス Ra
ramazeをCGIで使うときもセッションを使う(helper編) - NAT’s Programming Champloo
ramazeをCGIで使うときもセッションを使う - NAT’s Programming Champloo 上記エントリで、セッションをファイルに格納するモジュールFileSessionManagerを作りました。その続きです。 ramazeなら、FileSessionManagerみたいなモジュールはhelperにした方が良いよ、とコメント頂いたので、自分用helperにしてみました。自分用helper(custom helper)の作り方は、教えて頂いた、下記のページを参考にしました。 http://ramaze.net/features:helpers#custom-helpers セッションを管理するhelperのコードはこんな感じ。モジュールをRamze::Helperの中で定義します。 require 'ramaze/store/default' module Ramaze m
Rack でセッションを使う
Rack を使って Web サーバで統一されたインターフェイスの利用する http://d.hatena.ne.jp/secondlife/20070307/1173253661 Rack：a Ruby Webserver Interface http://rack.rubyforge.org/ Rack を使えば生 Ruby で WEBrick や Mongrel や FastCGI やいろいろあっても統一したインターフェースで書けるよ！ デバッグの時は WEBrick の方が挙動が落ち着いてるしスタックトレースも見やすいし。 でも本番はやっぱりせめて Mongrel か、ちょっと面倒だけど FastCGI がええな〜。 と啓蒙されたので最近 Rack を使い始めたんだが、ドキュメントがまるっきりない…… とりあえずセッションを使いたくて、Rack::Session::Cookie とい
SinatraのSessionには注意 - GIOの日記
SinatraでSessionはこんな風に使えます enable :sessions get '/foo' do session[:message] = 'Hello World!' redirect '/bar' end get '/bar' do session[:message] end SinatraではRackのCookieSessionをつかってるのですが、secretキーを指定していないため、MarshalしてBase64するだけのデータをクッキーに乗せてきます。 このままじゃ書き換えられて大変な事になるので、デフォルトのsessionは有効にせずに、RackのSessionをsecretキーを指定して使うべきではないだろうか。secretキーを指定した場合は、データとdigestをクッキーに乗せてくるので書き換えが検出できます。 use Rack::Session::Coo
2.0のcookie session storeを体感する - ザリガニが見ていた...。
Rails2.0の変更点で、セッション(session)データの保存先がクッキー(cookie)になったということを、よく目にする。確認してみると、確かに以前はtmp/sessionsフォルダの中に常にセッションファイルがあり、増え続けていたが、2.0環境にしてからはいつも空っぽだ。そうなると、本当にクッキーに保存されているのか？どのように保存されているのか？実際に覗いてみたくなった...。 クッキーを確認する MacOS X版のFirefox2.0のクッキーは、Firefoxの環境設定 >> プライバシー タブ >> Cookieを表示 ボタン、で表示される。 想像以上のクッキーの多さに驚く。一つずつ見ていてはキリが無いので、検索で「localhast」と入力してみる。 すると一気に絞り込まれ、Cookie名から「_test_slip202_session」が求めるクッキーだと予想できる
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.k-brand.gr.jp/log/001205