開發者保證產品數據和業務安全是基本責任之一。我工作以來從事開發以娛樂、社交、內容產業的APP產品為主，這里總結一下自己用到或者了解的移動應用常見網絡安全策略。

篡改數據

客戶端通常會保存uid，訪問接口時傳入uid告訴服務器是誰訪問。那么引出了最初級的安全問題，如果我們僅僅只信任uid那一旦修改這個參數值就可以篡改別的用戶數據了。

• 使用token，在用戶登錄成功服務端返回uid和token，客戶端訪問服務器時提供這兩個參數，uid區別唯一性，token驗證合法性。這樣即使修改了uid，對應的token不一致也無法成功。

• 使用https，https傳輸過程中數據是加密的，使用https可以防止用戶在網絡傳輸中途截取和修改。

  https分單向和雙向驗證，簡單說明這兩個概念：單向驗證即客戶端確認服務端是真的，雙向驗證即在此基礎上服務端驗證客戶端是真的。一些客戶端開發者可能還做過忽略證書的https請求，其實就是忽略單向驗證直接相信服務端是真的。

竊取數據

比如密碼的重要性不言而喻，下面談談如何保證密碼或重要數據不被泄露。

• 可還原加密。適用于如用戶隱私、財產信息等需要還原的數據。對稱加密，加解密使用的是同一個秘鑰，推薦AES，除此外還有DES、DES3等。不對稱加密，加解密使用不同秘鑰，如RSA。

• 不可還原加密，也叫數據摘要。適用于如用戶密碼這樣不需要還原的數據。如MD5、SHA1等。

  用戶密碼管理 tips

  1.在數據庫只保存密碼摘要
  2.多次摘要，比如進行3次MD5，或者MD5后再進行一次SHA1摘要等方式混合摘要
  3.加點salt(鹽)，有的攻擊者收集常用的密碼，然后對他們執行MD5或者 SHA1，使用大量數據做成龐大的數據字典，對泄露的數據庫中的密碼逐行對比，如果你的原始密碼很不幸的被包含在這個數據字典中，那么就能把你的原始密碼匹配出來。salt 是任意字母或數字的組合的隨機字符串，每個用戶注冊時生成不同的salt，保存方式如md5(密碼明文+salt)。

• 使用https，在上面已經提過。這里再提一點就是https同時使用到了對稱加密、非對稱加密、信息摘要3個手段。有興趣可以上網搜索https的基本原理。

模擬數據

如果攻擊者知道你的接口參數，有可能模擬這些數據修改提交或者批量提交。例如攻擊者中途拿到密碼密文雖然他不知道這些是什么鬼，但是拿到這個參數直接丟給服務器依然是合法的，再例如一些批量刷搶購活動，或者有好事者沒事對一個接口不斷重復提交數據。防止這些行為其實問題就是如何對參數進行合法性、時效性設置問題。

• 圖片、短信驗證碼。

• 參數簽名機制。首先服務端和客戶端各自保存一個key，客戶端請求服務器時將所需參數按一定順序排列+key組合字符串后摘要作為摘要參數一起提交到服務端，服務端將除摘要參數之外的參數按相同順序排列+key組合字符串摘要，匹配摘要值，如果一致則是合法請求。拿獲取我的資料接口舉例：

  1.服務端和客戶端持有相同key=abcdefg，該接口有uid、token兩個參數，我們需要增加一個timestamp參數，值為當前時間戳。假設uid=1,token=higklmn。
  2.請求服務端時，按參數名字典序排序+key結果timestamp=1234567890&token=higklmn&uid=1&abcdefguid，對這串字符串進行sha1之后得到ee6ef06d0770306f8868f20d7678e14a031bd23e，作為一個新的參數sign.最終提交的參數有timestamp、token、uid、sign這四個。
  3.服務端拿到參數后去掉除sign外的參數按照同樣的方式排序組合摘要，得到的值和sign的值匹配，一致為合法。

  做了簽名之后參數將無法修改，時效性就好判斷了，服務端處理完業務后有需要的可以將sign值保存，下次有相同的sign視為已經處理過的請求，不再處理。還可以判斷timestamp值，若與當前時間相差太久也視為過期請求。

結束語：移動應用網絡安全的防范介紹了大部分，其實還有很多需要我們去注意去解決的問題。和做架構一樣，項目的安全性不是靠設計出來而是一步一步隨著項目壯大而完善的。如果你的產品還沒有遇到攻擊或者還沒有做安全措施，這篇文章應該會對你有幫助。