iOS端末のブラウザアプリでは履歴やキャッシュを残さない「プライバシーモード」でも情報が漏れていることが判明
ウェブブラウザには検索履歴やCookieなどを削除してブラウジング内容をブラウザ上に残さないようにする「プライバシーモード」という機能が存在します。モバイルアプリでいうと、Safariの「プライベートブラウズモード」やGoogle Chromeの「シークレットモード」などがこれに当てはまるのですが、iOS端末上ではHTML5とAirPlayによって、プライバシーモード使用時でも情報がダダ漏れになっていることが明らかになっています。 When Private Browsing Isn't Private On iOS: HTML5 And AirPlay https://ma.ttias.be/when-private-browsing-isnt-private-on-ios-html5-and-airplay/ iOS端末にプリインストールされているブラウザアプリの「Safari」では、画
【スクリプトインジェクション対策08】自動ログインを実装しない。実装する場合は正しく実装する | gihyo.jp
なぜPHPアプリにセキュリティホールが多いのか? 【スクリプトインジェクション対策08】自動ログインを実装しない。実装する場合は正しく実装する 自動ログイン機能は便利ですが、セキュリティ上のリスクを確実に増加させます。安全性が重要なサイトでは自動ログイン機能は実装すべきではありません。 自動ログイン機能を実装する場合、正しく実装しなければなりません。 間違った自動ログインの実装方法 セッションIDクッキーの有効期限を長くする 固定の自動ログイン鍵をクッキーに保存する 自動ログイン鍵をすべてのページで送信する 自動ログインの実装にはセッションID以外の予測不可能なランダム文字列を利用します。複数のWebブラウザから自動ログインできるようしたい場合、ユーザIDと自動ログイン鍵、その鍵の有効期限を保存したテーブルを作成して鍵を管理します。 正しい自動ログインの疑似コードは次のようになります。 /
ブラウザのプライバシーモードを無視してしまう「スーパークッキー」とは？
ウェブサイトを閲覧するにはInternet ExplorerやGoogle Chrome、Firefox、Safariなどのウェブブラウザを使用する必要があり、これらのウェブブラウザにはプライバシー情報を保護するためにブラウジング時の履歴やCookie(クッキー)、一時ファイルなどを残さないプライバシーモードが存在します。しかし、プライバシーモードを使用してもこれらの機能を無視してユーザーの行動をトラッキングしてしまう「スーパークッキー」という手法が新たに生み出されました。 Browsing in privacy mode? Super Cookies can track you anyway | Ars Technica http://arstechnica.com/security/2015/01/browsing-in-privacy-mode-super-cookies-can-t
HTTPSを使っているのにCookieに「secure」属性を設定していない危険なサイトが話題に | スラド セキュリティ
最近SSL関連の脆弱性がたびたび話題になったが、これに関連してか、HTTPSを利用しているのにCookieのsecure属性を設定していないサイトについてが話題になっているようだ（セキュリティ研究家高木浩光氏によるTogetterまとめ）。 Cookieのsecure属性については、2004年に高木浩光氏がまとめた「安全なWebアプリ開発の鉄則 2004」の「CookieにSecure属性を」以下が分かりやすいが、この属性をセットしておくと、HTTPSでの通信時にのみそのCookieが送信される、というもの。secure属性が設定されていない場合、HTTP通信の際にもそのCookieが送信されるため、通信内容を傍受するなどでセッションIDなどが盗まれる可能性がある。 高木氏が検証したところ、secure属性が設定されていないサイトとしては全日空やニコニコ動画、OCNメールなどがあった模様。
第25回 PHPのアキレス腱 ── セッション管理 | gihyo.jp
PHPにはHTTPセッション管理モジュールが標準で付いてきます。このセッションモジュールには非常に重大なセキュリティ上の脆弱性が修正されずに残っています。その脆弱性とはセッションアダプションです。 セッションアダプションとは、セッション固定化攻撃に利用される脆弱性です。PHPのセッション管理モジュールがセッションアダプションに脆弱であることは、かなり以前、何年も前から知られています。しかし、開発者の理解不足より脆弱性が放置されたままになっています。 セッションアダプションとは セッションアダプションとは、ブラウザ等から送信された未初期化セッションIDをそのまま利用してセッションを初期化してしまう脆弱性です。ユーザが送信してきたIDでも第三者に予想できない文字列であれば大丈夫なのでは？と考える方もいると思います。その通りで第三者に予想できなければ問題ないですし、仮に予想できてもログインする際
第5回 携帯サイトでセッションを取り扱う | gihyo.jp
携帯サイトでのセッション管理 今回は携帯で会員サイトを作る時のベースとなるログイン状態の管理方法を見ていきたいと思います。セッションとはユーザーがサーバーに接続し、サイトを巡回している間アクセスしてきているのが同一利用者であることを認識するための仕組みです。この仕組みを利用することで、一度会員ログインが完了した利用者がサイトにアクセス中、継続的に自分だけの情報を見るといったことが実現可能になります。 図1 セッションの仕組み セッションを維持するためには、セッションIDを利用します。通常セッション管理はアクセスしてきた端末に対してセッションIDを割り振り、ブラウザに対して割り振られたセッションIDを渡します。サイト側はそのセッションIDに紐付いた情報を保持しておき、アクセスしてきたブラウザのセッションIDを元に情報を引き出すといった仕組みになっています。 ブラウザがセッション管理を行う方法
Cookieを使わずにユーザーを追跡する仕組みが普及しつつある | スラド IT
Canvas機能を使った文字やグラフィックス描画の際の挙動の違いでWebブラウザの違いを識別する「Canvas Fingerprinting」という技術が開発され、すでにトップ10万のサイト中5.5%がこれを使ったユーザー追跡を利用しているという。 また、ユーザがCookieをこまめに削除しても、サイト側が同じデータをFlashのローカル共有オブジェクト（LSO、Flash Cookie）などに保存しておいて回復させれば、実質的にCookieを不滅化することができる。このEvercookieを実現する手段の一つである「Respawning by Flash cookie」sは、人気上位200サイトのうち10サイトで検出されたそうだ。 Cookieを無効にしていても、適切な対処をしない限り、閲覧者の行動はかなりの割合で漏洩している可能性があるようだ。 Canvas Fingerprintin
CSRF 対策用トークンの値にセッション ID そのものを使ってもいい時代は終わりつつある - co3k.org
CSRF 脆弱性対策には攻撃者の知り得ない秘密情報をリクエストに対して要求すればよく、そのような用途としてはセッション ID がお手軽でいいよねという時代があったかと思います。 いや、もちろん、 CSRF 対策の文脈だけで言えば今も昔も間違いというわけではありません。セッション ID が秘密情報であるのは Web アプリケーションにおいて当然の前提ですので、 CSRF 対策としてリクエストに求めるべきパラメータとしての条件はたしかに満たしています。 たとえば 『安全なウェブサイトの作り方』 改訂第6版では以下のように解説されています。 6-(i)-a. (中略) その「hidden パラメータ」に秘密情報が挿入されるよう、前のページを自動生成して、実行ページではその値が正しい場合のみ処理を実行する。 (中略) この秘密情報は、セッション管理に使用しているセッション ID を用いる方法の他、
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
IPアドレス・クッキー・JavaScript・UAなどを使わずユーザーを個別に追跡する方法
by Vernon Swanepoel ウェブサイトのユーザーがどれぐらいページを見てくれているのか、訪問頻度はどれぐらいなのかといった情報を追跡するのにはクッキー(Cookie)やJavaScriptなどが使用されますが、そうやって追跡されるのがイヤだということでCookieを受け入れないように設定したり、JavaScriptをオフにしているという人もいるはず。しかし、それでもユーザーを個別に追跡する方法があります。 Lucb1e.com :: Cookieless Cookies http://lucb1e.com/rp/cookielesscookies/ これはオランダ在住でコード・セキュリティ・ネットワークを愛しているというlucb1eさんが明らかにしたもの。手法としては新しいものではなく、多数のサイトで使われているにもかかわらず、そのことを認識している人はほとんどいないというも
Web解析・広告で個人情報をどう扱うべきか？ プライバシー対策としての「Do Not Track」の現状と課題
『MarkeZine』が主催するマーケティング・イベント『MarkeZine Day』『MarkeZine Academy』『MarkeZine プレミアムセミナー』の 最新情報をはじめ、様々なイベント情報をまとめてご紹介します。 MarkeZine Day
ユーザーが制御できない「秘密cookie」、半数強のサイトが利用
米研究チームの発表によると、Adobe Flashを使ってネット上のユーザーの行動をひそかに追跡し続けるサイトが増えているという。 Adobe Flashを使ってネット上のユーザーの行動を追跡し続ける「秘密cookie」を利用するサイトが増えているという。米カリフォルニア大学バークリー校などの研究チームがこのほど論文を発表した。 「Flash cookie」は通常のcookieとは異なり、ブラウザのセキュリティ設定ではコントロールできないという。研究チームが大手サイトによる同cookieの利用実態について調べたところ、調査対象としたサイトの半数以上がFlash cookieを使ってユーザー情報を保存していることが判明した。 中にはユーザーが削除したHTTP cookieを、Flash cookieを使って復活させているケースもあった。しかしその存在についてはサイトのプライバシーポリシーでも
「スマホアプリと広告ビジネスをめぐるプライバシーとセキュリティ」について、高木浩光氏が問題提起 【モバイル＆ソーシャルWEEK2012レポート】
『MarkeZine』が主催するマーケティング・イベント『MarkeZine Day』『MarkeZine Academy』『MarkeZine プレミアムセミナー』の 最新情報をはじめ、様々なイベント情報をまとめてご紹介します。 MarkeZine Day
XMLHttpRequestを使ったCSRF対策 - 葉っぱ日記
合わせて読んでください：Flashと特定ブラウザの組み合わせでcross originでカスタムヘッダ付与が出来てしまう問題が未だに直っていない話 (2014-02/07) XMLHttpRequestを使うことで、Cookieやリファラ、hidden内のトークンを使用せずにシンプルにCSRF対策が行える。POSTするJavaScriptは以下の通り。(2013/03/04:コード一部修正) function post(){ var s = "mail=" + encodeURIComponent( document.getElementById("mail").value ) + "&msg=" + encodeURIComponent( document.getElementById("msg").value ); var xhr = new XMLHttpRequest(); xhr
ログアウト機能の目的と実現方法
このエントリでは、Webアプリケーションにおけるログアウト機能に関連して、その目的と実現方法について説明します。 議論の前提 このエントリでは、認証方式として、いわゆるフォーム認証を前提としています。フォーム認証は俗な言い方かもしれませんが、HTMLフォームでIDとパスワードの入力フォームを作成し、その入力値をアプリケーション側で検証する認証方式のことです。IDとパスワードの入力は最初の1回ですませたいため、通常はCookieを用いて認証状態を保持します。ログアウト機能とは、保持された認証状態を破棄して、認証していない状態に戻すことです。 Cookieを用いた認証状態保持 前述のように、認証状態の保持にはCookieを用いることが一般的ですが、Cookieに auth=1 とか、userid=tokumaru などのように、ログイン状態を「そのまま」Cookieに保持すると脆弱性になります
開発者を悩ませるiframe内表示Webアプリ問題とは？｜【Tech総研】
フレーム内に小さなブラウザのようにWebページを表示してくれる「iframe」。特別な技術は必要ないのに、さまざまな問題に直面してしまうことが多く、開発者を悩ませます。今回はこの問題について解説します。 こんにちは、ミクシィの鈴木理恵子です。前回は身近なWebの世界でよく使われているiframeを、利用シーン別に分類してご紹介しました。ソーシャルアプリ型、ソーシャルプラグイン型、ブログパーツ型、ポータル型がありましたね。 iframeはまるで小さなブラウザであるかのように、フレーム内にWebページを表示してくれます。そのため、iframe内Webアプリは、通常のWebサイトとほぼ同じ開発方法で作成ができ、特別な技術は必要ありません。しかし、全く同じ開発方法で問題ないかというとそうでもなく、そのままだとさまざまな問題に直面してしまいます。特に「Cookieを利用したセッション管理ができない場
Outbound Port 80 blocking のご提案
Outbound Port 80 blocking ⽵竹 <takesako@shibuya.pm.org> http://www.janog.gr.jp/meeting/janog31/program/OP80B.html [ ] � MacBook Air ⾏行行 � [ ] � ⾏行行 ⼈人 � [ ] � ⼊入 � [ ] � ⼈人 � [ ] � ⽤用 Google Wireshark ⾯面⼈人 Firesheep � 2010 10⽉月 �Firefox � �Eric Butler⽒氏 � LAN facebook Twitter ⽂文 HTTP Cookie � �PoC⽰示 Firesheep ⾯面 Eric Butler⽒氏⽤用 Firesheep � Web �Amazon.com CNET dropbox Evernote Facebook Flickr Gith
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CSRF対策用トークンの値にセッションIDそのものを使ってもいい時代なんて、そもそも無かった
PC
