高木浩光＠自宅の日記 - 破綻している日本のデータプライバシー法制
■ 破綻している日本のデータプライバシー法制 Tポイントの履歴とWebのアドネットワークとの結合 一昨年の7月に設立されたオプトとCCCの合弁会社「株式会社Platform ID」の広告システム「オープンデータプラットフォーム「Xrost」」について書いておかねばならない。 Xrostは、Web向けの行動ターゲティング広告を提供しているが、通常のそれとは異なる手段で、T-SITEと連係している。これは、設立当初の報道から窺い知ることができたし、以下の書籍にも「リアル店舗での購買行動履歴に基づくターゲティング」と書かれている。 DSP/RTBオーディエンスターゲティング入門 ビッグデータ時代に実現する「枠」から「人」への広告革命, 横山隆治／菅原健一／楳田良輝, インプレスR&D, 2012年5月25日 そして、Xrostの最も特徴的なオーディエンスターゲティングは、CCCが運営するT（ポイ
ParseっていうBaaSのソーシャル連携の実装がよくなった気がする - r-weblife
もう少しでおはようございます、ritouです。 前にこんなの書いたわけです。 ParseっていうBaaSのソーシャル連携の実装がよろしくない気がする - r-weblife 内容はこんな感じです。 ParseっていうBaaSのTwitter連携について アプリはParseに対してConsumerKey/Secret, Token/Token Secretを渡してTwitterアカウントとの連携を行う "攻撃者がTwitterに登録したConsumerKey/Secretとそれを使って取得した誰かのToken/Token Secretの組み合わせを持っていれば、好き勝手にアカウント連携とかログインとかできる"という問題がありそう で、前回私の調査が足りなかったのかその対応が行われたのか定かではありませんが、アプリ開発者の設定により上記の問題への対策ができることに気付きましたので整理しておきま
「OAuth 2.0 (Implicit Flow) でログイン」の被害例 - OAuth.jp
。登場人物 OAuth 2.0対応してる某ゲームプラットフォーム 某ゲームプラットフォーム上で占いゲームを運営してる攻撃者 某ゲームプラットフォーム上で農園ゲームを運営してる被害アプリの開発者 某ゲームプラットフォーム上で無邪気に遊んでる被害ユーザ ※ 念のため、今回の話は特にゲームに限った話ではない。 前提 某ゲームプラットフォーム、農園ゲーム共に、XSS とか CSRF とかセッションハイジャックされるような脆弱性はない。 農園ゲームはプラットフォームが発行するAccess TokenをOAuth 2.0のImplicit Flowを使って受け取り、同じくプラットフォームが提供するProfile API (GET /me とか) にアクセスして、レスポンスに含まれる user_id をもとにユーザを認証している。 攻撃者は占いゲームのDBから任意のAccess Tokenを取得可能。
JavaScript だけでクロスドメインで POST メソッドを送る方法
JavaScript のみを使って、クロスドメインを実現しつつ POST メソッドでリクエストを送信する方法について解説します。 ここで解説する方法にはこんな特徴があります。 (2009-10-30 追記) iframe の unload のタイミングについて、重大な不具合がある可能性に気づきました。Chrome/Firefox において、2度イベントが発生している可能性が高いです。unload イベントを使わない場合は無関係です。結論が分かったら修正版をこのページで公開します。 (2010-01-29 追記) Chrome は大丈夫そうです。Firefox もカウンタ or フラグを使ってイベントを記録すれば大丈夫ぽいです。ちゃんと直せて無くてすいません。 XMLHttpRequest では不可能な、クロスドメインによるポストを実現している。 元になるページの文字エンコードの種類にかかわ
CSRFで強制ログインさせるというアイデア - ぼくはまちちゃん！
こんにちはこんにちは！！ 今日はCSRF脆弱性のちょっとした話です！ このCSRFってなにかっていうと、 サーバーへのリクエストを『誰かに勝手に送らせる』っていうセキュリティがらみの攻撃手法のひとつ。 わかりやすい例だと、 HTMLの画像タグを以下のようにしたページを誰かに教える。 <img src="何々SNSの足跡.php" width="1" height="1"> そうすると、そのページを「見た人」が何々SNSの足跡.phpにアクセスしたことになる。 ※詳しくはこちらのマンガで → ［はまちちゃんのセキュリティ講座］ここがキミの脆弱なところ…！ ： 第2回 しーさーふって何ですか？ CSRFってこんな風に、 「ログイン済みの人に何か操作させる」ってイメージが強くて、 対策する側もまた、「既にログイン済みの人を守る」ような考えが強いんだよね。 例えば、勝手に日記に投稿させないように対
開発者のための正しいCSRF対策
著者: 金床 <anvil@jumperz.net> http://www.jumperz.net/ ■はじめに ウェブアプリケーション開発者の立場から見たCSRF対策について、さまざまな情報が入り乱れている。筆者が2006年3月の時点において国内のウェブサ イトやコンピュータ書籍・雑誌などでCSRF対策について書かれている記事を調べた結果、おどろくべきことに、そのほとんどが誤りを含んでいたり、現実的 には使用できない方法を紹介したりしていた。そこで本稿ではウェブアプリケーション開発者にとっての本当に正しいCSRF対策についてまとめることとす る。また、採用すべきでないCSRF対策とその理由も合わせて紹介する。 ■あらゆる機能がターゲットとなりうる ウェブアプリケーションの持つ全ての機能がCSRF攻撃の対象となりうる。まずこのことを認識しておく必要がある。 Amaz
"なんちゃら iOS SDK" でありそうな被害例 - OAuth.jp
昨日の続き。「ソーシャルゲームなんて3000万人の特殊な人しかやってない」という意見もあるようなので、今日は iOS アプリ版。 登場人物 iOS SDK 出してるプラットフォーム iOS SDK と連携するプラットフォームの公式 iOS アプリ プラットフォーム上で "まっとうな" アプリを運営してる攻撃者 攻撃者が自作した攻撃用アプリ iOS SDK 使って開発された被害アプリ あいかわらず無邪気な被害ユーザ 前提 プラットフォームが提供する iOS SDK は、 プラットフォームが指定するカスタムスキーマ (ex. “xyz-connect://”) で始まる URI にアクセスすることで プラットフォーム公式 iOS アプリに access token 取得のフローを delegate し 公式アプリが被害アプリの指定するカスタムスキーマ (ex. “foobar-rowial:/
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
