ウェブサイトがJavaScriptとCookieなしで個人を追跡する方法が一発で理解できる「No-JavaScript fingerprinting」
「フィンガープリント」とは、JavaScriptやCookieなしでウェブサイトのユーザーを識別するための固有識別子で、ユーザーの属性・行動・興味・関心といった詳細な情報をもとにマッチする広告を表示するターゲティング広告に用いられます。そんなフィンガープリントが、JavaScriptやCookieを使わずにどうやってユーザーを特定しているのかがよくわかるサイト「No-JavaScript fingerprinting」が公開されています。 No-JavaScript fingerprinting https://noscriptfingerprint.com/ 今回はGoogle ChromeからNo-JavaScript fingerprintingにアクセスしてみます。アクセスする前に、JavaScriptを使用しないようにあらかじめブラウザから設定しておきます。Chromeの右上にあ
HTML5のLocal Storageを使ってはいけない（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Randall Degges - Please Stop Using Local Storage 原文公開日: 2018/01/26 著者: Randall Degges 日本語タイトルは内容に即したものにしました。 画像は元記事からの引用です。 初版公開: 2019/10/19 追記更新: 2024/04/05 -- リンク情報を記事末尾に移動しました 本気で申し上げます。local storageを使わないでください。 local storageにセッション情報を保存する開発者がこれほど多い理由について、私にはさっぱり見当がつきません。しかしどんな理由であれ、その手法は地上から消えてなくなってもらう必要がありますが、明らかに手に負えなくなりつつあります。 私は毎日のように、重要なユーザー情報をlocal storageに保存す
Cookieを使用せずにユーザー属性を推定する技術を確立し、特許を取得 | ログリー株式会社
ログリー株式会社（本社：東京都渋谷区、代表取締役：吉永浩和、証券コード：6579、以下：ログリー）は、インターネット広告配信においてCookieなどのユーザーを一意に特定する技術を使用せずに、ユーザーの属性を推定する技術を確立し、特許を取得いたしました。（特許：第6511186号） 近年、インターネットにおけるユーザーのプライバシー保護について関心が高まり、ブラウザのCookieが制限されるようになりました。また、EU圏ではGDPR（EU一般データ保護規則 *1）が制定され、Apple社のSafariブラウザではITP（Intelligent Tracking Prevention（以下、ITP）*2）によってCookieによるトラッキングを禁止する機能が搭載されるなど、今後もユーザーのプライバシー保護に対する仕組みが整備されていきます。 ログリーが実施したスマートフォンにおけるITPの影
Web Storage: セッショントークンのマシな手段 ― cookieとセキュリティ面を比較してみる | POSTD
最近、私は「セッショントークンを、cookieの代わりに Web Storage (sessionStorage/localStorage)に保存するのは安全ですか？」ということを尋ねられました。このことについてGoogleで検索したところ、検索結果の上位のほとんどが「Web storageはcookieに比べてかなりセキュリティが弱く、セッショントークンには不向きである」と断言していました。透明性のため、私はこの逆の結論に至った理論的根拠を公に書くことにしました。 Web Storageに関する議論の中核として言われるのは、「Web StorageはsecureフラグやHttpOnlyフラグといったcookie特有の機能をサポートしていないため、攻撃者が容易に盗み取ることが可能」というものです。path属性についても言及されます。私は、これらの機能それぞれについて調べてみました。そして、
ログアウト機能の目的と実現方法
このエントリでは、Webアプリケーションにおけるログアウト機能に関連して、その目的と実現方法について説明します。 議論の前提 このエントリでは、認証方式として、いわゆるフォーム認証を前提としています。フォーム認証は俗な言い方かもしれませんが、HTMLフォームでIDとパスワードの入力フォームを作成し、その入力値をアプリケーション側で検証する認証方式のことです。IDとパスワードの入力は最初の1回ですませたいため、通常はCookieを用いて認証状態を保持します。ログアウト機能とは、保持された認証状態を破棄して、認証していない状態に戻すことです。 Cookieを用いた認証状態保持 前述のように、認証状態の保持にはCookieを用いることが一般的ですが、Cookieに auth=1 とか、userid=tokumaru などのように、ログイン状態を「そのまま」Cookieに保持すると脆弱性になります
4. クッキーとセッション
4.1. クッキー この節ではクッキーの取り扱いについて説明します。サーブレットではクッキーの情報を「javax.servlet.http.Cookie」クラスで管理しています。このクラスで管理されている情報は、クッキーをサーバから送る際に、HTTPヘッダーに追加される行と対応しています。追加される行は以下のような形式をしています。 Set-Cookie: NAME=VALUE; Max-Age=DATE; path=PATH; domain=DOMAIN_NAME; version=VERSION; comment=COMMENT; secure それぞれの意味は以下の通りです。 クッキーの名前と値に対応しています。「ID=56」で、「ID」というクッキー名に「56」という値が設定されます。 Cookieクラスのコンストラクタ「Cookie(String,String)」および「setV
とほほのCookie入門 - とほほのWWW入門
Cookie とは、以下のようなことを実現するための機構です。 訪問者がそのページに何回訪れたか記録して表示する。 通常モード、フレームモードなど、訪問者の好みを記録しておき、次回訪問時にその好みのモードで表示する。 掲示板やチャットで入力したユーザー名を記録しておき、次回訪問時にユーザー名の入力を省略する。 ログインによるセッションを維持する。 下記の仕様書が公開されています。 RFC2109: https://tools.ietf.org/html/rfc2109 (1997年2月) RFC2965: https://tools.ietf.org/html/rfc2965 (2000年10月) RFC6265: https://tools.ietf.org/html/rfc6265 (2011年4月) 上記のようなデータは CGI などを用いてサーバー側に記録することもできますが、Co
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
