?
十月一的假期間，在知乎上看到一個問題《網頁游戲都有哪些安全問題？》， 我是一個網頁游戲開發者，對這個問題非常感興趣，印象比較深刻。當時是在游玩，也沒時間細看這個問題。后來，在微博上，有一位朋友的轉發，又讓我看到這個 問題，冥冥中，有種想回答的沖動。上周六時，研發部門內部周會時，聽到其他項目組的一個整型溢出問題，導致刷錢的bug，又讓我想起這個問題，更加堅定我 要回答這個問題的決心，總結一下這項目中，所有經歷過的webgame安全問題的經驗，以加固當前項目安全壁壘，避免損失。亦可分享給其他做 webgame研發的朋友，做交流探討。
知乎中的原問題是『網頁游戲都有哪些安全問題？』，我覺得不妥，我給改成了『網頁游戲都有哪些安全問題？如何做得更安全？』，同時，問題也從『大家 來研究探討一下，網頁游戲攻防技術。必定，這個話題很敏感。目前，網頁游戲已經很多了，會不會被黑產盯上？網頁游戲會不會被黑，數據庫會不會被拖庫』改成 了『大家來研究探討一下，網頁游戲攻防技術。必定，這個話題很敏感。目前，網頁游戲已經很多了，會不會被黑產盯上？網頁游戲會不會被入侵？入侵方式有哪 些？如何做好網頁游戲的入侵防御？挽救措施有哪些？如何才能最小化減少廠商損失？入侵方式有哪些？如何做好網頁游戲的入侵防御？挽救措施有哪些？如何才能 最小化減少廠商損失？』，更改的理由是『本文原提問者開篇提到「大家來研究探討一下，網頁游戲攻防技術。」，那么應該不光提到如何入侵，更應該提到如何防御，應該細心描述漏洞形成原理，規避方式，以提高研發者技能水平；應該詳細講解安全事件發生后，如何最小化減少廠商損失，減少用戶損失，保護游戲平衡。』，幸運的是，這個修改，被知乎通過了。對此，表示感謝。
在后來閱讀這篇提問以及回答時，已經有幾位網友回答了，多數是站在安全工作者角度上回答了這個問題。在這篇日志里，我將以webgame研發者角度，切合游戲業務模塊邏輯，從業務需求，數據庫設計，程序編寫，操作方式上來講解漏洞形成原理，規避方案，也歡迎大家討論。
登錄認證
近幾年，網頁游戲幾乎都是以聯運方式運營，意味著游戲服務器本身不保存用戶密碼，用戶登錄在平臺，通過平臺跟游戲服務器的接口對接登錄。接口做加密認證。 故webgame的帳號密碼安全問題，這里不提了。但登錄認證的hash字符串安全，也還是要注意的。比如登錄hash字符串的生效時間，hash字符串 的加密參數來源，比如包括用戶名、登錄IP，瀏覽器user-agent等數據，以防止改hash被泄漏了，也是很難通過服務器的驗證。
游戲充值
webgame的游戲充值流程，跟普通網頁充值流程一致，沒有特殊的地方，其不同點就是跟其他眾多平臺做聯合運營時，勢必要每個公司做接口對接，且接口規 范各式各樣，且游戲廠商沒有話語權，必須按照他們的接口規范來，這實在棘手。騰訊的充值接口的驗證方式，安全性做的較為突出，大約代碼：
| 02 | $signKey = array('openid','appid','ts','payitem','token','billno','version','zoneid','providetype','amt','payamt_coins','pubacct_payamt_coins'); |
| 05 | foreach($signKey as $key ) { |
| 06 | ????if (isset($data[$key])) |
| 08 | ?$sign[$key] = $data[$key];? //只有 GET里有的參數，才參與sig的計算 |
| 11 | ######開始生成簽名############ |
| 13 | $url = rawurlencode($url); |
| 18 | foreach ($sign as $key => $val ) |
| 20 | ????$arrQuery[] = $key . '=' . str_replace('-','%2D',$val); |
| 22 | $query_string = join('&', $arrQuery); |
| 23 | //4 以POST方式拼接 1、3 以及URL |
| 24 | $src = 'GET&'.$url.'&'.rawurlencode($query_string); |
| 26 | $key = $this->config->get('qq_appkey').'&'; |
| 28 | $sig = base64_encode(hash_hmac("sha1", $src, strtr($key, '-_', '+/'), true)); |
| 29 | if ( $sig != $data['sig'] ) { |
| 30 | ????$return['ret'] = 4; |
| 31 | ????$return['msg'] = '請求參數錯誤：（sig）'; |
| 32 | ????$this->output->set(json_encode($return)); |
在此基礎上，還可以做的嚴謹點：
- 增加隨機參數名、參數值。隨機參數名、參數值由聯運方隨機生成，按照參數名的字符串所屬ASCII碼順序排序，參數名、參數值均參與sign的計算，增加暴力破解密鑰(app key)難度。
- 增加回調驗證訂單號，金額信息。游戲充值服務器接收到充值請求時，反向到該平臺回調接口，確認此筆訂單有效性，以防止加密密鑰泄漏的問題。
遠程文件引入
在網頁游戲的研發中，多數都是使用框架來做，即使用REQUEST來的參數，作為請求文件名的一部分，來使用，那么很容易形成遠程文件引入的漏洞。在我們之前的游戲中，曾出現過一例這樣的漏洞問題。
| 1 | // Load the local application controller |
| 2 | // Note: The Router class automatically validates the controller path.? If this include fails it |
| 3 | // means that the default controller in the Routes.php file is not resolving to something valid. |
| 4 | if ( ! file_exists(APPROOT.'controllers/'.load('Router')->getDirectory().load('Router')->getClass().EXT)) |
| 6 | ?load('Errors')->show404('Unable to load your default controller.? Please make sure the controller specified in your Routes.php file is valid.'); |
| 8 | include(APPROOT.'controllers/'.load('Router')->getDirectory().load('Router')->getClass().EXT); |
| 9 | load('Benchmark')->mark('load_basic_class_time_end'); |
webgame中的遠程文件引入
從代碼以及案例圖中，可以看到對于REQUEST的參數沒有過濾處理，直接作為文件名來include引入的，故導致這種問題，類似上頁圖中QQ群 網站的漏洞。若PHP version < 5.3.4 ，還會發生Null(%00) 截斷的問題，帶來更大的安全問題。在我們新的項目中，我們更改了實現方式，我們游戲所有接口都會走gateway，gateway里，對控制器名做類名規 范的檢測處理，再在指定幾個目錄下做autoload加載文件，且還會對REQUEST的類名、方法用ReflectionClass反射類的處理，檢測 到類、方法、參數是否合法。一來避免『遠程文件引入』漏洞問題，二來便于前后端聯調時，拋出更詳細的異常，方便調試。下面為參考代碼：
| 01 | require_once CONFIG_PATH . "/auto.php"; |
| 02 | spl_autoload_register("__autoload"); |
| 08 | $view->error(MLanguages::COM__INVALID_REQUST); |
| 09 | $msg = new Afx_Amf_plugins_AcknowledgeMessage($val->data[0]->$messageIdField); |
| 10 | $msg->setBody($view->get()); |
| 14 | $a = new Yaf_Request_Simple(); |
| 15 | $a->setControllerName($method[0]); |
| 16 | $a->setActionName($method[1]); |
| 17 | $objC = new ReflectionClass($method[0]."Controller"); |
| 18 | $arrParamenter = $objC->getMethod($method[1]."Action")->getParameters(); |
| 19 | $arrRequest = isset($val->data[0]->body[0]) ? (array)$val->data[0]->body[0] : array(); |
| 21 | foreach ($arrParamenter as $objParam) |
| 23 | ????$parm = $objParam->getName(); |
| 24 | ????$bIsOption = $objParam->isOptional();??? //是否為可選參數 |
| 25 | ????if (isset($arrRequest[$parm])) |
| 27 | ????????$a->setParam($parm , $arrRequest[$parm]); |
| 29 | ????elseif ($objParam->isOptional()) |
| 35 | ????????$bCanCall = false; |
| 40 | ????$rp = $app->getDispatcher()->dispatch($a); |
| 41 | ????$msg = new Afx_Amf_plugins_AcknowledgeMessage($val->data[0]->$messageIdField); |
| 42 | ????$msg->setBody($view->get()); |
| 43 | ????$message->data = $msg; |
SQL 注入
SQL注入原理、方式，跟普通web應用一樣，沒什么特別的，在使用REQUEST來的參數時，過濾處理即可。可能在消息格式，以及注入操作簡便上，會蒙蔽研發人員的眼睛，被忽略掉了。比如我們項目的AMF消息格式，在前端界面沒出來之前，我們后端程序員一般使用Pinta來模擬操作，調試程序。前端界面出來之后，會使用Charles proxy來捕捉http請求。在這些過程中，請求接口、參數的構造，沒有普通web那么簡單。研發人員也容易忽略對請求參數的過濾，故很容易形成這種問題。形成原理見：《WEB開發安全與運維安全淺見》，防御方式做過濾處理，或SQL預編譯。
AMF消息格式的WEBGAME中的SQL注入
?
AMF消息格式的WEBGAME中的SQL注入
為了提高游戲服務器的吞吐能力，網頁游戲的架構也是一直在演變的。在之前以Mysql作為數據存儲的webgame架構中，其他節點都是可以水平擴 展，或者說依賴簡單粗暴的增加服務器來解決，單單作為唯一數據存儲中心，不能這么做。為此，很多webgame的數據存儲改用Nosql來代替，甚至 java、C/C++的游戲數據，直接在內存中操作，游戲關服時，才寫入到DB中。故SQL注入的問題，也會越來越少。
通訊協議與消息格式
網頁游戲雖然名字叫網頁游戲，但通訊協議并非全是http，也有很多使用socket，以及http+socket并用的做法。我們是http協 議+amf消息格式，以及socket并用來實現。在http與https的取舍上，我們考慮到ssl的啟用后，大量的ssl解密加密運算，勢必會增加服 務器大量的CPU計算壓力。而傳輸的內容，多數是游戲業務的操作，響應，是能接受被監聽嗅探的行為的(認證信息除外)。站在安全角度，這不能理解。但站在 產品角度，考慮一下 投入產出，然后選擇http通訊，也是可以理解的。socket在我們游戲中，除了在聊天應用上使用外，在一些組隊、幫派戰之類需要多個玩家之間同步數據 信息時，我們也會使用socket來推送數據。在使用socket作為所有業務傳輸的協議時，協議格式一般都是開源協議，比如msgpack、protobuf之類，或者自定義的協議。使用自定義協議時，務必檢測整個消息包的每一個參數，類型范圍，避免個別超大數值、邊界數值出現，導致主程序內存越界，以至于服務宕機，無法正常服務的情況發生。
金幣復制-整型溢出
上周周六開周會時，聽到其他項目組的一個關于整型溢出導致產生刷金幣的問題。在這里，我抽象該案例，分享一下。商城出售開啟背包格子的所需道具『梧桐 木』。在游戲中，用戶包裹格子數量一般都會作為一個收費點，一款游戲的格子大約為每行7格子，一共8行這樣。比如前面3行是默認開放的，第4行是收費的， 而且第一個格子所需品梧桐木的價格1個銀子，第二個梧桐木是2個銀子，第三個是4個銀子。依次類推，意味著這些梧桐木的價格總和其實就是一個第一項為1， 公比為2，項為35的等比數列。 當用戶選擇購買梧桐木數量大于31時，比如32-36中這些數字時，這些等比數列的和就是大于2147483647。(只是舉例，實際上不會以這樣的價格 出售物品)
在java中，4字節的存放int型變量的范圍是-2147483648至2147483647。在java、c的有符號int型中存儲時，數的最高位描述符號位，4字節共32位，除去最高位的符號位，剩下31位，每個位上能表示2個數字，4字節的有符號的整數表示范圍為:負整數2^31個，范圍為『-1至-2147483648』；正整數2^31個，范圍為『2147483647至1』。 比如下圖(注意十進制數字跟二進制表示的變化順序)：
當開啟格子數字為大于31時，比如32，那么所需費用就是2147483647個銀兩，再買點其他物品，湊成超過2147483647的數字，比如又買了3個銀子的其他道具，總共花費2147483650個銀子，在4字節的有符號int中表示出來的結果，變成符號位為1，即負整數。數值位為0000000 00000000 00000000 00000010，也就是10000000 00000000 00000000 00000010，對應十進制的-2147483646。 程序邏輯上，再判斷現有銀兩是否足夠支付此筆花費時，是通過的。當使用當前余額減去這筆花費時，將變成減去一個負數，那么實際上就是加上一個正整數。變成 了自己銀兩賬戶余額的增長。而余額字段類型是long，則正確的存儲了這些余額，溢出漏洞被利用。在C中，使用無符號的數值類型，即可完成數值類型溢出刷 錢的行為，但在java中，好像沒有無符號的類型。這也可以先確定所有參與計算的數值必須為正整數作為必要條件(游戲業務特性，游戲內所有數字，肯定全為 正整數，甚至都不包括零)，先做大小判斷，再做正正相加，不能得負；負負相加，不能得正。來判斷是否發生了溢出問題。在PHP中，不用擔心溢出問題。
金幣復制-并發請求
Rpg類型的網頁游戲中，多數都有道具出售的功能，直接賣到商店，以及道具材料從商店買入功能。當玩家同時針對買入、賣出兩個操作，瞬間大量并發請求時，在服務器的處理邏輯一般有分別的兩個進程處理，共享數據分別數據庫中的對應賬戶余額表，如下圖：
webgame買入、賣出并發請求處理
| 03 | $iBalance = $obj->getBalance('user1');? //余額50 |
| 05 | //UPDATE `role_gold` SET gold = 150 WHERE role_id = 1 |
| 06 | if(!$obj->setBalance('user1',$iBalance + 100)) |
| 11 | if (!$obj->delItems($items)) |
| 19 | $iBalance = $obj->getBalance('user1');??? //余額50 |
| 20 | //UPDATE `role_gold` SET gold = 0 WHERE role_id = 1 |
| 21 | if(!$obj->setBalance('user1',$iBalance - 50)) |
| 26 | if (!$obj->addItems($items)) |
賣出請求的處理進程為1，買入請求的處理進程為2。在進程1還沒將結果寫入到DB時，進程2也從DB讀取到余額為50。這是，兩個進程拿到的余額信 息都是50。進程1按照邏輯代碼，計算出剩余余額是150；進程2計算出的剩余余額是0。最后，不管那個進程最后寫入余額，都是錯誤的結果。(注：這里的 代碼邏輯操作，跟mysql事務無任何關系，事務只能保證單個進程的事務范圍內多條語句都正確執行，或回滾。比如能保證扣錢成功，且物品刪除掉的兩個語句 都正確執行。能保證其中之一的語句執行失敗時，都正確回滾。)
其實，在事物開啟時候，SELECT語句是否可以取到最新的數據，或者是否需要等待鎖釋放，取決于MYSQL的事務隔離級別。在MYSQL的事務隔離級別中，有一下幾種隔離級別：
- READ-UNCOMMITTED(讀取未提交內容)級別
- READ-COMMITTED（讀取提交內容
- REPEATABLE-READ(可重讀)
- SERIERLIZED(可串行化)
對于READ-UNCOMMITTED，可以讀取其他事務中未提交的數據，而且據說性能還高不到哪里去，幾乎沒有在實際應用中使用；對于READ- COMMITTED，在同一事務中，會因為其他事務隨時可能有新的commit，導致同一select可能返回不同結果。這個也不適合游戲業務；再說第四 個SERIERLIZED，只要事務開啟，所有其他查詢，均排隊等待該事務提交之后，對于上面提到的賣出買入情況，第二個事務的SELECT操作，不會立 刻返回，會處于鎖等待狀態，一直到前一個事務結束。這個隔離級別，雖然能避免上面的問題，但性能較差，一般不會去使用。而REPEATABLE-READ 隔離級別，也是mysql默認的隔離級別，從功能上，比較符合游戲業務需要，也應該是廣大webgame架構中mysql的默認隔離級別。
對于這個問題，你可能很快就給出解決辦法，把UPDATE語句改為UPDATE `role_gold` SET gold = gold + 100 WHERE role_id = 1或者UPDATE `role_gold` SET gold = 150 WHERE role_id = 1 AND gold = 100來解決，但這種多個事務同時操作修改多個表的多條記錄時，還容易引發死鎖問題，比如《webgame中Mysql Deadlock ERROR 1213 (40001)錯誤的排查歷程》。而且，當條件為跨表內數據是否存在，或者另外條件不在MYSQL中，而在其他網絡接口的響應中時，如何做呢？
金幣復制--邏輯漏洞
引用DNF的漏洞新聞 《利用網游漏洞狂刷游戲幣賺錢 玩家自曝3天賺17萬》
玩家曝出刷幣漏洞 一個游戲道具可刷400人民幣
該漏洞到底是什么?原來游戲中“云冪袖珍罐”這個道具，可以開出2件一樣的游戲裝備，還有極少幾率開出游戲幣，開出的裝備不值錢，但如果開出金幣了，則分 為5000萬、8000萬以及1億游戲幣。而1億游戲幣，按正常市場行情，可在交易網上賣400多元人民幣。據玩家稱，在游戲中，角色的裝備是需要用包裹 來存放的，不過目前角色的包裹最多只有48格，也就是只能存放最多48件裝備。漏洞就是利用包裹的有限空間，存放47件裝備(存放滿了又無法開罐子)，只 留下一格空位，而在開“云冪袖珍罐”出裝備時，就會因包裹空間不足，而導致開罐失敗，而罐子還存在。玩家繼續開罐，直到出現金幣，但金幣不會占據包裹的空 間，因此開罐成功，然后罐子消失。發現這個漏洞后，部分玩家狂刷游戲幣，然后馬上在第三方交易平臺出售游戲幣，兌換成現金。
這種問題，都是研發人員邏輯不嚴謹導致，這種問題，也較難發現。規避方式可以依賴下面提到的『運營數據監控』。
道具復制--背包整理
跟上面的賣出、買入一樣，同時穿裝備、整理包裹。在設計時，可能會將身上裝備設計在裝備表中；將不在身上的裝備，設計到背包表中。當同時進行穿裝備 跟整理包裹的請求并發時，也會發生跟上面賣出，買入的情況，線程1讀取DB，發現包裹里有這裝備，然后準備刪除背包表的這條記錄，當準備寫入到裝備表時， 另外一個整理包裹請求的線程來了，讀取了整個背包表，進行道具的合并、排序。這時，之前的線程將這個裝備寫入到裝備表，并刪除了背包表里的數據，并提交事 務。這個穿裝備的所有操作都是合理、正常，且正確執行的。但另外一個整理背包的線程讀取了之前的背包表里的數據，包括那件被穿上的裝備。 在游戲中，整理背包需要對可堆疊道具做堆疊操作的，意味著需要合并多個道具，刪除部分道具。這意味著這里的操作，當前cgi線程的內存中的數據，將都會以 覆蓋的形式，寫入到DB中，那么意味著，之前被穿到身上的那件裝備，也會重新被寫入到背包中。那就變成兩張表里出現了兩個相同唯一ID的相同屬性的道具。 玩家就可以把背包中的這個道具出售給其他玩家。
在java或者C之類程序中，數據放內存中的游戲，也會存在這個問題，除非做讀鎖，但讀鎖會帶來鎖等待，鎖等待會導致線程被占用，阻塞后面請求的處 理，堆積大量請求。導致系統負載升高，服務器繁忙，以至于無法響應。好了，大約理解道具復制的形成原因了嗎？這個問題，我們從根本原因想想，問題到底出現 在哪里？如何規避呢？細心的同學不難發現，對于穿裝備的操作結果，會對下一個請求產生影響的，當前操作未得到服務端響應之前，服務端是不能處理下一個響應 的。對此，我們做了響應處理鎖--『用戶并發請求鎖』。
用戶并發請求鎖的實現，php中session以文件形式存儲時，php會對session文件加鎖，不釋放(如果不特意執行 session_write_close)，知道當前響應完成。另外一個線程才可以正常讀取，這簡介的形成了單個用戶的并發請求鎖，但是，后面的進程一直 處于等待狀態，也會占用一個php-fpm進程，阻塞其他用戶的正常請求對php線程的使用。為此，我們使用NOSQL的K-V形式結構，以 user_name為key的形式，實現用戶并發請求鎖，第一個請求，生成這個k-v數據，后一個請求發現有這個key了，那么立刻拋出異常，結束響 應，FLASH根據異常內容，提醒用戶不要進行惡意操作。即不會發生并發請求，又不會阻塞請求處理。同時，在請求結束的析構函數里，對這個鎖進行刪除操 作，不影響下一個正常請求。若因為程序異常，發生語法錯誤，導致析構函數沒法執行，沒有刪除用戶鎖時，可以在生成鎖的時候，設置過期時間，比如5秒，甚至 2秒，利用nosql的過期機制，實現用戶解鎖，避免用戶長時間無法正常游戲。
類CC攻擊-多用戶共享資源鎖的timebomb
我們現在研發的項目，是以NOSQL Redis作為DB，來存儲數據的，redis并沒有成熟的事務處理機制，watch甚至算不上關系型數據庫中的事務處理。對此，更需要對表進行加鎖解 鎖。java之類語言的項目，很多都是直接操作內存的，更是需要資源鎖，來解決并發問題，解決多個請求操作同一份數據的問題。公司有另外一個項目，出現過 一次因為鎖的顆粒度較大，帶來的鎖等待timebomb的問題，也導致了線程繁阻塞忙，請求堆積，系統負載上升，導致宕機的問題。這個項目的鎖是針對所有 用戶的鎖，每個用戶的請求發來時，當前線程會對所有用戶的數據加鎖，直到響應完成，才釋放掉。這么做，是為了解決因當前操作，會影響到其他用戶數據，比如 多人PK，多個玩家之間的交互。
當其他請求一并發來時，那么資源會立刻被鎖住，直到上一個請求結束，才釋放鎖，那么其他線程都處于等待狀態。用戶基數小時，是看不出來鎖帶來的影響的，內 存操作都比較快。當用戶基數大時，或者說請求數增大時，后面的請求的等待時間會越來越長，超過webserver的等待時間，直接返回timeout，不 能正常提供服務。
這種問題的發生，是因為鎖的顆粒太大了，不應該將所有用戶都鎖住，最好細化到當前請求所影響到的單個用戶，只鎖住單個用戶的數據。這樣，才減少timebomb的發生。
其他
知乎里的朋友提到，很多webgame 的前端做了判斷，而后端沒做判斷的問題，這種問題，實屬不該存在。在我們的項目中，后端做的驗證判斷，遠比前端多的多。有時候，為了界面上的動畫表現，前 端flash一般會在用戶操作之后，立刻渲染，然后，再根據后端響應，決定是否繼續做界面元素改動。比如脫裝備，玩家操作時，會先渲染裝備從角色面板，跳 到背包里的動畫，然后，再根據后端響應結果，決定是否回滾動畫。這樣，避免顯得操作后，一定時間的反映遲鈍假象，以提高用戶體驗。當然，后端是一定會做判 斷的，判斷角色背包是否有空格之類。現在的webgame研發，一般都不會存在前端判斷，而后端不判斷的做法了。如果有，也應該是個別遺漏情況。
比如去年的time33算法的hash dos的問題，使用json消息格式的webgame一定要注意，php只是在接收請求時，做了最大數量的限制。但在json解碼之后的數據中，是沒有處理的。這里千萬別忘記了。
運營數據異常監控
再完善的防御措施，都仍會有安全漏洞。適當的監控措施，也一定要有，監控等級、金幣、游戲幣、經驗、珍貴物品的變化等等，一旦發現，立刻報警，在漏洞未擴散之前，第一時間去修復漏洞，以減少損失，維護游戲平衡。
日志系統
日志系統一定不能漏掉，所有操作，必須寫入日志，當安全事件發生后，可以作為各種數據回滾，交易糾紛處理的可靠數據。也是作為數據監控的最準確的數據來源。
如果你用了我畫的小清新般的插圖，請記得為圖片寫上署名來源，畫圖是最花費我時間的一件事。
?
?
原文地址：http://www.cnxct.com/experience-with-webgame-of-security-and-defense/
轉載于:https://www.cnblogs.com/dasn/p/3373059.html
總結
以上是生活随笔為你收集整理的转:网页游戏都有哪些安全问题的全部內容，希望文章能夠幫你解決所遇到的問題。
如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。
