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

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

とりあえず、外部サイトの画像を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パラメータを変更することで、画像にかぎらずいろいろなページを取得できる状態のようです。

あかん。オープンプロキシになってる。http://t.co/QtUgZZfiNs @gunosy_news @piyokango “Gunosyの修正対応と謎のアクセスログとの関係” http://t.co/4qJ12ptRey

— やなぎぃ (@yng_hr) 2014, 5月 14

修正

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

ただし、リファラを見ているだけのようなので、リファラにhttp://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 サーバーからのアクセスのようでした。

アクセスの回数が多い

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

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

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

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

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

ユーザーエージェントに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月の問題発生時（リダイレクトでリファラが遮断されていなかった問題）同様、かなり早かったと思います。前回が本当に早かったので、今回も素早く対応されるんじゃないかと思っていました。

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

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

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