サードパーティCookieの歴史と現状 Part1 前提知識の共有 - 最速転職研究会
Web開発者のためのサードパーティCookieやらトラッキングやらの問題点について三回ぐらいに分けて書きます。 この文章は個人的に書いていますので、おい、お前のところのサービスがサードパーティCookieに依存してるじゃねーかというツッコミがあるかもしれないが、そういうことを気にしているといつまで経っても公開できないという問題が出てしまうので、そんなことはお構いなしに書く。ちなみに例外なく自社サービスに対してもサードパーティCookieに依存するな死ねと言っている。これはWebプログラマー観点で、自分がサービス開発に関わる上で知っておかねばならないだろう知識として十数年間だらだらとWebを見ていて自然に知っていたものと、あるいは興味を持って率先して調べたものが含まれている。ググッて直ぐに分かる程度の用語の定義的なことは書かない。あくまでWebサイト制作者側からの観点なので、ブラウザ開発関係
ant-eater.com - ant eater リソースおよび情報
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
実は厄介、ケータイWebのセッション管理
実は厄介、ケータイWebのセッション管理：再考・ケータイWebのセキュリティ（3）（1/3 ページ） “特殊だ”と形容されることの多い日本の携帯電話向けWebサイト。そこには、さまざまな思い込みや性善説の上しか成り立たないセキュリティが横行しています。本連載は、ケータイWebの特殊性をていねいに解説し、正しいケータイWebセキュリティのあるべき姿を考えます（編集部） 「Cookieを使えない端末」でセッションを管理する方法は？ 第2回「間違いだらけの『かんたんログイン』実装法」ですが、多くの方に読んでいただきありがとうございました。 今回は、前回に引き続き架空のSNSサイト「グダグダSNS」のケータイ対応を題材として、ケータイWebのセッション管理の問題点について説明します。携帯電話向けWebアプリケーション（ケータイWeb）のセッション管理は、かんたんログインよりも対策が難しく、厄介な問
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
高木浩光＠自宅の日記 - 共用SSLサーバの危険性が理解されていない
■ 共用SSLサーバの危険性が理解されていない さくらインターネットの公式FAQに次の記述があるのに気づいた。 [000735]共有SSLの利用を考えていますが、注意すべき事項はありますか？, さくらインターネット よくある質問（FAQ）, 2010年2月10日更新（初出日不明） Cookieは、パスなどを指定することができるため、初期ドメイン以外では共有SSLを利用している場合にCookieのパスを正しく指定しないと、同じサーバの他ユーザに盗まれる可能性があります。 （略） 上記については、「同サーバを利用しているユーザだけがCookieをのぞき見ることができる」というごく限定的な影響を示していています。また、Cookieの取扱いについて、問い合わせフォームやショッピングカート等、ビジネス向けのウェブコンテンツを設置されていなければ特に大きな問題とはなりませんが、個人情報を取り扱われる管
twitter の OAuth で思ったより豪快に認可してしまっている件 - 知らないけどきっとそう。
忘れたころに追記 API で _twitter_sess は発行されているようですが、web の UI にアクセスはできなくなったみたいです（つまり豪快さは解消されてます） OAuth コンシューマが twitter API にアクセスすると、ブラウザでログインしたときと同様のセッションクッキーが発行されている模様です GET https://twitter.com/account/verify_credentials.xml Authorization: OAuth realm="", oauth_consumer_key="***", oauth_nonce="***", oauth_signature="***", oauth_signature_method="HMAC-SHA1", oauth_timestamp="1253358338", oauth_token="***",
PHPのSession Adoptionは重大な脅威ではない - ockeghem's blog
なぜPHPアプリにセキュリティホールが多いのか?：第25回 PHPのアキレス腱にて、大垣靖男氏がPHPのSession Adoption問題について取り上げている。大垣氏は度々この問題を取り上げているが、今のところ氏の主張に同調する人を見かけない。それもそのはずで、大垣氏の主張は間違っていると私は思う。 以下、大垣氏の主張を実際に試してみる形で、順に説明しよう。 大垣氏の主張 大垣氏の主張は、PHPにはSession Adoption脆弱性があるために、標準的なSession Fixation対策であるsession_regenerate_id()を施しても、その対策は有効ではないというものだ。 しかし，実際には現在に至るまでPHPのセッションモジュールのセッションアダプション脆弱性は修正されないままになっています。このために，本来はsession_regenerate_id関数をログイン
ヤフーがyimg.jpを使う本当のワケ - 最速配信研究会(@yamaz)
ヤフーの画像はなぜyimg.jpドメインなのか？ サイト高速化の手法とヤフーの失敗例 でヤフーがなぜドメインを変えて画像サーバを運用しているかが書かれている.「静的なコンテンツに対してクッキーフリードメインを使うことによって速度向上を狙う」というのが理由とあって,これはこれでもちろん正しいのだけれど,これはどちらかというと副次的な理由で本当の理由は違う. クッキーフリードメインを使うことで悪意あるFlashコンテンツなどから自社ドメインのクッキーを守るためというのが本当の理由で,これはあちこちで使われているテクニックだ.Flashコンテンツは外部の業者さんに作ってもらったり,広告の入稿素材として入ってくるので,信頼できないデータとして取り扱う必要があり,万一まずいデータがアップされることがあっても大丈夫にしておく必要がある. 最近ユーザからの任意のコンテンツを受けつけて同一ドメインで配信し
【CSL】CSL緊急注意喚起レポート〜新手のSQLインジェクションを行使するボットの確認〜 | LAC
セキュリティソリューション分野でのリーディングカンパニー、株式会社ラック（本社：東京都港区、代表取締役社長:齋藤理、以下ラック）は、自社の研究機関であるサイバーリスク総合研究所のコンピュータセキュリティ研究所から緊急注意喚起レポートを公開しました。 本レポートによると、IDS/IPS、WAF などの防御システムをすり抜け、Webサイトの管理者が気づきにくい手法で攻撃する新手のSQLインジェクション攻撃を行使するボットを確認したと報告されています。また、この新手のSQLインジェクション攻撃はラックのセキュリティオペレーションセンターJSOC（ジェイソック）でも9月30日早朝から検知されており、また、実際の被害に遭ったWebサイトも確認されたため、広く注意喚起する目的で本レポートを公開しました。 本レポートでは、攻撃の特徴、攻撃による影響、対策方法についてそれぞれを詳細に解説しています。一般利
ここギコ！: 携帯電話のCookie周りについて
Posted by nene2001 at 14:55 / Tag(Edit): mobile cookie session / 0 Comments: Post / View / 0 TrackBack / Google Maps 携帯電話のCookie周りについて考えてたら、色々まとまらなくなったので、タイトルあいまいで全部ここに書く。 恥ずかしながら携帯Cookie初心者です。 なので、それおかしいよ、とか、或いはとっくに常識だよ、的なこと書くかもしれませんが、ご容赦のほど。 取っ掛かり：DoCoMoのiモードIDについて これまで、DoCoMoがCookie使えないのを理由として、かつキャリア毎に大きく認証処理変えてたら開発が煩雑だよね、という理由で、3キャリア携帯の端末や個人識別IDをログイン手段として用いて、WILLCOMとか識別IDを出さない仕様の方を、Co
Firefoxで「プライバシー情報の消去」の全部にチェックしても履歴は完全には削除されない - Active Galactic : 11次元と自然科学と拷問的日常
っていうことを、今頃知った。みんなで使うパソコンの設定をしていた身としては、履歴やクッキー、パスワードやフォームの類を全削除にしておけば問題はなく、クリーンなブラウザを快適に使ってもらえると思ってた。 へぇ、Flashクッキーなんて楽しい手段があるんだ。マクロメディアのローカルフォルダにクッキーがばっちり残っているじゃないか。Adobe Flashにはブラウザのクッキーとは独立した個人情報保管システムがあるみたいだね。他のプラグインも独自にローカルフォルダにデータを保管していたりするのかな。ん、ニコニコ動画の前回検索タグ履歴なんてのがあるぞ。 多分、Windowsだとこの辺にあると思う。 >C:\Documents and Settings\ユーザー名\Application Data\Macromedia\Flash Player\#SharedObjects\ もちろん、これは特定のブ
BASIC 認証でログアウトを可能にする方法 - kazuhoのメモ置き場
Cookie でログイン状態を管理すればいいんじゃいのかな。 まず、ログインボタンを押した時「だけ」is_logged_on を真にする。 HTTP/1.1 Authorization Required Set-Cookie: is_logged_on=1 WWW-Authenticate: Basic realm="Hoge123456" ...サーバ側では、Basic 認証のパスワードがあり、かつ、is_logged_on の値が真であることをチェックすればいい。 GET / HTTP/1.1 Cookie: is_logged_on=1 Authorization: Basic ... ... HTTP/1.1 200 OK ...で、ログアウトの際には、Cookie を消す。 HTTP/1.1 200 OK Set-Cookie: is_logged_on=0 ...そして、is_
Cookieは悪くない――潜む漏えいパターンの真実 (1/2)
日ごろ何げなくPCに保存されているCookieという名の情報保存の仕組み。この仕組みには、アクセス先のサイトによって暗号化を行っていない場合や、無用に長い保存期間で設定されている場合がある。サーバ管理者やユーザーは何に注目すればよいのか。 オンライン・ムック「スパム時代のサニタイズ開発手法」では、前回、個人情報漏えいのケースとして、サーバサイドとクライアントサイドの2つの側面があることを解説した。今回はセキュリティホールに関するニュースでは必ずと言ってよいほど目にする「Cookie」について解説していく。いったいどのようなものなのか？ そして、普段、何げなく使っているブラウザが利用するCookieの仕組みについて解説しよう。便利な機能として使われているものだが、時には情報漏えいの原因となってしまうことを理解しておきたい。 サーバサイドのソフトウェア環境は、Webサーバの管理者側に責任が委ね
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
テクノロジー : 日経電子版