大話程序猿眼裏的接口

時間 2019-11-06

標籤大話程序眼裏接口简体版

原文原文鏈接

開場

魂淡別碰的孩子(接口), 做爲後端程序猿本身寫的接口就像本身的孩子同樣，盡然製造出來了，那就要對他之後的人生負責到底；
隨着業務的壯大，須要支撐業務接口也愈來愈多，使用的用戶量變大，虎視眈眈的黑客們視機而動，老是在業務中尋找着能夠竊取他人利益的入口，因此咱們應該多考慮安全性問題，防範於未然。前端

場景

服務端程序猿根據需求開發出業務相關的接口，用來知足需求中用戶和服務器交互的功能，提供給前端或者客戶端（PC端軟件，APP端應用）使用，大部分程序猿在開發接口的時候就僅僅去考慮如何實現業務上的邏輯功能，而每每不多會去考慮接口的安全性問題，通常服務端提供的接口都是http/https協議的，經過Fiddler，Wireshark，Charles等抓包工具，能夠抓取到請求，而後進行分析，模擬請求，進行併發請求，或者修改信息的攻擊。程序員

例子：

問題1. 接口暴露用戶隱私信息就至關於在光天化日下裸奔，被看光了

描述：程序猿在作業務接口的時候每每沒有保護用戶隱私的意識，把用戶的隱私信息暴露在外面，一旦被人利用起來會給用戶帶來麻煩，同時被發現會下降平臺的信任度；數據庫

防：

用戶隱私數據加密，加*號，如用戶的相關數據的JSON中有用戶手機號，用戶郵箱，支付帳號，郵寄地址等隱私數據；
用戶請求接口時須要對其隱私參數加密：如用戶登錄請求登錄接口，須要將用戶密碼進行可逆加密，以避免接口被惡意代理捕捉請求後獲取明文密碼；
分享出去的地址中不要用明文的用戶ID，或者用戶登陸的token

問題2. 接口暴露敏感信息，就像把鑰匙插在鑰匙口沒拔掉同樣，只要你會開門就能進去

用戶參與活動的數據JSON集合中不要有活動相關業務邏輯的決定性的數據,如：競拍出價活動，出價惟一最低者拿獎品，結果獲取出價的接口暴露了全部出價的價格統計結果。json

防：

數據中須要將敏感字段,或者對業務有着決定性做用的字段中的部分字符串加*;

問題3.數據被人順手帶走(主業務接口相關JSON數據如：首頁商品列表數據)

描述：接口中的JSON數據會被其餘人拿去作本身的相關的功能；這樣就形成了服務器的額外支出後端

防：

IP請求量限制，時間範圍內請求量限制，等各類限制IP請求的規則，
如：統計記錄(能夠記錄到mongdb中)，定時監控記錄發現請求量大於限制的數量就進行IP封殺;
請求頭的校驗，如：User-Agent 校驗請求頭是否是APP客服端發起，Referer 是否是有來源，來源域名是否是本身的域名地址等(這種方式只能是多一個門檻)；

描述：經過修改請求中的參數來發起的請求，如：登錄接口修改用戶名和用戶密碼，進行密碼庫碰撞等。安全

舒適提示：
修改請求參數可能會致使不少安全性問題，如：SQL注入，XSS 跨站腳本攻擊等，傳送門個人【大話程序猿眼裏的WEB安全】有相關的介紹和解決方案
如下方案都針對客戶端，如PC軟件和APP，WEB端JS去作加密的話不是很推薦，JS代碼是暴露出來的，因此若是用JS作加密必定要混淆JS代碼服務器

防：

增長一個簽名參數，將參數名進行邏輯的排序組合拼接+祕鑰MD5，而後服務端接受到請求的時候也用一樣的邏輯獲得簽名與簽名參數進行對比是否相同，這樣可使參數沒法被修改，修改了就提示非法請求。如：接口http://www.test.com/go/?actid=1&userid=123 咱們能夠加一個sign參數= MD5(actid=1&userid=123&【secret】)【secret】=祕鑰，本身定義。服務端用同樣的邏輯獲得密文和sign簽名進行對比是否同樣，不同就提示非法請求。cookie
整個參數內容進行可逆的加密
限制參數範圍，如：支持分頁接口，不少人會爲了方便使用，加了參數就是pagesize(一頁的數據量)，當沒有去限制頁碼最大值得時候，若是表數據量很大，而後攻擊者修改pagesize參數爲N萬，而後數據庫就奔潰了,相關業務就掛了。

問題5.影分身術，模擬請求，發起併發請求

描述：經過抓包工具抓到請求後模擬請求，如：模擬每日簽到請求，或者直接發起每日簽到的併發請求。
舒適提示：當請求併發後如何保證數據的完整性，一致性問題，這也是平時開發很須要注意的問題，傳送門個人【大話程序員眼裏的高併發】有相關的介紹和解決方案。併發

防:

模擬併發請求，IP限制同上問題2的解決方案。
請求信息帶上時間(可逆加密的時間)，服務端獲取時間，超過限定時間的返回請求超時(目的使抓取到的請求不是一直有效的)。
用戶token,等標識用戶重要的信息數據，保存COOKIE須要設置過時時間，或者加密的明文裏要有建立的時間，服務端作對應的時間失效的限制，這樣即便COOKIE被別人盜取，模擬請求也會隨着時間而失效;

總結

咱們須要提升本身的安全意識，防範於未然，要多站在攻擊者的角度來看本身的接口;(讓本身有一種被害妄想症的感受，你就離精神病近了一步，<(￣︶￣)↗ ) 不要作開發需求的機器人，咱們是有思想有創造力的開發者;高併發

附加我的開發流程

在評審需求的時候要把業務邏輯問題提出來，並給予解決方案的選擇;
肯定需求後將整個業務邏輯的梳理清楚，複雜的能夠畫出流程圖;
根據需求設計實現方案，須要考慮性能問題[數據庫壓力，服務器壓力]，安全問題，用文檔的形式記錄下本身的設計方案。（能夠深刻到代碼層面如何去實現）;
列出需求中功能點，評估出本身的時間，獲得總工時;
開始開發，開幹;