httpOnlyなCookieとは？ - それマグで！
Webkitの要素の検証でCookieをいじっていると、見慣れないカラムに気づきました。気になったので調べました。 HTTP というカラムにチェックボックスが入っています。 ブラウザの要素の検証でCookieを見ると、左から name , value, domain , path, expires , size ,http , secure と並んでいます。 (cookie) expires は期限 path/domain はオリジンの指定 secure は HTTPSだけで使われるCookie 、 http は？ secure の逆？？だとすると secure / http の両方のチェックが説明できないし、わざわざカラムにして表示しない。 だとすると、なんなのか？ http のチェックはなにか？ HTTP 通信ヘッダのみで使われるCookieという意味になります。 わかりやすくいえば
P3Pコンパクトポリシーをコピペするのが流行らないことを祈る | 水無月ばけらのえび日記
なにげにしらなかったんだけど、IEで別ドメインのiframeを読み込むと、そのiframe内のcookieが有効にならない。 そーゆーときは、HTTPのリクエスト時のヘッダーに下記のkey＆valueを出力しておけばOKらしい。 ("P3P", 'CP="CAO PSA OUR"') こーするだけで、あらふしぎ。IEがCookieを保存してくれるじゃん。 ……。 iframeで別ドメインのコンテンツを読み込むと、そのCookieはサードパーティーのCookieとなります。IEのデフォルトでは、ポリシーが定義されていないサードパーティーのCookieは受け入れないようになっていて、P3P (www.w3.org)でポリシーを宣言すれば受け入れられるようになります。 P3Pのポリシーを定義するには、がっつりとXMLを用意する方法もありますが、HTTP応答ヘッダの中に直接書くという方法もあり、コ
クッキーのSecureフラグはリバースプロキシに立てさせたい - Qiita
HTTPクッキーで秘密情報、例えばログインセッションIDなどを扱う場合はSecureフラグを立てるのが定石です（例え秘密情報を扱わないとしても立てるのが定石と考えるべきかもしれません。セキュリティテストでは機械的に問題点として検出されてしまいますから）。 Secureフラグとは「HTTPS通信時にしか送り返さないでください」というブラウザへの指示。 などと、Set-Cookieヘッダにsecureと追記することで実現します。こうしておけば、平文通信に秘密情報が流れてパケットキャプチャで盗聴されてしまうという心配がなくなります。 開発時にはsecureフラグが邪魔だったり というわけでまともなユーザアカウント管理のあるWebシステムならsecureフラグは当然付けなければいけないのですが、問題は開発中です。 開発マシンのローカルにサーバを立てて動かしているときなど、HTTPSアクセスってこと
CSRF 対策用トークンの値にセッション ID そのものを使ってもいい時代は終わりつつある - co3k.org
CSRF 脆弱性対策には攻撃者の知り得ない秘密情報をリクエストに対して要求すればよく、そのような用途としてはセッション ID がお手軽でいいよねという時代があったかと思います。 いや、もちろん、 CSRF 対策の文脈だけで言えば今も昔も間違いというわけではありません。セッション ID が秘密情報であるのは Web アプリケーションにおいて当然の前提ですので、 CSRF 対策としてリクエストに求めるべきパラメータとしての条件はたしかに満たしています。 たとえば 『安全なウェブサイトの作り方』 改訂第6版では以下のように解説されています。 6-(i)-a. (中略) その「hidden パラメータ」に秘密情報が挿入されるよう、前のページを自動生成して、実行ページではその値が正しい場合のみ処理を実行する。 (中略) この秘密情報は、セッション管理に使用しているセッション ID を用いる方法の他、
Released Cookie::Baker to CPAN - Hateburo: kazeburo hatenablog
I released Cookie::Baker that provides HTTP cookie generator and parser http://search.cpan.org/~kazeburo/Cookie-Baker/ https://metacpan.org/release/Cookie-Baker ### synopsis use Cookie::Baker; $headers->push_header('Set-Cookie', bake_cookie('foo','val')); my $cookie = bake_cookie('foo', { val => 'val', path => "test", domain => '.example.com', expires => '+24h' }); my $cookies_hashref = crush_cook
Firefoxの新ポリシー サードパーティcookieをデフォルトで遮断へ
Firefox 22から導入される新ポリシーでは、ユーザーが閲覧したことのないサードパーティーのcookieを遮断する。 Mozillaはユーザーのプライバシー保護の一環として、Webブラウザ「Firefox」の今後のバージョンに、サードパーティーのcookieをデフォルトで遮断する新ポリシーを採用する。Firefoxの開発に携わる米スタンフォード大学のジョナサン・メイヤー氏が2月22日のブログで明らかにした。 cookieは広告業者などがユーザーの行動を追跡するために使っているプログラム。Firefox 22から導入される新ポリシーでは、ユーザーが実際に閲覧している「ファーストパーティー」のWebサイトのcookieは引き続き許可する一方で、ユーザーが閲覧したことのない「サードパーティー」のcookieは遮断する。 メイヤー氏によれば、競合するWebブラウザではGoogleのChrome
Access-Control-Allow-Origin試してみた。その２ - ミルク色の手紙
前回めでたくクロスドメインからレスポンスもらえるようになったけど、Cookieが送れなかった件。 参考をよーく見直してみたら、なんかCookieセットできそうな文章を発見。で、再度お試し。 RPC側を次のように修正。Access-Control-Allow-Credentialsヘッダーを追加する。 <?php header('Access-Control-Allow-Origin:http://localhost'); header('Access-Control-Allow-Credentials:true'); header('Content-Type:text/plain;charset=UTF-8'); $msg = ' World'; if(isset($_COOKIE['_test_'])) { $msg = ' Again'; } else { setcookie('_te
[セキュリティ]httponlyは普及するのか (2006-12-26 - T.Teradaの日記)
Firefox2でもhttponlyが使えるという話を耳にしました。 httpOnly - Firefox Add-ons*1 httponlyがいよいよ普及するか？ というのでネタにしてみます。 なお、この日記は、WinXP＋IE6SP2環境を前提として書きました。 はじめに httponlyは、XSS脆弱性がある状況においても、cookieを窃取されないようにすることを狙ったIEの独自機能です。 MSDN - Mitigating Cross-site Scripting With HTTP-only Cookies この機能を有効にするためには、発行するcookieにhttponly属性を付けます。 Set-Cookie: key=value; domain=example.com; HttpOnly httponly属性が付けられたcookieは、JavaScriptのdocume
![[セキュリティ]httponlyは普及するのか (2006-12-26 - T.Teradaの日記)](https://cdn-ak-scissors.b.st-hatena.com/image/square/e8a0aea5d375a69b5b38062b6dbabb4cf556055e/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F10257846132711010800%2F10257846132711097230%2F1548045809)
サードパーティCookieの歴史と現状 Part1 前提知識の共有 - 最速転職研究会
Web開発者のためのサードパーティCookieやらトラッキングやらの問題点について三回ぐらいに分けて書きます。 この文章は個人的に書いていますので、おい、お前のところのサービスがサードパーティCookieに依存してるじゃねーかというツッコミがあるかもしれないが、そういうことを気にしているといつまで経っても公開できないという問題が出てしまうので、そんなことはお構いなしに書く。ちなみに例外なく自社サービスに対してもサードパーティCookieに依存するな死ねと言っている。これはWebプログラマー観点で、自分がサービス開発に関わる上で知っておかねばならないだろう知識として十数年間だらだらとWebを見ていて自然に知っていたものと、あるいは興味を持って率先して調べたものが含まれている。ググッて直ぐに分かる程度の用語の定義的なことは書かない。あくまでWebサイト制作者側からの観点なので、ブラウザ開発関係
SWFUpload の Cookie バグに悩まされました
とある案件でファイルのアップローダー機能を作ることになりました。まぁ何も考えずにやるならば、こんな感じ。 でも今回の要件はコレではダメなのです。 アップロード時にページ遷移はさせたくない ファイルサイズが大きなファイルをアップロードするので、プログレスバーを表示して進捗表示したい 認証済みのユーザだけアップロード機能を使わせたい とすると Ajax か Flash だなぁ〜と思って探してみました。よく考えたらプログレスバーを表示するためには、事前にファイルサイズを知る必要があります。とすると JavaScript ではローカルのファイルサイズを取得できないので Flash 実装のライブラリを探すのが良さそうです。 いろいろ検証してみた結果 SWFUpload が一番よさげです。コレ結構有名なライブラリですよね。でもどうにも既存のシステムと認証部分でうまくいきませんでした。既存システムの認証
cookieのサイズはパフォーマンスに影響を与えるか - bits and bytes
私は "回線が早くなった現在、データの転送よりもコネクションの確立にかかるオーバーヘッドの方が大きい" という根拠のない信念を持っています。 だから、今ではバイト数を節約するよりも、Vitamin Features » Serving JavaScript Fast のような方法でコネクションを抑えることのほうが速度的には効果があるだろう、考えていました。 そんなところに おぎろぐはてな - Cookieがパフォーマンスに与える影響 経由で Performance Research, Part 3: When the Cookie Crumbles » Yahoo! User Interface Blog に、クッキー500バイトでレスポンスを15ms改善できるという記事を見つけて、単純に500バイトを15msで割ったら300Kbps程度で日本じゃあり得ない遅さですが、小さいファイルの場
Cookieがパフォーマンスに与える影響 - おぎろぐはてブロ
Yahoo!のYUI Blogで、"Performance Research, Part 3: When the Cookie Crumbles"という記事で、Cookieがレスポンスに与える影響が説明されています。 Cookieのサイズと、それによるレスポンスタイムの変化の表とか興味深い。 まとめの適当な訳。 不要なCookieを排除する cookieのサイズを可能な限り小さくする 適切なドメインレベルで発行し、不必要に他のサブドメインに影響を与えないようにする 適切な有効期限を設定する。 実サイトのCookieサイズの分析 記事の方では、トップページにアクセスしたときの各サイトで発行されるCookieのサイズの表が示されています。 でも、それってちょっと、やほーの都合のいいような条件にしてないか？ということで、普段使って、Cookieが蓄積されている状態でのCookieのサイズを調べて
ユーザーが制御できない「秘密cookie」、半数強のサイトが利用
米研究チームの発表によると、Adobe Flashを使ってネット上のユーザーの行動をひそかに追跡し続けるサイトが増えているという。 Adobe Flashを使ってネット上のユーザーの行動を追跡し続ける「秘密cookie」を利用するサイトが増えているという。米カリフォルニア大学バークリー校などの研究チームがこのほど論文を発表した。 「Flash cookie」は通常のcookieとは異なり、ブラウザのセキュリティ設定ではコントロールできないという。研究チームが大手サイトによる同cookieの利用実態について調べたところ、調査対象としたサイトの半数以上がFlash cookieを使ってユーザー情報を保存していることが判明した。 中にはユーザーが削除したHTTP cookieを、Flash cookieを使って復活させているケースもあった。しかしその存在についてはサイトのプライバシーポリシーでも
そろそろクリックジャッキングについて一言いっておくか - 最速転職研究会
Firefox3で「サードパーティのCookieも保存する」をオフにする。 防げる。 いずれのブラウザにもサードパーティ製のcookieを制限するオプションがあるが、Firefox3以外だと、フレーム内表示された場合に「新規にcookieを保存しない」だけで保存済みのcookieは送信してしまう。 軽く調べてみたところ、次のようになった。(間違ってたら教えてください) サードパーティのcookieの新規保存 サードパーティの保存済みcookieの送信 表示中のドメインのcookieの保存/送信 IE6,7,8(デフォルト) x o o IE6,7,8(セキュリティ高) x x x Opera9.6(デフォルト) o o o Opera9.6(制限) x △ o Safari(制限/デフォルト) x o o Safari(全て受け入れる) o o o Firefox2(デフォルト) o o
Apache TomcatとHTTPクッキーにまつわる騒動 - GeekFactory
Apache Tomcat 5.5.26（6.0.16も同じ）で、HTTPクッキーの取り扱いについて大きな仕様変更が行われました。ここでは仕様変更の内容と影響範囲を考察します。 HTTPクッキー 簡単に復習しましょう。WebブラウザがWebサーバから以下のHTTPヘッダを受信したとき、Webブラウザは test というクッキーを記憶します。 Set-Cookie: test=nullpo; Expires=Wed, 08-Oct-2008 14:03:16 GMT; Path=/クッキーは NAME=VALUE という形で表現されます。連想配列と同じ。 NAME VALUE test nullpo 一度クッキーを受信すると、ブラウザは当該URLにアクセスする度に、以下のHTTPヘッダを送信するようになります。 Cookie: test=nullpoこのように、クッキーはWebサーバがブラウ
Cookieの内容で認可を行うApacheモジュール - Webと何かとその近所
調べ事をしていたらmod_auth_hmacと似た事が実現できるモジュール(リリースはmod_auth_hmacよりずっと前!)をたまたま見つけたので、これはひとつまとめておかねばと思い、Cookieの内容で認可を行うApacheモジュールを探してまとめてみた。 そのつもりは無かったのに、なぜか開発者は日本人が多いような。 mod_auth_cookie Apache 1.3.x / 2.0.x ライセンス: Apache Software License(?) Basic認証でのWWW-Authenticateフィールドの内容をCookieに移すものらしい 配布元が見つからない mod_auth_cookie_fu Apache 2.0.x ライセンス: MIT モジュールは認可のみ行う mod_auth_hmacより高機能 mod_auth_form Apache 1.3.x ライセン
Apache のみで Cookie によるアクセス制御をかける - WebOS Goodies
WebOS Goodies へようこそ！ WebOS はインターネットの未来形。あらゆる Web サイトが繋がり、共有し、協力して創り上げる、ひとつの巨大な情報システムです。そこでは、あらゆる情報がネットワーク上に蓄積され、我々はいつでも、どこからでも、多彩なデバイスを使ってそれらにアクセスできます。 WebOS Goodies は、さまざまな情報提供やツール開発を通して、そんな世界の実現に少しでも貢献するべく活動していきます。 自分専用のサーバーに Apache をインストールする目的のひとつに、自分専用の Web サイトを構築したい、というのがあるのではないでしょうか。最近は XOOPS や TikiWiki、各種 blog など、個人でも手軽に使える CMS が多く開発されていますので、簡単に自分専用のポータルサイトを構築できます。また、よく使う資料などをどこからでもアクセスできるよ
apache の mod_auth_cookie, mod_ticket モジュール
Landscape トップページ | < 前の日 2003-08-21 2003-08-22 次の日 2003-08-26 > Landscape - エンジニアのメモ 2003-08-22 apache の mod_auth_cookie, mod_ticket モジュール 当サイト内を Google 検索できます * apache の mod_auth_cookie, mod_ticket モジュールこの記事の直リンクURL: Permlink | この記事が属するカテゴリ: [Apache] mod_auth_cookie、mod_ticket のどちらも apache のモジュール。apache レベルで 特定のトークンを持っているかどうかをチェックし、アクセスの可否を決定できるようにする。 ライブラリ側にあるとうれしい機能だな。以前作ったサイトは、これで置き換えられるかもしれない
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CSRF対策用トークンの値にセッションIDそのものを使ってもいい時代なんて、そもそも無かった
Cookie::XS