2014-12-17

feedmeter サービス終了のお知らせ (訂正：存続するようです）

お知らせ

2004年にローンチしてから早10年、ついにこの日が来たかという感じですが、2014年12月31日をもって feedmeter のサービスを終了させていただくことにしました。

フィードメーターは私がサイボウズで働いている時代に趣味で開発したサイトです。

リリースして翌日には100万アクセスを突破、アクセスの多さにレンタルサーバー会社から怒られたのもすごく昔の出来事のような気がします。

このサービスがきかっけで「もっとたくさんの人に使ってもらえるようなサービスを作りたい！」と思い独立まで至ったので、いろいろと感慨深いものがあります。

今のツイキャスがあるのもこのサービスとブロガーさんたちのお陰なのでいろいろ感謝ですね。これがなかったらツイキャスはもちろん、IT界隈の人たちとのつながりもなかったんじゃないかなと思います。

ということで、フィードメーターは2014年末をもって終了させていただきます。

※ feedmeter が存続することになりました。詳細は後日！

フィードメーターを長らく愛用いただき、ありがとうございました！

2013-04-05

Facebookがいきなり実施したセキュリティ対策でログインできなくなるWebアプリたぶん多数

多数あると思います。ていうか、俺、ひっかかった。

掘っていくと、ここ数日に実施されたセキュリティ対策らしく、app secret と client secret が同一の場合、https://graph.facebook.com/oauth/access_token がcode認証受け付けなくなる、という問題です。

ここに情報載ってます。

BugsThe request is invalid because the app secret is the same as the client token

これにひっかかると、ヘッダに

WWW-Authenticate: OAuth "Facebook Platform" "invalid_request" "The request is invalid because the app secret is the same as the client token"

って書かれて400エラー返します。わはは。

で、そもそも「client secret なんて使ってるの？」って話しで、今の Facebook の SDK 使ってる人は誰もこれ使ってないと思います。

が、そこが罠で、最初にアプリ登録したときに、「なんかわかんないから Client Secret 生成しとけ」ってやった人、アウトです（最近は大丈夫みたいだけど）。

なんと、以前生成された Client Secret は App Secret と同一の文字列を返す仕様になっており、今になって「あ、それ、セキュリティ的にまずいから認証落とすわ」ってなったわけです。使ってないのに。。

ということで、Client Secret 生成してしまって、あれーWebでログインできなくなってるよーーって人は Client Secret を再生成すると直りますので、やってみるといいと思いますよ。

＃この罠の解決には1.5時間かかりました・・・

2013-03-22

Appleのサーバー認証を通過するアプリ内課金のクラックツールが出回っているらしい

アプリ内課金のクラックツールで有名なのは iAP Cracker で、これは偽署名を作成することで「サーバー側認証を行なっていない」実装のアプリについてアプリ内課金を回避ししてしまうツールです。

urus のリポジトリにあるやつが有名で、これを使うとデフォルトで Transaction ID が「com.urus.iap.xxxx」になるので、まぁもろバレなわけですが・・・。

iAP Cracker については、iOS 6.1 で Apple が対策をいれたため使えなくなりました。

代わりに「LocalIAPStore」というものが出まわってます。ただ、これも「サーバー側認証」されるとダメなので、アプリ開発者がちゃんとサーバー側で認証していれば問題ありません。

ところが、最近サーバー側認証を回避するアプリ内課金のクラッキングツールが出回っているようです。

アプリ内課金のサーバー認証では、iPhoneなどでアプリ内課金を行った際に発行される「レシート」というものをサーバー側で「Apple のレシート認証サーバー」に渡して、このレシートが正しいものかどうか判定しています。

で、このツールは「正しいレシート」を作成することで、サーバー認証を通過してしまいます。

どうやって「正しいレシート」を作成するかというと、全く関係ないアプリのアプリ内課金を使っています。

以下、そのレシートの内容。

{
"original-purchase-date-pst" = "2012-07-12 05:54:35 America/Los_Angeles";
	"purchase-date-ms" = "1342097675882";
	"original-transaction-id" = "1700000xxxxx";
	"bvrs" = "1.4";
	"app-item-id" = "450542233";
	"transaction-id" = "1700000xxxxx";
	"quantity" = "1";
	"original-purchase-date-ms" = "1342097675882";
	"item-id" = "534185042";
	"version-external-identifier" = "9051236";
	"product-id" = "com.zeptolab.ctrbonus.superpower1";
	"purchase-date" = "2012-07-12 12:54:35 Etc/GMT";
	"original-purchase-date" = "2012-07-12 12:54:35 Etc/GMT";
	"bid" = "com.zeptolab.ctrexperiments";
	"purchase-date-pst" = "2012-07-12 05:54:35 America/Los_Angeles";
}

つまり、アプリにてアプリ内課金を実施すると、まったく関係ないアプリのレシートを送信してくるわけです。
で、これが（全部ではないのですが）たまに Apple の認証を通過してしまいます。non-consumable なんですかね。

※追記）成功率は非常に低いことがわかりました。ので、いたずらレベルですね。

この踏み台に使っているアプリはこちら。

https://itunes.apple.com/app/id450542233

bid にある通りなんですが、ZeptoLab というところが作ってるアプリですね。ここが仕掛けてるのか踏み台にされているのかはわかりません。ていうか、Google おすすめの有名パズルゲームなんで、踏み台にされてんでしょうね。

全然関係ないレシート送付して課金成功するわけないじゃんｗｗｗｗって思うかもしれませんが、レシートチェック後の product-id をちゃんと検証してないサーバーを狙った攻撃なんで、成功するところはあるでしょう。（ていうか、俺もちょっと落とし穴あって塞いだｗ）

なので、まぁ、iPhone のアプリ内課金では

- サーバー側でのレシート認証
- 認証後のレシートの product id などのチェック

が必須ですので、一応メモ。

＃ていうか、Jailbreak まわり詳しくないんで、詳しい人教えてくださいｗ