はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
クライアントサイドの巨大なクッキーとサーバーサイドのヘッダーサイズ制限の組み合わせによるDoSについて - デー
もう10年以上前のネタなのですが、いまだに有効だし、最近、セッションを扱っていないならXSSがあってもあまり問題ないという意見を見ることがあるので、サービス提供側として案外面倒なことになる場合がある、という話を書きました。 POCです。 http://www.udp.jp/misc/largecookiedos.html 内容としては、 JavaScriptから巨大なCookieをブラウザに設定できる HTTPサーバーは受け取れるHTTPヘッダーサイズの上限を持っていて、それを超えていた場合にBad Requestを返す 1によって2を超えるサイズのCookieが設定可能な場合がある（たぶんほとんどの場合可能） よってXSSなどによって巨大なCookieを設定されると以降サービスが利用できなくなる というものです。 Cookieの有効期限を何十年も設定されるとユーザー側で勝手に回復すること
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では署名付ける代
HTTPSを使ってもCookieの改変は防げないことを実験で試してみた
寺田さんのブログエントリ「他人のCookieを操作する」には、通信路上の攻撃者がいる場合は、SSLを使っても、Cookieの盗聴を防ぐことはできるが、Cookieの改変を防ぐことはできないと指摘されています。いかにも寺田さんらしい簡にして要を得たエントリで、これに付け加えることはあまりないのですが、残念ながらまだ読んでいない人が多そうだと言うことと、より広い読者に向けて具体的に説明した方がよいだろうと考えました。 そこで、通信路上に攻撃者がいる典型例として、公衆無線LANの偽AP（アクセスポイント）があるケースを題材として、「HTTPSを使ってもCookieの改変は防げない」ことを説明します（Secure属性使うと盗聴は防げますが、改変は防げません）。長いエントリなので結論を先に書いておきます。 Secure属性がないCookieはHTTPSでも盗聴できる Cookieの改変についてはSe
他人のCookieを操作する - T.Teradaの日記
少し前の話ですが、Googleが自身のWebサイトの脆弱性発見者に対して、報酬（現金 500 USD以上）を支払うプログラムをはじめています。 Google Online Security Blog: Rewarding web application security research 過去にも、脆弱性の発見者に報酬を支払うプログラムはありましたが、Webブラウザ等のソフトウェアの脆弱性が対象でした（参考）。 今回のプログラムでは、Webアプリの脆弱性が対象だというところが特色です。しかも、実際に運用されている本番のGoogleサイトの脆弱性が対象です。その脆弱性の発見者に報奨金を払うということは、（一定の制約は設けていますが）基本的に自由に本番サイトの検査をしてよいといっているわけです。 実際にやってみる Webアプリの診断をやっているものにとっては、これ以上のお小遣い稼ぎはない！と思
Cookie Clearinghouse | Cookie Clearinghouse
Thank you for your interest in the Cookie Clearinghouse. We have stopped work on this project. Here are some projects whose efforts you might want to follow instead, along with some thoughts on what we learned: If you are interested in software to protect your privacy online, we recommend the Privacy Badger project from the Electronic Frontier Foundation (EFF). Privacy Badger incorporates technica
各携帯端末のCookieについてまとめ - Kimura.Memo
Set-Cookie: name=value; Expires=date Set-Cookie: name=value; Max-Age=second 携帯端末全般に言えること。 Cookieにセットするname, valueは、適切にエスケープすること。 有効期限の指定は、Max-Age記法に対応している場合は、なるべくそれを使うようにすること。 一度にたくさんのSet-Cookie:を発行しないこと。 （なるべく１つのSet-Cookie:にデータをまとめる） VodafoneのCookie W型*1/3GC型*2端末のみ対応 一時型/期限型とも対応 ただし、一時型にするには、Expires, Max-Ageともに記載無しでなければならない。 期限型の場合は、Expires, Max-Ageいずれかがあれば良い。 Max-Age記法の場合は、Version=1;を記述する必要があるかも
secure.softbank.ne.jp について SoftBank に質問したら残念な結果になったの巻 - co3k.org
割と個人的には速報なので簡単にまとめます。 高木浩光さんの http://twitter.com/HiromitsuTakagi/status/16057716034 のアドバイスを受けて、 secure.softbank.ne.jp を通さないようにする方法などについて、以下のような質問を投げました。 https://secure.okweb3.jp/mobilecreation/EokpControl?&event=QE0004&tid=24187 HTTP から HTTPS へのリンクについて OpenPNE （http://www.openpne.jp/）というオープンソースのソフトウェアを開発している者です。 SSL 環境でログイン継続に Cookie を使うにあたり、 URL として https://example.com/ のような形式と、 https://secure.so
OpenPNE 3.5.3 での「かんたんログイン」の端末固有IDからの（部分的）脱却で困った点 - co3k.org
（個人ブログなので「携帯電話個体識別番号」ではなく「端末固有 ID」と呼ぶよ） ということで、 OpenPNE 3.5.3 でおこなった「かんたんログイン」の変更について http://www.openpne.jp/archives/5070/ の件です。 ここで説明されているのは（技術者には既知である事項の説明を除くと）、要するに以下のようなことです。 Cookie 内のランダムな ID を見る認証手段を用意したよ Cookie が使える端末では端末固有 ID ではなく Cookie 内の ID を見て「かんたんログイン」するようにしたよ 認証手段を「A: Cookie 内 ID のみ」「C: 端末固有 ID のみ」「B: A と B を併用」できるようにしたよ（see: http://twitter.com/co3k/status/15973375832 ） B の方法を選んだ場合は、
高木浩光＠自宅の日記 - 今こそケータイID問題の解決に向けて
■ 今こそケータイID問題の解決に向けて 目次 ソフトバンクモバイル製のiPhoneアプリがUDIDを認証に使用していた件 Web開発技術者向けの講演でお話ししたこと 研究者向けの講演、消費者団体向けの講演でお話ししたこと 総務省がパブリックコメント募集中 ソフトバンクモバイル製のiPhoneアプリがUDIDを認証に使用していた件 6月初めのこと、ソフトバンクモバイルが「電波チェッカー」というiPhoneアプリを直々に開発して、iTunesストアで配布を始めたというニュースがあったのだが、それを伝えるITmediaの記事で、「取得された電波状況情報はiPhoneのUDIDとともにソフトバンクモバイルに報告される」と書かれているのが気になった。*1 「電波チェッカー」で検索して世間の反応を探ったところ、ソフトバンクモバイル社のCTO（最高技術責任者）の方が、Twitterで直々に市民と対話な
携帯Webのクッキー利用について調べてみたメモ【update】
携帯でクッキーがどれぐらい使えるか調べたメモ。 ■３キャリア＋スマートホン（PC）対応クッキー記述 クッキーのドメイン、パス指定に何も記述しなければ完全一致として扱われるのでこれであればそのままクッキーの読み書きは可能です。 しかし一定規模のシステムであれば、クッキーのスコープを広く取りたいケースの方が多いと思います。 サブドメイン、複数のAレコードによるWebサーバが存在する場合に、３キャリア共通に使えるようにするクッキーのドメイン指定は、「.」から始まるドメインを指定することで可能です。 例： Set-Cookie: testcookie=thankyoumovatwi; path=/; domain=.movatwi.jp この辺、ハマリ所なのでウノウラボの記事もご参考ください。（なんとドメインが.jpと.inで挙動が違うらしいという、、） 携帯とCookieドメイン ■携帯電話でク
Cookie 今昔物語 - はてなるせだいあり
概要 Cookie の不幸な歴史と現状、そして将来についてまとめた。 仕様はどこにあるか Web 上の様々な規格は、誰かが定め、それに皆が合わせるという形で動いている。しかし、Cookie の仕様は誰が決め、どこで規定されているか知っている人は、意外と少ないのではないかと思う。W3C や IETF だと思っている人が多いのではなかろうか。 正解を言ってしまうと、定めたのは 1994 年、Netscape Communications 社であり、文書は http://wp.netscape.com/newsref/std/cookie_spec.html で公開されていた。アクセスしてみればわかる通り、このページはもう存在しないし、Netscape 社自体が AOL に買収されており、今は Mozilla になったというか、消えてなくなっていることを知っている人は多いだろう。当時の文書は例に
yohgaki's blog - Firefox 2.0 ではおかしなクッキーの動作が一部だけ直っている模様
(Last Updated On: 2006年11月9日)備考：名無しさんの指摘でタイトルを変更、一部本文を修正しました。（IEとFFの立場を入れ替えました） 少なくとも2006年1月ころのMozilla系ブラウザには簡単に設定できるべきでないクッキーが設定できてしまう問題がありました。最悪なのはco.jp等、ccTLDの属性ドメインに対してクッキーが設定できてしまう動作ですが、手元のFirefox 2.0で試したところHTTPのSet-Cookieヘッダではco.jpには設定できなくなっています。しかし、この修正が中途半端でJavaScriptからdocument.cookieにco.jpにクッキーを設定できてしまいます。（名無しさん、情報ありがとうございます） example.co.jpとwww.example.co.jpに同じ名前のクッキーを設定するとexample.co.jpのクッ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Stanford, Mozilla, Opera team up to tackle cookie privacy issues
How Firefox's Anti-Cookie Policy Could End Web Advertising As We Know It
https://b.hatena.ne.jp/HiromitsuTakagi/20091004