この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは。
ご機嫌いかがでしょうか。
"No human labor is no human error" が大好きな吉井 亮です。
CEDEC2022 を聴講しています。セッションレポートをまとめました。
セッション
タイトル : チート行為とオンラインゲームセキュリティ
受講スキル：オンラインゲームのチート行為を防ぐ方法に興味のある方
受講者が得られるであろう知見 : 典型的な機能と実装に対する問題点と解決案
セッションの内容
オンラインゲームをフェアな環境にする作業として、チート対策は欠かすことのできないものになりました。
このセッションでは、主にサーバープログラムの設計・実装に焦点を当てて、典型的な機能と実装からくる問題点を取りあげ、解決案を示します。
講演者プロフィール
松田 和樹 様
所属 : 株式会社ラック
部署 : デジタルイノベーション統括部デジタルペンテスト部
講演された松田様は『オンラインゲームセキュリティ』の著者です。私も購入し何度も読んでいます。豊富な対策が具体的に招待されています。ゲームはもちろんゲーム以外のセキュリティ対策でも参考になると感じてます。
ラック社員による、書籍『オンラインゲームセキュリティ』が発刊
レポート
必須となったチート対策
チート対策、やらないといけないことは分かっている
- どうやればいいですか
- どこまでやればいいのですか
- 誰が教えてくれるのですか
- 完璧なセキュリティは存在しない
- 前より少しずつ良くすることならできる
- 困難ではあるが、頑張ればできる
- 工数がかかる
- チームごとに練度がかなり違う (ノウハウ門外不出の弊害)
- やりたくないと思っている担当者もいる
所感
ゲーム会社は内製化が進んでいる。社内リソースに余裕がある会社はチート対策に取り組んでいるが、そうではない会社はどうしていいのか分からないのが実情と解説されていました。
チート対策は必要であるが、何をどうしたらよいか担当個人レベルでは理解の限界はあるだろうし、ノウハウが誰から提供されるわけではない辛さはあると思います。
チーターのほうも必死(?)で進歩していきます。それに追随して対策をすることも心理的なハードルとなり現場の負担になっているかもしれません。
チート対策に必要なコスト
対策するなら効果測定が欲しい
- 効果が見えないままではお金は出しにくい
- 効果測定はどうやってやるの？
- 対策すれば被害総額が売上に転換するのか？
- 対策すればユーザー離脱を食い止められるか？
- 対策をアピールすればユーザーは戻ってくるのか？
- 対策が終わった頃には飽きられているかも
- チート対策はコスト優先になってしまう
- どれだけ売れるか分からないからコストをかけられない
- (逆説的に) 売れてから対策する、もあり
攻撃と防御の非対称性
- チート対策してもゲームは面白くならない
- しかし、放置するとクソゲー化が進行
- 追加予算が発生したとして
- セキュリティに使うか？ゲームのブラッシュアップに使うか？
攻撃者と防御側ではスキルセットが違う
モチベーションも違う
- サラリーマンとしてのゲーム開発者
- 生活のために必死にチートしているチーター
- 時間は無限にある
- ゲームの仕様を最も理解しているのは開発者とは断言できない
所感
セキュリティ対策をやってもゲームが面白くなるわけでない、コストをかけにくい、という話はまさに大半のゲーム関係者が感じているジレンマだと思います。
いつどこからどの程度の規模で襲ってくるか分からないチーターに予算を割り当てるよりも、ゲーム自体の機能追加や体験改善に予算を回すのは仕方がないことです。
ゲームが売れて予算が確保できるようになってから本格的なチート対策を行うのも一つの手段であるという解説されていました。
チート行為の端緒
クライアント側の設計・実装に問題がある場合
- クラックを試みる
- クラック対策ツールを導入する
サーバー側の設計・実装に問題がある場合
- ゲームの仕様・実装に反する通信をサーバーに飛ばす
- 実装・設計の見直し、診断テストの実施
チート対策ペネトレーションテストの概要
Tangible ROI through Secure Software Engineering
- 工程別セキュリティとコスト
- 設計：コスト1
- 実装がないので机上分析
- 開発：コスト6.5
- 実装が終わったものから逐一診断
- テスト：コスト 15
- 設計と実装に対する診断、リリース前なのでまだ間に合う
- 運用：コスト 60～
- 実害が発生していればインシデント調査が含まれるのでコストが大きくなる
- 設計：コスト1
ゲームセキュリティ診断の分類
- ブラックボックス診断
- 現存するゲームアプリの動作・解析を端緒として問題点を見つける
- 仕様が明確ではない前提で実施する (チーターと同じ条件)
- NDAが煩雑にならない
- 開発現場への負担が少ない
- チーターと同じ条件なのである意味実情に近い
- 近視眼的な成果までしか出ない
- チーターの最大の武器である人海戦術に対抗できない
- ゲーム仕様を熟知しないと見つからない脆弱性はほぼ見つからない
- ソースコードや仕様書が渡されてないため、具体的な指摘ができない
- ホワイトボックス診断
- 仕様書・設定情報・ソースコードを受領する
- サーバープログラムも診断対象
- 診断員はゲームをプレイし、ソースコードも読んで内部実装を把握する
- 事象の確認と指摘だけではなく、解決案まで提示できる
- 実装ではなく設計に問題がある場合は妥協案を提示できる
- 診断の効率をあがるためにソースを読む
- 第三者がチェックするため、ソースコードの品質も評価できる
- NDAの締結がほぼ必須
- ソースコードを外部に出すことが前提
- ゲームエンジンを内製している会社はなおさら
- コストは明朗会計とはいかない
- 開発者からの寛大な協力が必須
- 環境を構築するために開発者の手を借りる
- 仕様書・設定情報・ソースコードを受領する
所感
クライアント側とサーバー側の両方で対策が必要です。それぞれによって対策が異なります。
ゲーム開発工程のフェーズによって行えるテストとコストが変動します。モダンなセキュリティ対策はシフトレフト、つまり初期のフェーズから対策を実施することは重要だとされています。 フェーズが進めば進むほど対策にコストがかかり、影響範囲の把握が困難になると考えます。ゲーム開発においても早い段階でセキュリティ対策を行うべきだと感じました。
事例と対策 パラメータのチェック不備
- 指示とパラメータが対になっている
- 例えばガチャ1回なら「Gacha=1」など
- ガチャの回数に負数を指定する
- 内部実装が悪いと負数を指定されると異常な処理になる
- 「-1回回す」はあり得ない
- 異常な処理の結果がプレイヤーにとって有益になる → チート (不利益になれば仕様)
- 不完全な実装だと「-1回回す」ごとに石が増えていくなど例
- パラメータのチェックを厳密にする
- クライアントから指定されるパラメータはすべて改造可能だと思う
- サーバー側で受け取るときに厳密チェック
- 指示の仕様を見直す
- 1回と10回のガチャなら、1か10以外エラーにすればいい
事例と対策 排他制御不備
1個しかないアイテムを2個拾われたら
適切な排他制御がなされていない処理に複数リクエストを送る
アイテムの二重受け取り(「アイテム売却」「レシート使用」など想定シーンは無限にある)
- 端末を2つ用意し、2つとも同じアイテム受け取り画面を開く
- 同時に受け取る
アイテム受け取り一連の処理
- アイテムを受け取っていないか調べる
- 受け取ったアイテムをデータベースに保存する
- アイテムを受け取り済にする
一連の処理に対して排他制御が行われていない場合、アイテムが2個受け取られてしまうことがある。
- データベースにおけるトランザクション処理を理解したうえで適切な実装が必要となる
- フレームワークを使えばコードを書けてしまうが、知識としては必要
- 不測の事態に備えて、後から検証できるログを取る
- データベースのロールバックで巻き戻せるか？
アイテム二重使用のケース
- 端末を2台用意するか。パケットを送信できる環境を用意する
- 一方はアイテム合成、もう一方はアイテム売却のように
- ゲーム内資産が発生するすべての箇所になるため、影響範囲が広い
所感
チートはやられる前提で対策を行うことが重要だと感じました。
パラメータチェックでは、整数であることのチェックの他にも想定している値以外は受け取らない(ガチャなら1 or 10 など)という実装が参考になりました。
Web セキュリティは多層防御が基本だと考えています。アプリケーション側でのパラメータチェックに加えて、インフラ側では WAF や DDoS 対策を導入することが大切です。
排他制御は「言うのは簡単、やるのは難しい」という対策の一つだと考えています。
松田様の「フレームワーク等使えば実装できるが開発者の知識としては必要」という言葉は心に突き刺さりました。
チートに対する対策もそうですが、チートされてしまった後の調査にも知識が必要だと感じてます。
登壇者のまとめ
3
