Cookie の性質を利用した攻撃と Same Site Cookie の効果 | blog.jxck.io
Intro Cookie はブラウザによって保存され、紐づいたドメインへのリクエストに自動で付与される。 この挙動によって Web におけるセッション管理が実現されている一方、これを悪用した攻撃方法として、 CSRF や Timing Attack などが数多く知られており、個別に対策がなされてきた。 現在、提案実装されている SameSite Cookie は、そもそもの Cookie の挙動を変更し、こうした問題を根本的に解決すると期待されている。 Cookie の挙動とそれを用いた攻撃、そして Same Site Cookie について解説する。 Cookie の挙動 Cookie は、 Set-Cookie によって提供したドメインと紐づけてブラウザに保存され、同じドメインへのリクエストに自動的に付与される。 最も使われる場面は、ユーザの識別子となるランダムな値を SessionI
websec-room.com - websec room リソースおよび情報
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
高木浩光＠自宅の日記 - 共用SSLサーバの危険性が理解されていない
■ 共用SSLサーバの危険性が理解されていない さくらインターネットの公式FAQに次の記述があるのに気づいた。 [000735]共有SSLの利用を考えていますが、注意すべき事項はありますか？, さくらインターネット よくある質問（FAQ）, 2010年2月10日更新（初出日不明） Cookieは、パスなどを指定することができるため、初期ドメイン以外では共有SSLを利用している場合にCookieのパスを正しく指定しないと、同じサーバの他ユーザに盗まれる可能性があります。 （略） 上記については、「同サーバを利用しているユーザだけがCookieをのぞき見ることができる」というごく限定的な影響を示していています。また、Cookieの取扱いについて、問い合わせフォームやショッピングカート等、ビジネス向けのウェブコンテンツを設置されていなければ特に大きな問題とはなりませんが、個人情報を取り扱われる管
HTTPSを使ってもCookieの改変は防げないことを実験で試してみた
寺田さんのブログエントリ「他人のCookieを操作する」には、通信路上の攻撃者がいる場合は、SSLを使っても、Cookieの盗聴を防ぐことはできるが、Cookieの改変を防ぐことはできないと指摘されています。いかにも寺田さんらしい簡にして要を得たエントリで、これに付け加えることはあまりないのですが、残念ながらまだ読んでいない人が多そうだと言うことと、より広い読者に向けて具体的に説明した方がよいだろうと考えました。 そこで、通信路上に攻撃者がいる典型例として、公衆無線LANの偽AP（アクセスポイント）があるケースを題材として、「HTTPSを使ってもCookieの改変は防げない」ことを説明します（Secure属性使うと盗聴は防げますが、改変は防げません）。長いエントリなので結論を先に書いておきます。 Secure属性がないCookieはHTTPSでも盗聴できる Cookieの改変についてはSe
rails3 + deviseにてCookieをsecureにする | ダークフレイムブログ
環境： Rails 3.2.11 devise 2.2.3 rails/deviseの初期設定ではcookieはsecure設定ではありません。secure設定でないと、ログイン処理等でhttpsにより暗号化したcookieの送受信を行っていても、同一サイト内のhttpページでは暗号化せずにそのcookieを送信してしまいます。また、サイト全体がhttpsの場合でも不測の事態に備えてsecure設定にしておいたほうが無難です。 ・【rails】 _session_idをsecureにする config/initializers/session_store.rb にて次を追加: Yourproj::Application.config.session_store :cookie_store, :secure => true (Yourprojは各位のプロジェクト名に合わせて下さい) ・【
クッキーをセキュアにする〜Session FixationとかSession Hijackとか〜 - 雑雑草々
こんにちは。 クッキーをセキュアにする必要が出てきたため、色々探したんですがなかなか情報が発見できませんでした。結局、人の助けを借りて見つけたので記載します。（Railsのリファレンスには記載あったと思います。。。） まず、用語の説明。 Session Fixation アプリケーションが生成したセッションIDを盗むことができないなら攻撃者自身が生成したセッションIDをクライアントに使わせてしまおう、という攻撃。 セッション・ハイジャック（session hijack） 他人が確立したTCPの通信路を横取りする行為。 ほかのユーザーのセッションIDやセッション・クッキー（セッション管理に使用しているクッキー）を盗むことで、別のコンピュータからそのユーザーになりすました アクセスが行える危険性がある。例えば、セッション・クッキーが類推可能な簡単なものであったり、セキュアでない通信経路で送られ
Androidの標準Webブラウザでセキュア属性付きのCookieの扱いがPCやiPhoneと異なる件について - susumuis Info
Android用のWebサイトを作っていてはまったので、報告します。対象はブラウザ上で動くWebアプリの話で、ネイティブアプリではありません。 Googleで検索しても、ネイティブアプリ関連の情報は出てきますがWeb開発の情報が意外とすくなかったので、少しでもお役に立てれば幸いです。 概要 Android標準ブラウザ（Dolphinブラウザなども含む）で、セキュア属性付きのCookieの挙動がiPhoneのブラウザや、PCのChromeなどと異なります。 Cookieやセキュア属性の概要はこちらなどをご参照ください。http://itpro.nikkeibp.co.jp/article/COLUMN/20080221/294407/ PCやiPhoneのブラウザの場合、WebサーバがSet-Cookieレスポンスヘッダを返した場合、例え、そのCookieのセキュア属性が設定されていても、ブ
プライバシー保護に。トラッキング系サービスのCookieを自動削除·Autodistract MOONGIFT
Autodistractはトラッキング系サービスのCookieだけを削除するソフトウェア。 AutodistractはMac OSX/Safari向けのフリーウェア（ソースコードは公開されている）。今ではログインを行うWebシステムが当たり前になっており、Cookieを敢えてオフに設定している人は少なくなっている。また、サードパーティーのCookieもデフォルトでオンになっており、オフに設定している人は少ないだろう。 初回実行時のGrowl サードパーティー製Cookieとしてよく使われているのが広告の行動追跡システムだ。テクノロジー系ブログを見ている人に対して、別なサイトにいった時にも類推される広告を出すことで費用対効果を高める。そんなシステムを忌み嫌う人が使ってみたいのがAutodistractだ。 AutodistractはいわゆるCookie削除ツールだ。しかし全てのCookieで
Rails 2系すべてのブランチに脆弱性、Ruby 1.9ユーザはアップグレード注意 | エンタープライズ | マイコミジャーナル
Ruby on Rails 4日(米国時間)、Ruby on Railsの2系すべてのバージョンにXSSの脆弱性があることがRiding Rails: XSS Vulnerability in Ruby on Railsにおいて発表された。特定のUnicode文字列を使ってチェックをくぐり抜け、任意のHTMLを送り込まれる危険性がある。なおRuby 1.9系で動作しているアプリケーションはこの影響を受けない。それぞれのバージョンに対するパッチは次のとおり。 2-0-CVE-2009-3009.patch - Patch for 2.0 series 2-1-CVE-2009-3009.patch - Patch for 2.1 series 2-2-CVE-2009-3009.patch - Patch for 2.2 series 2-3-CVE-2009-3009.patch - Pa
はてなブログ | 無料ブログを作成しよう
来年も作りたい！ふきのとう料理を満喫した 2024年春の記録 春は自炊が楽しい季節 1年の中で最も自炊が楽しい季節は春だと思う。スーパーの棚にやわらかな色合いの野菜が並ぶと自然とこころが弾む。 中でもときめくのは山菜だ。早いと2月下旬ごろから並び始めるそれは、タラの芽、ふきのとうと続き、桜の頃にはうるい、ウド、こ…
railsのクッキーとセッションについてまとめ - おもしろwebサービス開発日記
こないだ、よくわからんので今度調べると書いたところについて。 CSRFの対応について、rails使いが知っておくべきこと - おもしろWEBサービス開発日記 まずクッキーとセッションの違いから。自分の認識はこんな感じ クッキーもセッションも、ブラウザにデータを保存させる仕組み。 クッキーはデータをそのままブラウザに保存させる。 セッションはセッションIDをブラウザに保存させ、データはサーバ側が保持する。サーバはセッションIDをキーにしてデータを取り出す。 railsでクッキーを設定するには railsでは、クッキーは基本的に使わないと思ってますが、一応使い方をメモ。 cookies[:hoge] = { :value => "value", :expires => "30.days.from_now", :path => "/store", :domain => "www.example.
CookieStoreとセキュリティ(2), CookieStoreの有効期限, Ruby on Rails の注文の多い料理店に入ってしまった話 - Journal InTime(2008-01-14)
_ CookieStoreとセキュリティ(2) ちょっと気になるのが、サーバが一度発行したクッキーは、HMACで使用する鍵を変えたりしない限り、ずっと有効だということだ。悪意のある第三者がクッキーを盗聴してリプレイを試みる、というケースについては、盗聴できたという時点で他のセッションストアの場合もセッションハイジャックが可能になるので、CookieStoreがとりわけ危険だというわけではない。気になるのは、ユーザがセッションの状態を任意の時点に戻すことができる点だ。アプリケーションの作りによっては悪さができそうな気もするのだけれど、実際のところどうなのだろう。 [Cookieとセキュリティより引用] と書いたけど、問題になりそうな具体例を思い付いた。 RailsによるアジャイルWebアプリケーション開発 のサンプルのショッピングカートアプリケーションでは、カートの格納先にセッションを使用し
CookieStoreとセキュリティ, RailsによるアジャイルWebアプリーション開発第2版とRails 2.0 - Journal InTime(2008-01-13)
_ CookieStoreとセキュリティ Rails 2.0ではCookieStoreという新しいセッションストアが導入されている。 CookieStoreは、セッションデータをサーバ上のファイルやDBに保存する代りに、クッキー自体に保存する。 このため、セッションデータの読み書きのコストが減ったり、古いセッションデータ の掃除の手間がなくなる、という利点がある。 「そんなことをしたらユーザにセッションデータを改竄されるじゃないか」というのが 当然の疑問だが、HMAC(デフォルトではSHA1)によるチェックで改竄を防ぐようになっ ている。 ただし、セッションデータ自体は平文(marshal+base64)なので、中身を見られてしま う。これについては、そもそもユーザに見られては困るようなデータをセッションデ ータに格納すべきではない、という立場を取っているようだ。 ちょっと気になるのが、サ
Immortal Session の恐怖 : 404 Blog Not Found
2007年11月29日07:15 カテゴリ書評/画評/品評 Immortal Session の恐怖 さすがの私も、今夜半の祭りにはmaitter。 私のtwitterが荒らされていたのだ。 荒らし発言は消してしまったが、にぽたんがlogを残してくれている。 nipotumblr - Dan the cracked man 一部で言われているように、本当にパスワードが抜かれたかどうかまでは解らない。が、状況としてはnowaがベータテスト段階で持っていたCSRF脆弱性をついた荒らしにそっくりだった。 にぽたん無料案内所 - こんにちはこんにちは！！ この時も、私のnowaのメッセージに荒らしが入った。パスワードを変更しても暫く荒らしが続いていた点も似ている。 ここでの問題は、 bulkneets@twitter曰く(直接リンクは避けます) 問題は本人が気付いてもパスワード変えてもセッション残
2007-12-11
ソースつき解説。有難いです。 セッションデータがファイルからクッキーに行くことによるメリットは多々あります。 一番大きいところでは、アプリケーションサーバの分割（つまりスケール）が容易になること。 あとは公式ブログの2.0機能ダイジェストにもあるように、軽くなる、メンテが簡単になるなど。 *1 でもセキュリティはやっぱり心配。digestは改竄防止にはなるけれど、データの中身が覗かれたり、secret(digestの鍵）を計算されてしまうリスクは増えています。 対策として考えられるのは、以下でしょうか。列挙してみると基本的なことばかりなのですが。 cookieにはsecureオプション dataには漏洩してはまずい情報はなるべく保存しない ↑と関連してCSRF対策は念入りに secretを十分長くとることや、定期的更新など なんか勘違いとか漏れとかあったらご指摘お願いします。 *1:携帯端
FunctionalテストでCookieを使う方法 - Hello, world! - s21g
This article was migrated from http://rails.office.drecom.jp/takiuchi/archive/101 Ruby on Railsでは、コントローラの挙動をテストするためにFunctionalテストという仕組みがあります。 実際にページを取得し、レンダリング結果のタグを解析したり、リダイレクト先が正しいかどうか、指定したIDのタグが出力されているかどうか、などなど、様々なテストを行う事ができます。 そこで、ログインした状態でないとアクセスできないようなページのテストを記述するために、Cookieやセッションを使ってテストを記述する必要が出てきます。しかし、こちら（Rails - Functional Test with Cookie）で報告されているように、FunctionalテストでCookieを使用する方法には若干癖があり、ド
Ruby On Rails ピチカート街道 - [2.0]セッション＆クッキー -
XSS クロス・サイト・スクリプティングで問題として真っ先に上げられそうな、cookie の値を javascript で取ってくる、ということが出来ないクッキーのことです。 それを http only cookie と言ったりしますが、その設定が出来るようになりました。 options = { "name" => "quality", "value" => "owesome", "http_only" => true } cookie = CGI::Cookie.new(options) http only クッキーとはなんぞや、の方は、 T.Teradaの日記や Mitigating Cross-site Scripting With HTTP-only Cookiesがお勧めです。 【広告】 CSRF (Cross-Site Request Forgery) を勝手に防止してください
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Secure Cookie Flag Control | OWASP Foundation
徳丸浩の日記
http://www.machu.jp/posts/20080101/p01/