網頁遊戲都有哪些安全問題？如何做得更安全？
大家來研究探討一下，網頁遊戲攻防技術。必定，這個話題很敏感。目前，網頁遊戲已經很多了，會不會被黑產盯上？網頁遊戲會不會被入侵？入侵方式有哪些？如何做好網頁遊戲的入侵防禦？挽救措施有哪些？如何才能最小化減少廠商損失？
謝邀。。。。 壓根沒人邀請我，好像這個詞成為知乎的通用開篇詞語。
十月一的假期間，看到這個問題，當時沒怎麼在意。幾天後，在微博上，又看到這個問題，冥冥中，有種想回答的衝動。上周六時，研發部門內部周會時，聽到其他項目組的一個整型溢出問題，導致刷錢的bug。這更加堅定我要回答這個問題的決心，拯救地球的任務，就交給我了。以下是在下經歷過的webgame安全問題的經驗，定有不妥指出，還請各位斧正。如果覺得幫助了你，亦可分享給其他做webgame研發的朋友，做交流探討。
原問題是『網頁遊戲都有哪些安全問題？』，我覺得不妥，我給改成了『網頁遊戲都有哪些安全問題？如何做得更安全？』，同時，問題也從『大家來研究探討一下，網頁遊戲攻防技術。必定，這個話題很敏感。目前，網頁遊戲已經很多了，會不會被黑產盯上？網頁遊戲會不會被黑，資料庫會不會被拖庫』改成了『大家來研究探討一下，網頁遊戲攻防技術。必定，這個話題很敏感。目前，網頁遊戲已經很多了，會不會被黑產盯上？網頁遊戲會不會被入侵？入侵方式有哪些？如何做好網頁遊戲的入侵防禦？挽救措施有哪些？如何才能最小化減少廠商損失？』，更改的理由是『本文原提問者開篇提到「大家來研究探討一下，網頁遊戲攻防技術。」，那麼應該不光提到如何入侵，更應該提到如何防禦，應該細心描述漏洞形成原理，規避方式，以提高研發者技能水平；應該詳細講解安全事件發生後，如何最小化減少廠商損失，減少用戶損失，保護遊戲平衡。』，幸運的是，這個修改，被知乎通過了。對此，表示感謝。
前面安全專家@餘弦 站在安全工作者的角度，回答了這個問題。下面我將以webgame研發者角度，切合遊戲業務模塊邏輯，從業務需求，資料庫設計，程序編寫，操作方式上來講解漏洞形成原理，規避方案，也歡迎大家討論。
登錄認證
近幾年，網頁遊戲幾乎都是以聯運方式運營，意味著遊戲伺服器本身不保存用戶密碼，用戶登錄在平台，通過平台跟遊戲伺服器的介面對接登錄。介面做加密認證。故webgame的帳號密碼安全問題，這裡不提了。但登錄認證的hash字元串安全，也還是要注意的。比如登錄hash字元串的生效時間，hash字元串的加密參數來源，比如包括用戶名、登錄IP，瀏覽器user-agent等數據，以防止改hash被泄漏了，也是很難通過伺服器的驗證。
遊戲充值
webgame的遊戲充值流程，跟普通網頁充值流程一致，沒有特殊的地方，其不同點就是跟其他眾多平台做聯合運營時，勢必要每個公司做介面對接，且介面規範各式各樣，且遊戲廠商沒有話語權，必須按照他們的介面規範來，這實在棘手。騰訊的充值介面的驗證方式，安全性做的較為突出，大約代碼：
$signKey = array("openid","appid","ts","payitem","token","billno","version","zoneid","providetype","amt","payamt_coins","pubacct_payamt_coins");
$sign = array();
//從GET參數中，對比找出上面參數的值
foreach($signKey as $key ) {
if (isset($data[$key]))
{
$sign[$key] = $data[$key]; //只有 GET里有的參數，才參與sig的計算
}
}
######開始生成簽名############
//1: URL編碼 URI
$url = rawurlencode($url);
//2:按照key進行字典升序排列
ksort($sign);
//3: 拼接，並URL編碼
$arrQuery = array();
foreach ($sign as $key =&> $val )
{
$arrQuery[] = $key . "=" . str_replace("-","%2D",$val);
}
$query_string = join("", $arrQuery);
//4 以POST方式拼接 1、3 以及URL
$src = "GET".$url."".rawurlencode($query_string);
// ## 構造密鑰
$key = $this-&>config-&>get("qq_appkey")."";
//### 生成簽名
$sig = base64_encode(hash_hmac("sha1", $src, strtr($key, "-_", "+/"), true));
if ( $sig != $data["sig"] ) {
$return["ret"] = 4;
$return["msg"] = "請求參數錯誤：（sig）";
$this-&>output-&>set(json_encode($return));
return ;
}
在此基礎上，還可以做的嚴謹點：
- 增加隨機參數名、參數值。隨機參數名、參數值由聯運方隨機生成，按照參數名的字元串所屬ASCII碼順序排序，參數名、參數值均參與sign的計算，增加暴力破解密鑰(app key)難度。
- 增加回調驗證訂單號，金額信息。遊戲充值伺服器接收到充值請求時，反向到該平台回調介面，確認此筆訂單有效性，以防止加密密鑰泄漏的問題。
遠程文件引入
在網頁遊戲的研發中，多數都是使用框架來做，即使用REQUEST來的參數，作為請求文件名的一部分，來使用，那麼很容易形成遠程文件引入的漏洞。在我們之前的遊戲中，曾出現過一例這樣的漏洞問題。
// Load the local application controller
// Note: The Router class automatically validates the controller path. If this include fails it
// means that the default controller in the Routes.php file is not resolving to something valid.
if ( ! file_exists(APPROOT."controllers/".load("Router")-&>getDirectory().load("Router")-&>getClass().EXT))
{
load("Errors")-&>show404("Unable to load your default controller. Please make sure the controller specified in your Routes.php file is valid.");
}
include(APPROOT."controllers/".load("Router")-&>getDirectory().load("Router")-&>getClass().EXT);
load("Benchmark")-&>mark("load_basic_class_time_end");
從代碼以及案例圖中，可以看到對於REQUEST的參數沒有過濾處理，直接作為文件名來include引入的，故導致這種問題，類似上頁圖中QQ群網站的漏洞。若PHP version amp;< 5.3.4 ，還會發生Null(%00) 截斷的問題，帶來更大的安全問題。在我們新的項目中，我們更改了實現方式，我們遊戲所有介面都會走gateway，gateway里，對控制器名做類名規範的檢測處理，再在指定幾個目錄下做autoload載入文件，且還會對REQUEST的類名、方法用ReflectionClass反射類的處理，檢測到類、方法、參數是否合法。一來避免『遠程文件引入』漏洞問題，二來便於前後端聯調時，拋出更詳細的異常，方便調試。下面為參考代碼：
require_once CONFIG_PATH . "/auto.php";
spl_autoload_register("__autoload");
......
//默認消息格式
$view-&>clear();
$view-&>error(MLanguages::COM__INVALID_REQUST);
$msg = new Afx_Amf_plugins_AcknowledgeMessage($val-&>data[0]-&>$messageIdField);
$msg-&>setBody($view-&>get());
$message-&>data = $msg;
...
$a = new Yaf_Request_Simple();
$a-&>setControllerName($method[0]);
$a-&>setActionName($method[1]);
$objC = new ReflectionClass($method[0]."Controller");
$arrParamenter = $objC-&>getMethod($method[1]."Action")-&>getParameters();
$arrRequest = isset($val-&>data[0]-&>body[0]) ? (array)$val-&>data[0]-&>body[0] : array();
$bCanCall = true;
foreach ($arrParamenter as $objParam)
{
$parm = $objParam-&>getName();
$bIsOption = $objParam-&>isOptional(); //是否為可選參數
if (isset($arrRequest[$parm]))
{
$a-&>setParam($parm , $arrRequest[$parm]);
}
elseif ($objParam-&>isOptional())
{
//可選參數
}
else
{
$bCanCall = false;
}
}
if ($bCanCall)
{
$rp = $app-&>getDispatcher()-&>dispatch($a);
$msg = new Afx_Amf_plugins_AcknowledgeMessage($val-&>data[0]-&>$messageIdField);
$msg-&>setBody($view-&>get());
$message-&>data = $msg;
}
SQL 注入
SQL注入原理、方式，跟普通web應用一樣，沒什麼特別的，在使用REQUEST來的參數時，過濾處理即可。可能在消息格式，以及注入操作簡便上，會蒙蔽研發人員的眼睛，被忽略掉了。比如我們項目的AMF消息格式，在前端界面沒出來之前，我們後端程序員一般使用Pinta來模擬操作，調試程序。前端界面出來之後，會使用Charles proxy來捕捉http請求。在這些過程中，請求介面、參數的構造，沒有普通web那麼簡單。研發人員也容易忽略對請求參數的過濾，故很容易形成這種問題。防禦方式做過濾處理，或SQL預編譯。
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中，好像沒有無符號的類型。這也可以先確定所有參與計算的數值必須為正整數作為必要條件(遊戲業務特性，遊戲內所有數字，肯定全為正整數，甚至都不包括零)，先做大小判斷，再做正正相加，不能得負；負負相加，不能得正。來判斷是否發生了溢出問題。
金幣複製-並發請求Rpg類型的網頁遊戲中，多數都有道具出售的功能，直接賣到商店，以及道具材料從商店買入功能。當玩家同時針對買入、賣出兩個操作，瞬間大量並發請求時，在伺服器的處理邏輯一般有分別的兩個進程處理，共享數據分別資料庫中的對應賬戶餘額表，如下圖：
//賣出
// startTrans
$iBalance = $obj-&>getBalance("user1"); //餘額50
//UPDATE `role_gold` SET gold = 150 WHERE role_id = 1
if(!$obj-&>setBalance("user1",$iBalance + 100))
{
//rollback
}
//扣除物品
if (!$obj-&>delItems($items))
{
//rollback
}
//commit
//買入
// startTrans
$iBalance = $obj-&>getBalance("user1"); //餘額50
//UPDATE `role_gold` SET gold = 0 WHERE role_id = 1
if(!$obj-&>setBalance("user1",$iBalance - 50))
{
//rollback
}
//發放物品
if (!$obj-&>addItems($items))
{
//rollback
}
//commit
賣出請求的處理進程為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的形式，實現用戶並發請求鎖，比如 redis的setnx介面，原子性判斷操作有則返回false，，沒有就添加一個，返回true。那麼，對於下一個請求，setnx時，返回false，有這個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解碼之後的數據中，是沒有處理的。這裡千萬別忘記了。
運營數據異常監控
再完善的防禦措施，都仍會有安全漏洞。適當的監控措施，也一定要有，監控等級、金幣、遊戲幣、經驗、珍貴物品的變化等等，一旦發現，立刻報警，在漏洞未擴散之前，第一時間去修復漏洞，以減少損失，維護遊戲平衡。
--------------------------------10-16 21:08補充---------------------
日誌
日誌系統一定不能漏掉，所有操作，必須寫入日誌，當安全事件發生後，可以作為各種數據回滾，交易糾紛處理的可靠數據。也是作為數據監控的最準確的數據來源。
補一個真實的故事。去年6月份，我們項目新上線一個系統，以及騰訊充值介面V2升級V3，涉及充值代碼改動，研發測試、策劃測試、QA測試完畢之後，上線到個別服務區，觀察情況。每次新版本上線，整個項目組都會持續觀察數據情況，尤其是充值總額， 10、50、100的漲，突然，總額下降了。充值總額下降了，這可是總額啊，只能增加，是不會下降的。肯定哪裡有BUG，DBA直接看binlog，查充值記錄相關的SQL語句，最後發現充值系統的sql語句為UPDATE table set gold_num = $num,is_pay =1 ，沒有WHERE，沒有WHERE啊，多麼弱智的BUG，這尼瑪能容忍么？肯定要拉出來，彈JJ彈到死。當我從SVN日誌中看到涉及這個文件的修改者時，我立刻石化了，悄悄的修了bug，默默的上傳......
事情是發生了，原因很弱智。是我自己，忘記寫where條件，由於框架封裝了，問題並不容易被發現。而且自己測試充值都是正確的，包括後來的策劃測試、QA測試，都沒有發現問題。所屬功勞，就是「數據監控系統「，所以，我們遊戲開發商，第一時間，比用戶還早的發現了問題所在。數據監控，一定必不可少。
至於修復方案，那要感謝日誌系統。每筆充值，都有雙份日誌，一是各個遊戲大區自己的DB中。二是充值中心中。充值中心負責跟其他各大平台對接。這次的事故，影響遊戲大區的數據，並未影響到充值中心數據，故可以有據可查。這樣，偉大的DBA可以更便捷、放心的修複數據了。對此，不管發生其他刷錢、刷裝備、盜號之後的交易糾紛，都可以依賴日誌來做處理。日誌系統，也一定必不可少。
從新功能發布，到發現BUG，到修復BUG，總共歷時不到1小時(svn時間可以看出來，16：30對外的)，可想而知，數據監控的效果多麼值得稱讚。新功能上線時，各個測試環節要去做。按大區伺服器，做灰度發布也可以更小的減少bug影響範圍，減少損失。
---------------------------------10月22日 更新------------------------------------------------
協議與外掛
本問題的目標是『網頁遊戲』，『網頁』意味著的用瀏覽器。使用瀏覽器與伺服器通訊的遊戲，才能成為瀏覽器。而瀏覽器支持普通的http協議的基本網頁數據通訊，支持以socket協議的flash插件或者java Applet實現，以及unity3D開發的遊戲。就目前業界流行做法上，flash插件做客戶端的佔了一多半。unity3D的客戶端源碼安全性我不清楚。flash的源碼，眾所周知，很容易逆向出來。比如回答者@Seraph 提到博客 Seraph"s Blog 中所寫方式逆向還原出flash源碼。當源碼很容易被拿到後，那麼通訊協議的消息格式，也是一覽無餘，那麼各種外掛實現起來，易如反掌。
- 策劃初期，減少重複性勞動的玩法，以免玩家感到疲勞，給與外掛市場。若重複性不高，那麼外掛可用性也就差。
- 遊戲本身提供一些內掛，替玩家實現重複性勞動。
- 前後端都是統一網關，後期實現協議加密也比較簡單，快捷。抵擋住初級外掛編寫者，當然，中國人才濟濟，大牛多多。
- 定時更換通訊密鑰，增加外掛編寫者的勞動量。
- 遊戲內部機制限制，比如體力值。
- 人肉判斷，驗證碼之類(網頁遊戲目前還沒火到這個地步)。
其實，網頁遊戲中的最大、最多的漏洞，幾乎都是遊戲業務金幣複製、裝備複製等技術性漏洞，以及遊戲業務判斷不嚴謹、條件不合法之類的邏輯漏洞，而常見的web漏洞在網頁遊戲里，顯得並不突出，種類數量也少，也較為容易發現，修復。
=============================2014年7月22日更新================
我不知道這個回答會不會還有人看到，因為這不是一個新的回復，不會出現在各位的消息提醒中，可能不會漲粉，但我覺得還是有必要在更新一下，希望以後通過搜索，看到這篇文章的同學，對你們有幫助。SO，我還是更新一下。
又一起webgame中的刷道具的問題，問題發生在背包內道具移動的業務上：
- 當從A位置移動到B位置時，若兩者是同一類型，且可疊加(兩者都是綁定或不綁定)，則疊加數量到其中一個上，並銷毀另外一個。
- 若不是同一類型，或不可疊加，則兩者呼喚位置。
- 若目標位置為空，則把物品從A移動到B。
如果這個功能由你看寫，你如何寫？
程序員的代碼在 gist:b7d794d3cb663dd86aad
/**
*
* 背包內道具移動
* @param string $former 源位置格子號
* @param int $target 目標位置格子號
*/
public function MoveItemAction($former, $target)
{
$former = trim($former);
$target = intval($target);
if(!$former || $target &< 1)
{
return $this-&>_view-&>error(MLanguages::COM__PARAMETERS_NOT_LEGAL); //參數異常;
}
//獲取道具信息
$former_item = $this-&>__mItems-&>getNumberItem($former);
if(!$former_item)
{
return $this-&>_view-&>error(MLanguages::PACK__NOT_EXIST); //使用道具不存在;
}
$former_md5id = $former_item["md5_id"];
$former_num = $former_item["number"];
$former_base = $former_item["item_id"];
$former_sup = $former_item["superpose"];
//開啟事務
$this-&>__mRole-&>beginTrans();
$target_item = $this-&>__mItems-&>getNumberItem($target);
......
其出現問題部分就是如上這些，大家看代碼時，會認為這前期的判斷都是正確的，符合業務邏輯的，問題卻發生了「來源格子」跟「目標格子」的判斷，沒有判斷這兩個參數是不是同一個位置，若是同一個位置，那麼上面的所有業務邏輯判斷都是合法的，下面的代碼中，將根據這「兩個」道具的屬性進行堆疊，然後就發生了道具複製的問題.....
修復方法想必大家都會，就是判斷來源位置目標位置是否相同if(!$former || $target &< 1 || ($former == $target)) //判斷來源位置目標位置是否相同
如果是你，你會犯這樣的錯誤嗎？
以上為鄙人的遊戲研發經驗，歡迎討論。時間倉促，再加上感冒前期癥狀，輕微頭暈，難免思維混亂，敬請諒解。 此回答禁止轉載，代碼高亮效果不理想，其他格式沒有。鄙人BLOG中文章 webgame中常見安全問題、防禦方式與挽救措施 可以轉載，但務必遵循博客所示協議。
@葛巾 大神能給個贊么？
這個得遊戲安全同學來回答更好，不過我說下我的一些hacking心得吧。
網頁遊戲分兩類：flash遊戲與html遊戲。
flash遊戲與服務端通信的消息格式有兩類：
1. 是flash特有的amf消息格式。這個格式是可逆的，一般外掛就會逆出這個格式，然後自動化。
2. http協議，這個導致的服務端安全問題和普通的網站基本沒什麼區別，因為此時服務端都是nginx, lighttp, apache, tomcat之類，服務端語言是：php, java, python之類。
我遇到的一些flash遊戲，相關邏輯在客戶端進行，缺乏服務端驗證，直接導致我可以無限金幣，無限裝備…開發者以為flash那麼厚，看不到運算邏輯，實際上要反編譯出源碼很容易，比如用swfscan，很多時候的攻擊直接在瀏覽器中間人抓包攔截，就更容易了:)
html遊戲
這個和服務端通信就是http了，如果用了html5，也許會用websocket。不過一般都是http協議，所以服務端安全問題和普通網站沒什麼區別。
由於是html，在客戶端上還可能出現XSS, CSRF等問題，這類客戶端安全問題可能導致用戶賬號被劫持等問題。
整體來說，搞網頁遊戲的攻擊成本更低。
最後補充下：早就被黑產盯上了。根本不用想，我最佩服黑產兄弟，他們比我們速度快N倍！非技術的扯幾句。
早期不少頁游研發技術實力都很一般，工期又緊，其實不用黑客哥哥出馬，自身就BUG一堆，各種被普通玩家刷錢刷道具，還有工作室打金，都很頭痛。所以導致頁游在安全性防備上，更多往設計上考慮「出了問題怎麼辦」「怎麼危害更低」。
目前不少頁游都傾向減低流通性（比如道具買賣、金幣買賣這些盡量少）流通性強一旦出問題稍微時間長點就會禍害整個伺服器，鬧不好要回滾數據，而不流通只要處理單一或一批賬號即可，對伺服器影響不大。
另外頁游運營要求強檢測、強數據分析，運營客服會盯緊，數據異常及時發現，後台數據分析要強，能還原問題；另外頁游的高端玩家覆蓋做的比較好，充值較高、排名較高的玩家都盡量覆蓋。所以萬一有黑客哥哥黑了系統，必然有所反應，估計沒多久就有玩家會說，有個人突然很厲害啊，又不說話，是不是托兒啊，結果內部一看，還真不是托兒。再一查收入，這哥哥沒充錢？或者收入對不上啊親，然後去找技術哥哥了…
個人感覺不如客戶端網遊安全。
這裡的安全指的是防禦入侵，釣魚，外掛的能力。
網頁遊戲因為 Web 環境的限制，不太可能使用太變態的通訊加密手段，大部分網頁遊戲還都是純 HTTP API 的形式，沒有加密和混淆，很容易抓包然後寫出腳本類(自動完成某些工作)的外掛。
按我的了解，大部分網頁遊戲都沒有使用SSL, 在不受信任的網路中很容易被抓包，竊取敏感數據，或者釣魚等等。
遊戲安全，看到這四個字，就讓我心裡突突，因為處理線上問題，每一次都實在是非常的棘手。
先說通訊協議，看前面有提到http和socket兩種，我們的遊戲全部都採用socket來當做通訊協議。
主要考慮以下2點：
http通訊可以採用xml 或者json，在通訊的可讀性上非常方便，但缺點卻在通訊上佔據了多餘的帶寬。
socket通訊協議在可讀性上比http差太多太多，但是只要在前後端在協議的封裝上做好了，遇到問題的時候，也就很容易了，可以彌補這一缺陷，不用每次都列印出二進位來分析，這簡直就是一件要人命的事情；在說效率,雖然http底層也是基於tcp/ip的，但在單台機器上,socket明顯還是比http快的，也降低了web單台伺服器的瓶頸以及多線程問題。
說完通訊協議，回到主題，遊戲安全。
遊戲的基本數據多是保存在內存中，玩家上線載入，存儲分三種（離線存儲、定時周期存儲、直接存儲）
對於socket的協議來講，SQL注入的問題可以忽略掉了，因為都是對內存數據的操作，所以不會外來數據影響。
我們遇到最多的問題歸根結底只有1個，程序不嚴謹。
玩家會通過遊戲的正常請求消息來做數據的分析以及後續的模擬。
由於我們的遊戲是socket協議，所以僅拿這個距離，玩家會通過wpe的工具或者其他記錄行為的工具來分析你client請求了什麼，server返回了什麼。
根據client的請求分析請求參數及請求動作。
比如：一個正常的操作通過如下3步完成，由A 觸發 B ，再觸發C.
玩家再操作一次後，記錄了這個操作，它可以任意的發送wpe數據請求C。而不通過正常的操作途徑到C。
這樣可能由於驗證不嚴謹，直接造成遊戲漏洞。。
這樣的問題，是通過正常操作測試測試不出來的。隱藏的比較深，而且在寫代碼的時候要時刻注意這樣的問題。
很多問題在正常情況下是會沒問題的，在測試的時候，一定要測邊界值，這點非常的重要。邊界值沒問題，數據正常的存儲，防禦性變成做的好一些，這樣產生的問題相對比較小。
一些重要的功能也可以設置開關
線上問題，能直接線上更新修改的，盡量別停服把，反正停服了，死定了，妥妥的。
至今三款遊戲，第一款所有的邏輯操作都在伺服器端，給了伺服器端太大的壓力。現在目前的項目中，客戶端做了所有它能做的邏輯判斷，伺服器只對操作以及數值做校驗，相對之前，省心了些。
順嘴再說一句，只要遊戲不做交易，開發的時候省心省一半！現在很多頁游做的時候都已經不做交易了，基本都可以理解為單機遊戲，沒有交易的遊戲不是好遊戲，至少降低了非常多的娛樂性及可玩性，現在只圖簡單。可以交易的遊戲在防禦型編程上要求更為嚴格，操著賣白粉的心啊！
再感慨~ 總之現在遊戲，無聊+坑，還累壞了我們的程序
1.協議方面不要輕易相信客戶端發的數據，只需要取出操作信息，比如購買道具，需要驗證是否出售道具ID，購買數量是否在有效範圍。
2.對於一些敏感介面就特別處理，比如區分加金幣和減金幣介面，從語義上做區分。
3.觀測數據統計，跟蹤異常數據。
-----
題外，大多頁游基本不設交易系統，實際上，對於賬號安全方面沒端游那麼嚴重，更多的就是業務上面的異常，程序邏輯上的錯誤是一個方面，同時策劃所配的配置文件也不能小視，把測試的文件一不小心部署到線上那就跪了。
推薦閱讀：