2020/02/13 DevSumi 発表資料
最新のブラウザで変わるCookieの取り扱いやPrivacyの考え方
2020/02/13 DevSumi 発表資料
流行マルウェア「EMOTET」の内部構造を紐解く | 技術者ブログ | 三井物産セキュアディレクション株式会社
EMOTETというマルウェアは2014年にはじめて確認されて以来、様々な変化を遂げてきました。当初はオンライン銀行の認証情報窃取を主な目的としたオンラインバンキングマルウェアとして認知されていましたが、その後、様々な変更が加えられ、現在においては2014年出現当時とは全く異なる挙動や目的を持ったマルウェアとなっています。 2018年末現在、EMOTETは世界中で積極的に拡散され被害拡大が懸念されており、日本国内も例外ではなく、様々な企業へEMOTETの感染を狙った不正メールが届いている状況にあります。 そうした状況にもかかわらず、少なくとも国内においては、今のところ現在のEMOTETに関する感染から挙動に至るまでのまとまった情報が見当たりません。 そのため、今年11月～12月に実際の国内企業への攻撃で使用されたEMOTETの不正メールを元に、我々が調査した結果と現在のEMOTETの全体像を
あなたがネットでエロ広告を見るのは、あなたがエロいからではない
youkoseki.com あなたがネットでエロ広告を見るのは、あなたがエロいからではない 「ネットのエロ広告がひどい」というようなことを言うと、「ネットの広告はターゲティングされてるんですよ。エロ広告が出るのはあなたが普段エロサイトばかり見ているからではないですか」と言い返す人がいる。 最近どうも流行りの考え方のようで、このごろツイッターで似たようなやりとりを何度も目にしている。 一見、このツッコミに反対することは難しい。自分がエロサイトを見ていないことを他人に証明できないからだ。そもそも大人ならエロサイトを見ても構わないし、それと一般サイトにエロ広告が溢れる問題は無関係なのだが。 だからこれ以上の誤解が広まらないように、ここに書いておく。あなたがネットでエロ広告を見るのは、あなたがエロいからではない。エロ広告は、あなたがエロいと知って配信されているとは限らない。 反証の方法 反証は簡単
Suica履歴は個人データでした―第1回プライバシーフリーク・カフェ（後編）
ターゲティング広告、日本のやりかた米国のやりかた 山本 はい、というわけで後半を進めたいと思います。 いま、個人の閲覧情報をトレースするために使われているcookie問題というのは非常に熱いところでありまして、まずはこの議論からしていきたいと思っております。 cookieを使うことで個人的な履歴も含めてさまざまな情報がとれるようになってきました。そうなってくると先ほどの冒頭でありました、「個人情報とはなんぞ？」と言ったときに、定番であり当たり前のように使われているcookieについて論じないわけにいかなくなっているわけです。 例えば、ある特定のニュースサイトに一定期間、定期的に訪問された読み手がどのようなURLをたどると結果的にどういうECサイトに飛んでいき、それが購買になるかということがなんとなく分かってくるようになります。そこに、属性データが組み合わさると、この読み方のパターンを持って
CORS(Cross-Origin Resource Sharing)について整理してみた | DevelopersIO
ブラウザからAmazon S3に直接ファイルをアップロードしたい 先日、Amazon S3にファイルをアップロードするWebアプリを作ろうとして色々調べていたところ、S3にCORSという仕様のクロスドメインアクセスの設定をすることによって、ブラウザから直接S3にアップロードをする方法にたどり着きました。ただ、この方法を使うにあたってはCORSというクロスドメインアクセスの仕様をきちんと理解しておいた方が良さそうでしたので、まずはCORSについて自分なりに整理してみました。 なお、弊社の横田がCORSとS3についての記事を以前書いていますので、S3のCORSサポートに関する概要を知りたい方はそちらをご覧下さい。 CORS(Cross-Origin Resource Sharing)によるクロスドメイン通信の傾向と対策 CORS ブラウザでAjax通信を行う際には、同一生成元ポリシー(Same
Webアプリ開発者のためのHTML5セキュリティ入門
Enterprise x HTML5 Web Application Conference 2014の発表資料です。Read less
twitterに学ぶなりすまし投稿対策
先日もtwitter上の犯行予告により20歳の青年が逮捕されたようですが、なりすましによる誤認逮捕ではなかったのか気になるところです。そこで、twitterが、なりすまし投稿をどの程度対策しているかを調べてみることにしました。twitterの安全性を確認することが目的というよりも、twitterが実施している対策を知ることにより、皆様のWebサイトを安全にする参考にしていただければと思います。 今回調べた「なりすまし投稿」の手法は下記の通りです。 クロスサイト・リクエスト・フォージェリ(CSRF) クロスサイトスクリプティング（XSS） HTTPヘッダーインジェクション クリックジャッキング DNSリバインディング クッキーモンスターバグ このうち、上の5つの解説は拙稿「“誤認逮捕”を防ぐWebセキュリティ強化術」、最後のクッキーモンスターバグについては、過去のエントリ「クッキーモンスター
クッキーモンスターバグがあると、IPアドレス偽装防止のCSRF対策が回避される
日経Linux 2013年1月号に「“誤認逮捕”を防ぐWebセキュリティ強化術」を書き、それが今週4回連載で、ITproに転載されました。この中で、クロスサイトリクエストフォージェリ(CSRF)対策について説明しましたが、クッキーモンスターバグ(Cookie Monster Bug)がある場合に対策が回避されることに気がつきました。 それでは、どのような対策が望ましいかを考えてみると、中々難しい問題です。以下、その内容について検討します。 解決すべき課題の整理 記事の趣旨は、昨年無実の市民のパソコンからCSRFによる犯行予告が横浜市のサイトに書き込まれたことを受けて、サイト側でCSRF対策をして、なりすまし書き込みができないようにしようというものです。なりすましの犯行予告には、CSRFのほか、マルウェアを用いる方法、CSRF以外のWebサイトへの攻撃手法もあるので、CSRF対策だけで十分と
GoogleがSafariの設定を迂回してトラッキングしていたとされる件について(2) - 最速転職研究会
http://d.hatena.ne.jp/mala/20120220/1329751480 の続き。書くべきことは大体既に書いてあったので、補足だけ書く。 Googleは制裁金2250万ドルを支払うことでFTCと和解した http://jp.techcrunch.com/archives/20120809google-settles-with-ftc-agrees-to-pay-22-5m-penalty-for-bypassing-safari-privacy-settings/ まさか(まともに調査されれば)こんなことになるとは思わなかったので驚いた。異常な事態である。そしてGoogle側の主張を掲載しているメディアが殆ど無いのも異常な事態である。 2250万ドルもの制裁金(和解金)が課せられるのは、2009年に書かれたヘルプの記述が原因だという。 問題の記述 http://obam
「Facebookで自分の名前と写真を広告に使えないようにする方法」について - 最速転職研究会
表題の件について、ソース不明の噂話や、意味を理解しないままリスクを誇張して拡散される様子を数日前から見ることができる。放っといて収まるかと思っていたらnanapiが大拡散していた。記事を書いているのはnanapiの社長であるkensuuである。時給800円のバイトかと思ったらkensuuである。 http://nanapi.jp/37983/ この件についての見解をいくつかTwitterに書いた。 まあ、全くのノーリスクというわけでも無いだろう。 正確に言えば「この設定が意味を持つような不適切な実装をしてはならない」 「表示」するだけならば、広告主や、他の広告ネットワークに対して、あなたのプロフィール画像や表示名に対してアクセスを許可する必要がない。facebook.comのiframeを使って直接Facebookから表示するだけだ。この意味がわからなかったらウェブ系の仕事に関わっているプ
後付けでトラッキング機能が有効化されることについて、はてなとTwitterの場合 - 最速転職研究会
前: http://d.hatena.ne.jp/mala/20120308/1331193381 はてなのその後の話 http://hatena.g.hatena.ne.jp/hatenabookmark/20120313/1331629463 話題になってからの対応が遅い、という人がチラホラいたけれど、別に対応はそれほど遅いというわけでもないと思う。 これは近藤さんがSXSWというイベントに行っていて日本にいなかったためで、収益にも影響する話なので即断できなかったのだろう。 こういう時にあとさき考えないで不良社員が勝手に広報したり、勝手に修正しても良いと思う(個人の感想です) 公平のため記しておくとHUG Tokyoというイベントで大西さんにおごってもらった(はてなの脆弱性をちょくちょく報告しています) Twitterの話 先日、Twitterが外部サイト上でのボタン、ウィジェットでト
Google Safety Center - Stay Safer Online
search. email. watch. store. share. browse. message. ask. meet. search. search. email. watch. store. share. browse. message. ask. meet. search. search. search. email. email. watch. watch. store. store. share. share. browse. browse. message. message. ask. ask. meet. meet. search. search. search. email. watch. store. share. browse. message. ask. meet. search.
オンラインプライバシー勉強会-行動追跡の現状とブラウザ業界の動向-
1. オンラインプライバシー勉強会 ∼行動追跡の現状とブラウザ業界の動向∼ by Tomoya ASAI (dynamis) last update on 2011.04.20 2. about:me http:// dynamis.jp @dynamitter facebook.com/ dynamis mailto: Tomoya ASAI <dynamis@mozilla-japan.org> 3. はじめに 今日は「勉強会」です 相互に議論・勉強しましょう 個人的な意見も述べます Mozilla 公式見解ではありません 後半はディスカッションタイム 途中でも遠慮なく質問・議論を Mozilla の公式見解はプライバシーブログ: http://blog.mozilla.com/privacy/
サードパーティCookieの歴史と現状 Part3 広告における利用、トラッキング、ターゲティング広告におけるプライバシーリスク - 最速転職研究会
前回の続き。なるべく一般人向けに書きます。サードパーティCookieとあまり関係のない話も書きます。 http://d.hatena.ne.jp/mala/20111125/1322210819 http://d.hatena.ne.jp/mala/20111130/1322668652 前回までの概要 トラッキング目的のCookieの利用などからサードパーティCookieの利用は問題視されIE6で制限がかけられるもプライバシーポリシーを明示すれば利用できるという迂回手段を用意、しかし今ではP3Pはオワコン化、SafariはサードパーティCookieの受け入れをデフォルトで拒否する設定を採用したが一度受け入れたCookieは問答無用で送信、Mozilla関係者は「殆ど合法的な利用目的はない」と言っていたものの既存Webサイトとの互換性のために変更できず、ブラウザはサードパーティCookie
サードパーティCookieの歴史と現状 Part1 前提知識の共有 - 最速転職研究会
Web開発者のためのサードパーティCookieやらトラッキングやらの問題点について三回ぐらいに分けて書きます。 この文章は個人的に書いていますので、おい、お前のところのサービスがサードパーティCookieに依存してるじゃねーかというツッコミがあるかもしれないが、そういうことを気にしているといつまで経っても公開できないという問題が出てしまうので、そんなことはお構いなしに書く。ちなみに例外なく自社サービスに対してもサードパーティCookieに依存するな死ねと言っている。これはWebプログラマー観点で、自分がサービス開発に関わる上で知っておかねばならないだろう知識として十数年間だらだらとWebを見ていて自然に知っていたものと、あるいは興味を持って率先して調べたものが含まれている。ググッて直ぐに分かる程度の用語の定義的なことは書かない。あくまでWebサイト制作者側からの観点なので、ブラウザ開発関係
今日こそわかる、安全なWebアプリの作り方2010
2. アジェンダ • 本日の構成 – 脆弱性の分類 – Webアプリの構造と脆弱性の原因箇所 – 「入力」では何をすればよいのか – SQLインジェクション対策の考え方と実際 • 原理の話（グローバル） • 文字コードの話（グローバル&ローカル） – ケータイWebアプリのセキュリティ（ローカル） • 議論の焦点 – Webアプリケーションのセキュリティ施策の考え方 – グローバル v.s. ローカル – 対策の歴史とあるべき姿 Copyright © 2008-2010 HASH Consulting Corp. 2 3. 徳丸浩の自己紹介 • 経歴 – 1985年 京セラ株式会社入社 – 1995年 京セラコミュニケーションシステム株式会社(KCCS)に出向・転籍 – 2008年 KCCS退職、HASHコンサルティング株式会社設立 • 経験したこと – 京セラ入社当時はCAD、計算幾何
mixi足あと廃止に寄せて - 最速転職研究会 | コメント mixiって今ほとんどがモバイルでアクセスされてたはずだけど、スマホ以外のガラケーでもこの問題が起きるの？
mixiが6年以上に渡って放置してきた足あと機能を使って訪問者の個人特定が可能な脆弱性を修正した。簡単に説明するとmixi以外のサイトからでもユーザーに気付かれずに、その人のmixiアカウントを特定するということが出来たが、出来なくなった。(正確にはユーザーが気付いたとしても特定された後) アダルトサイトが訪問者のmixiアカウント収集したり、ワンクリック詐欺サイトがmixiアカウント特定して追い込みかけたり、知らない人からメッセージ送られてきてURL開いたらmixiアカウント特定されてたり、そういうことが今まで出来ていたのが出来なくなった。 過去にもいろんな人が言及してるし、すでに終わった議論だと思ってる人もいるだろう。世間一般にどれぐらい認知されていたのかはよく分からないが、少なくとも技術者やセキュリティ研究者の間ではよく知られている問題だった。 http://internet.kil
徳丸本のあれこれを実践してみて気付いたこと | 水無月ばけらのえび日記
更新: 2011年7月9日23時0分頃 とあるシステムで徳丸本のストレッチングを採用することにしたという話がありましたが、その実装が佳境に入ってきました。私は指示だけ出して、実装はお任せ……と思っていたのですが、基本的な部分を作ってもらったところでバトンタッチされ、私が引き継ぐ形で実際にコードを書くことになりました。 基本的には徳丸本 (www.amazon.co.jp)のオススメどおりの実装にするという方針なのですが、実際にコードを書いてみると、いろいろと気になったり迷ったりした事も出てきました。そのあたりを簡単にメモしておきます。 ※ちなみに、このシステムはRuby1.9.2 + Ruby on Rails3での実装なので、PHPのコードサンプルをそのまま使っているわけではありません。 ストレッチ回数をどう決めるのか徳丸本327ページにあるコード例を参考にして実装。アプリケーションごと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Firefox 22のCookieに関するポリシー変更(予定)についての意見書
https://github.com/xKerman/memorandum/blob/master/autopagerize_cookie_issue.md
