- この文章と、それに含まれる考察や各サービスへの脆弱性報告などはmala個人の活動であり、所属している企業とは関係ありません。
- 執筆時点で未修正の不具合や、過去に修正済みで運営元が開示していない脆弱性情報なども含みますが、公益を意図しています。
2020年の年末に、スマホ向けのLunascapeとSleipnirに対して、以下の問題を脆弱性として報告した。
Chrome ExtensionのLive HTTP Headersを調査した。Firefox用のものではない。Firefox用のものではない。
11/7追記
Summary in english.
/* | |
// mxhr.js | |
// BSD license | |
var mxhr = new MXHR; | |
mxhr.listen(mime, function(body){ process(body) }); | |
mxhr.listen('complete', function(status_code){ ... }); // 2xx response | |
mxhr.listen('error', function(status_code){ ... }); // other case | |
mxhr.open("GET", url, true); // or mxhr.open("POST", url, true); | |
mxhr.send(""); |
use strict; | |
use Net::Twitter; | |
use MongoDB; | |
my $nt = Net::Twitter->new( | |
traits => [qw/API::RESTv1_1/], | |
consumer_key => "xxx", | |
consumer_secret => "xxx", | |
access_token => "xxx", | |
access_token_secret => "xxx", |
https://gist.github.com/mala/5062931
の続き。
Twitterの人に色々と問題点は伝えたんだけど、これからOAuthのサーバー書く人や、クライアント書く人が似たような問題を起こさないようにするために、どうすればいいのかについて簡単に書きます。既存の実装真似して作るとうっかりひどい目にあう。
自分は意図的に「Twitterの脆弱性」という表現を使わないように気を使っていて、それはクライアントアプリ側の責任もあるからなのだけれども、安全に実装するための方法がわかりにくかったり誤解を招きやすかったり、Twitterに買収されているTweetDeckにも問題があったりしたので、それはやっぱりTwitter側の責任の比重が大きいとは思う。とはいっても別に責任を追求したかったり◯◯はクソだといったことを言いたいわけではなく、誰が悪いとか言う以前に、複合的な要因によって問題が起きるときには原因を正しく理解する必要があると思う。
説明するのめんどい http://vividcode.hatenablog.com/entry/twitter-oauth-vulnerability
とりあえず即座に攻撃できるような状態ではなくなっています。
** アクセス解析の類を設置するサイト運営者の一般的な想定 | |
http://www.ninja.co.jp/rule/analyze | |
図1 | |
訪問者 → 忍者ツールズ → 業務提携先 | |
↓ | |
サイト運営者 | |
この場合、業務提携先、業務委託先に「忍者ツールズが知っているデータ」の中で「忍者ツールズが第三者に提供しても大丈夫だと考えている情報」が共有されることになる。 | |
それは利用規約とかプライバシーポリシーに、統計データのみとか、個人を特定できないようにするとか、必要な範囲でとか、守秘義務を結んだ上で、とか書かれるのが一般的。 |