情報科学屋さんを目指す人のメモ

方法・手順・解説を書き残すブログ。私と同じことを繰り返さずに済むように。

Gunosyの漏洩問題修正による謎のアクセスログ(compute.amazonaws.com、Go 1.1 package http)

Gunosy (7) セキュリティ (62) プライバシー (4) 個人情報 (6)

Gunosyユーザーの興味関心情報が外部サイト管理者に漏洩する仕組みと想定される悪用例」で紹介した問題の対策が実施されていることを発見したので、その対策について紹介します。

また特に、昨日の午後から、Amazon AWSのIPアドレス(54.255.93.94)から、謎の大量アクセスが来るようになったけれど、ユーザーエージェントが「Go 1.1 package http」だし、リファラは空白だしで、原因がわからない!一体どこからのアクセスなんだ!と思っているサイト管理者に対する答えになるかもしれません。

一昨日指摘した問題点

詳しい問題点の説明は、前述の記事を読んでください。非公開設定のGunosyユーザーであっても、そのユーザーの「Facebookアカウント名」・「IPアドレス」・「Gunosyのアルゴリズムで推薦された記事」の組が外部の人に漏れてしまう、というお話です(一例なのでリンク先を読むように)。

gunosy-img-access-referrer-log-sample

とりあえず、外部サイトの画像をimgタグで【直接】読み込んでいる部分を修正すれば、とりあえず問題発生を防げる、というのがポイントです。

修正内容

5/13 15時頃より、imgタグの画像URLを指定する部分「src=...」が、次のように変更されていました

Before:「src="http://did2memo.net/wp-content/uploads/2014/05/ilovemusic-ranking-2-300x300.png"」

After:「src="http://imageproxy.gunosy.com/_img_rd?u=http://did2memo.net/wp-content/uploads/2014/05/ilovemusic-ranking-2-300x300.png"」

簡単にいえば、直接ユーザーのウェブブラウザが画像を取りに行かずに、gunosyのサーバー(imageproxy.gunosy.com)が、画像を代わりに取りに行くので、外部サイトと直接やり取りするのはGunosyのサーバーとなり、外部サイトにはGunosyのサーバーの情報しか漏れない、という仕組みです。当然今回問題にしたリファラは遮断されており、漏れ出ることがない、ということになっています。

詳しいところまで見ると、imageproxy.gunosy.com からのレスポンスヘッダには「Via: 1.1 varnish」とあり、高速でシンプル(らしい)リバースプロキシサーバー Varnish が使われていることが分かりました(1.1とありますが、Varnishのバージョンが1.1だというわけではないようです)

公開プロキシ状態(追記)

URLパラメータを変更することで、画像にかぎらずいろいろなページを取得できる状態のようです。

修正

これについて、修正が入りました。現在は、Gunosyのプロキシを通じていろいろなサイトを見る、ということは出来ないようになったようです。

ただし、リファラを見ているだけのようなので、リファラにhttp://gunosy.com/ を設定することで、引き続き閲覧可能です。

プロキシ(imageproxy.gunosy.com)からのアクセスの特徴

この imageproxy.gunosy.com のIPアドレスが 54.255.93.94 だったので、当ブログのアクセスログからそのIPアドレスで検索すると、次のアクセスログが発見されました。

「54.255.93.94 - - [13/May/2014:99:99:99 +0900] "GET /wp-content/uploads/2014/05/ilovemusic-ranking-2-300x300.png HTTP/1.1" 200 71601 "-" "Go 1.1 package http"」

対象ファイルにも矛盾がなく、確かにその imageproxy.gunosy.com サーバーからのアクセスのようでした

アクセスの回数が多い

このアクセスログは、画像の初回取得の1回ずつなどでは全くなく、かなりの数が残されていました

つまり、 imageproxy.gunosy.com から、何度も何度もアクセスが来ていた、というわけです(ただし、ログだけからすぐ imageproxy.gunosy.com からだ、ということは分からない→後述)。

すでにこの時点で、Gunosyに掲載されたニュースから数日経ったので、私のブログへのgunosyからのアクセスは既にだいぶ減っていたのですが、それでも同じファイルに7秒間しか間隔が開いていないアクセスがありました

対象はニュースのサムネイル画像なので静的ファイルです。変更される可能性はありますが、まず変更がないので、長めのキャッシュを行うのかと思ったのですが、そういうわけでもなさそうです。

※修正対応から1日経過しつつある5/14現在、ブラウザのキャッシュを切って繰り返しアクセスしてみたところ、こちらのサーバーへのアクセスはその回数より少なかったので、全くキャッシュをしていない、というわけではないようです。ただ、短いものだと2秒間隔のアクセスが来ました。ちょっと仕組みがよくわかりませんでした。

ユーザーエージェントにGunosyという文字なし→謎アクセス

また、ユーザーエージェント(通常、ブラウザの種類やバージョンが書き込まれる部分だが、私はGoogle-botのクローラです、のようなことを宣言する場所でもある)に目を向けてみると、ユーザーエージェントが初期設定のままなのか何なのか、gunosyからのアクセスであるということが表明されていませんでした

ユーザーエージェントは「Go 1.1 package http」となっており、Gunosyからのアクセスなのか、これだけでは判別できません。

ちょっとぐぐってみても、このUAが何に起因するものなのか、すぐには分からなかったのですが、Varnishを使う上での、何かしらの初期設定なのだと思われます(わざわざこのUAに設定したわけではなさそう)。分かる人は教えてください。

IPアドレスからは、Amazon EC2だとはわかるが…→謎アクセス

また、そのIPアドレスを逆引きしても、わかるのは「ec2-54-255-93-94.ap-southeast-1.compute.amazonaws.com」止まりでした。これまたGunosyからのアクセスなのか、わかりません。

修正を知らない人からは謎アクセスにしか見えないかも

というわけで、私はGunosyの修正対応を調べた流れだったので最初から「ログの原因はGunosy」とわかったのですが、この修正対応のことを調査している人以外がアクセスログを最初に見ても、「何だこの画像への大量アクセスは。AWSとしかわからないし、リファラ空白だし、UAはGo 1.1 package httpっていう謎だし、一体何なんだ?」となってしまい、「ログの原因はGunosy」とすぐにはわからないのではないかと思います。

というわけで、もしこんなアクセスが昨日の午後から急に出現していることに気がついていたら、それはGunosyからかもしれないので、チェックしてみてください

おまけ:もし遮断してしまったら

思いつきで書いておくと、Varnishや周辺を含めた挙動がわからないのではっきりとはわかりませんが、この同一IPアドレスからの大量アクセスをサーバー側で遮断してしまっていたとしたら、それが原因でGunosyに画像が表示されない、なんてことが起こるかもしれません。こっちのNginxの設定を追加すれば実験はできますが、面倒なのでやめておきます。

対応の早さと修正漏れ、とその修正漏れに対する修正

修正の早さは去年11月の問題発生時(リダイレクトでリファラが遮断されていなかった問題)同様、かなり早かったと思います。前回が本当に早かったので、今回も素早く対応されるんじゃないかと思っていました。

ただ、対応が早い一方で、修正漏れ(ドメイン名にそもそもリダイレクト自体が挟まっていなかった問題)が残っていたりして、ちょっとチェックが不足しているのかな、という気もしていました。なぜなら、その修正を見て、すぐ修正漏れに自分が気が付けたからです。

一昨日の記事で一緒に指摘しておいたからだと思うのですが、画像のプロキシ対応とともに、今回修正されていました。

あとは、今回の修正に、漏れがないか、なかったらいいな、と思うばかりです。少し見てみた感じ、同様の問題は一斉に塞がれたようで、単純な漏れはなさそうでした。

コメント(0)

新しいコメントを投稿