CloudFrontで「Forward Cookies」を「All」にしている時に注意すべき点 | DevelopersIO
菅野です。 先日、CloudFront経由でウェブページにアクセスした時に常に「X-Cache: Miss from cloudfront」となるので調査したところ、CloudFrontの「Behavior」の「Forward Cookies」が「All」になっている事が原因でした。 今回はなぜ「All」だとキャッシュが使われなかったのか、CloudFrontにおけるcookieの注意点について書こうと思います。 webページを準備 EC2インスタンスを立ち上げ、apacheとphpをインストールします。 /var/www/html/index.phpを作成し、内容は以下にします。 GoogleAnalyticsもcookieを使うので検証の為に埋めました。 <?php setcookie( "cookie01", "value01" ); // setcookie( "cookie02"
IEのクッキーモンスターバグはWindows 10で解消されていた
エグゼクティブサマリ IEのクッキーモンスターバグはWindows 10では解消されているが、Windows 7とWindows 8.1では解消されていない。このため、地域型JPドメイン名と都道府県型JPドメイン名上のサイトは、クッキーが外部から書き換えられるリスクが現実的に存在しするので、セキュリティ対策上もクッキー書き換えのリスクを考慮しておく必要がある。 クッキーが外部から変更された際のリスク ウェブサイトの利用者が第三者によりクッキーの値を変更されると、以下のような攻撃が可能になります。 セッションIDの固定化攻撃（脆弱性がある場合） クッキーを攻撃経路とするクロスサイトスクリプティング攻撃（脆弱性がある場合） 一部のCSRF対策の回避 「一部のCSRF対策」と書いたのは、OWASPの資料ではDouble Submit Cookieと呼ばれるもので、乱数値をクッキーとリクエストパラ
PHPのsetcookie関数で空文字列を設定しようとするとクッキーが削除される
PHPでスクリプトを書いていて、setcookieの第2パラメータ(クッキーの値)の変数をタイプミスしたところ、以下のレスポンスヘッダが送信されていました。 setcookie('A', $misspelled_variable); ↓ 結果 Set-Cookie: A=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT 日付が大昔になっているし、クッキーの値に「deleted」は指定していません。これは、クッキーを削除する時の書き方ですが、PHPでクッキーの削除というと、expiresに過去日付を明示する方法をよく見かけますが、単に第2パラメータを空文字列にすればよかったのか…と思いマニュアルを見たら、一応書いてありました。 http://php.net/manual/ja/function.setcookie.php 陥りやすい失敗 クッキーは
iOSのSafariでサードパーティーCookieが使えない対策 - Takuji->find;
iOSのSafariでiframe内に別ドメインのページを表示して、そのドメインでCookieを使う場合、最初のページでは使用できないという素敵な仕様がある。 対策方法としては、POSTで遷移するとか、パラメーター持ち回って次のページでCookieにセットするとか。 <form id="redirect_form" action="" method="POST"> <input type="hidden" name="hoge_session" value="[% sid %]" /> <button type="submit">げーむをはじめる！的な</button> </form> <script type="text/javascript"> $(document).ready(function (){ $('#redirect_form').attr('action','/');
node.jsでhttp sessionを共有するsocket.ioのテストを書く - すぎゃーんメモ
node.js + socket.io はリアルタイムwebアプリを作るのにとても良い組み合わせだと思っています。 しかし、基本的にsocket.ioのconnectionはhttpのsessionと関連が無いので、例えばそのconnectionがログインしているユーザのものかその他のユーザのものか区別がつかない。以前はSessionWebSocketを使ってそれを判別するようにしていたのだけど、残念なことに残念なのでコレはもう使いたくない。。 そこでclientから最初にcookieを送信してもらって、そこからclientのsessionを識別する、という方法がある、と以前@masahirohさんに教えていただきました。 *1 session共有方法 クライアント側では下記のように接続時にcookieを送信するようにしておき、 var socket = new io.Socket();
サードパーティCookieの歴史と現状 Part2 Webアプリケーションにおける利用とその問題 - 最速転職研究会
前回 http://d.hatena.ne.jp/mala/20111125/1322210819 の続きです。 前回のあらすじ ブラウザベンダーはサードパーティCookieをデフォルトでオフにしたかったんだけどお前らがサードパーティCookieに依存したサイト作るし使うからオフに出来なかったんだよ!!!!! といった事情を踏まえた上でWebアプリケーションにおけるサードパーティCookieの利用の歴史について書きます。前提知識の共有が済んだので、ここからはある程度個人的な意見も含まれます。実装面での技術的な内容も含みます。 サードパーティCookieが必要とされてきた歴史 広告のためのトラッキングCookie以外にも、サードパーティCookieに依存したサービスが数多く存在してきた。個人的に把握しているいくつかのサービスについて時系列で述べる。ついでに広告業界の流れについても重要なのを幾
全く何も痕跡を残さずにブラウズする方法 | ライフハッカー・ジャパン
ブラウザのプライベートモードを使えば、ブラウズ履歴が完全にプライベートになっていると思いますか？ 実は言うとそうではないんです！ どちらかと言うと、なんらかのブラウズの痕跡を残していることの方が多いくらいなのです。なので、今日は、何も痕跡を残さずにブラウズする完全なるプライベートブラウジング方法について解説します。 問題 ネット上で何を見たのか、という履歴は、ブラウザの履歴やその他のプライベートデータを消去しただけでは完全には消えません。キャッシュされたDNS lookupsやFlash cookiesなどはOSに保存され続けているのです。最初に明確にしておくと、全ての記録を常に完全に削除し続ける、というのは不可能です。なので、職場で見るべきでないサイトなどを見ている場合、PC上の履歴を削除しても、システム管理者などによって見つけられてしまう可能性はあります。自分のPCの場合、下記の方法で
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
