まだ書影が出ていないのですが、MacPeople2014年11月号は本日発売です。

載ったと同時に休刊です…

 

さて、紙面では長くなるので触れられなかった、「MBaaSだとなぜチートしやすいのか」を補足したいと思います。

 

MBaaSの弱点は、ゲームロジックがクライアント側に実装されていること

以下は紙面にも出ている、ゲームロジックがゲームサーバー側にある場合と、アプリケーション内にある場合の図です。

MBaaS-cheat-logic

 

ゲームサーバーがある場合、クライアントアプリからゲームサーバーに対して、ゲームの進行を進めるようにAPIを呼び出しています。これはブラウザベースのゲームではこの仕組みのものがほぼすべてだったと思います。

MBaaSを使う場合、サーバー側にはゲームロジックを入れることができませんので、アプリ側にゲームロジックを入れることになります。これがブラウザベースのゲームだった場合、JavaScriptでゲームロジックを作ることになると思いますが、ブラウザですので中身が丸見えになっています。

ブラウザ上のJavaScriptを改造して、本来ならありえないようなパラメーターをサーバー側に一度記録させれば、以後そのパラメーターで遊びつつけることが可能です。

ブラウザベースのMBaaSでチートを防ぐのは無理だと考えましょう。

ネイティブアプリでの対策方法

ネイティブアプリはブラウザベースに比べて、内部ロジックを改造する難易度は上がります。では、ゲームロジックがMBaaS側に送っているパケットを盗聴して中身を改変してみるのはどうでしょうか。

例えばSSLを使うことでインターネット経路上での盗聴は防げます。これにプラスして初歩的なセキュリティとして、API KEYやcookieを使ったセッション管理などと組み合わせているのが多いかと思います。

しかし、Cookieは複製してセッションハイジャックといったことが可能なため安全とは言えません。

 

もう少しセキュリティを上げる方法は無いでしょうか?最近ではJSONに署名をつけるJSON Web Tokenという手法があります。

これは、cookieのセキュリティトークンをより高度にしたもので、HTTPヘッダーに付与することで通信の真性度を保証するものです。

以下はJWTを使ったWeb APIアクセス図のサンプルです。

JWT

まずClientは「これからWebAPIにアクセスするのでユーザ識別IDが埋め込まれたTokenをください」と通知します。するとServer側はユーザーを識別出来るIDを動的に作成して(DBの中のIDを使ってはいけません)、それを秘密鍵で署名したものと公開鍵をClientに返します。この動的に作ったIDはmemcacheなどのKey-Valueストア系のサービスに記憶させておきましょう。

次にClientはWebAPIに対してのリクエストパラメーターをもらった公開鍵で署名して、先ほど受け取ったJWTをHTTPヘッダーに設定してServerに送信します。Server側は受け取ったHTTPヘッダーを確認して、含まれているJWTが自分が発行したものか検証します。ここで検証が正しければユーザーが特定できますので、クライアントから送られてきたリクエストを秘密鍵で復号してWebAPIに渡します。

気をつけることとして、動的に作成したユーザー識別IDは利用後は再利用せずに破棄しましょう。できれば秘密鍵も頻繁に更新することが望まれます。

こういった方法でそれなりのセキュリティを担保することができます。

 

このサーバー側にセキュリティトークンを発行させて、そのトークンを使ってデータを署名してサーバーに送信する、といった手法は、金融決済系ではよく使われている手法です。さらにIPアドレスで制限したりコールバックを使ったりなど、セキュリティを高めています。

スマートフォンの場合、コールバックは出来ないのですが、プッシュ通知を使うことでコールバックと同じことが可能になります。

本当にセキュリティが高い処理(例えば課金処理など)を行う場合は、プッシュ通知をコールバックとして使うロジックを使うといいでしょう。(※iOSの場合 Androidは頑張ればプッシュ通信すら抜き取れてしまいます)