關於PHP寫入APP介面的安全性問題探討一-php教程-PHP中文網

在探討這個問題之前，先要確認一點的是，作為一名互聯網Coder，無論你是前端或後端你都要對http請求要有一定的了解，知道http特性，要清楚的了解http裡面的Request與Response是什麼，知道為什麼網站會存在cookie，session，驗證碼的意義和必要性。因為探討APP接口的安全性就是在探討HTTP請求的安全性；

我一般把APP接口分為三類，普通接口，表單接口，會員接口；本文重點討論會員接口

普通接口

一般GET請求，例如獲取新聞列表GET http://Example.com/index.php?module=news&action=list，為了防止採集或暴力查詢，我們PC端一般做如下處理:

防止本站被它站file_get_contents，所以要辨識user_agent，如果不是透過瀏覽器來存取的話直接不給看。
如果別人透過偽造user_agent來存取的話，就透過單位時間ip的存取量來控制抓取方，可以寫一套演算法，如果再一個ip在前後一分鐘多於多少次訪問量來處理。但是，會有一種情況，即某個小區或公司內都是使用某一個IP的外網的話，這樣搞就會自尋死路，所以還要配合瀏覽器中的cookie來處理
總結: 請求頭可以偽造，IP位址可以變更，cookie可以清空，基本上PC端是很難防這個問題的，例如淘寶，點評等大站的資料我也是常去採的。

那APP端如何處理這個問題呢?我們可以抓點評APP的http請求包來看一下:

<code>GET http://114.80.165.113/mapi/ugcuserfeeds.bin?filtertype=5&userid=129059048&token=73114c7e9a4485319542039cdff854d989f61e5821d306b3abf0fc9904eb51ff&start=0 HTTP/1.1
Host: 114.80.165.113
Accept: */*
pragma-appid: 351091731
pragma-newtoken: c2032338f6abf96c8e2984db1655f2bac73b88f799e49aab4a426d414f994b5f
pragma-token: 73114c7e9a4485319542039cdff854d989f61e5821d306b3abf0fc9904eb51ff
pragma-dpid: 9214560561001942797
pragma-device: 566fe5aeb75a827967fbad8356608134ba98a4a6
Proxy-Connection: keep-alive
pragma-os: MApi 1.1 (dpscope 7.5.0 appstore; iPhone 8.3 iPhone7,1; a0d0)
Accept-Language: zh-cn
network-type: wifi
User-Agent: MApi 1.1 (dpscope 7.5.0 appstore; iPhone 8.3 iPhone7,1; a0d0) Paros/3.2.13 </code>

登入後複製

當你直接訪問http://114.80.165.113/mapi/ugcuserfeeds.bin?filtertype=5&id? =129059048&token=73114c7e9a4485319542039cdff854d989f61e5821d306b3abf0fc9904eb51ff&start=0的時候,直接從伺服器端擋住或直接從伺服器端給一般x,我們也可以在設定項中根據與客戶端開發人員約定的某些自訂的Request頭資訊,例如上面的parama-*,在伺服器設定項中可以取得到這些自訂的Request頭資訊,然後根據是否為約定好的Request資訊,如果不是就rewrite到450;
關於PHP寫入APP介面的安全性問題探討一但是,我們透過抓包既可獲得全部請求頭資訊,這時可以完全模擬請求頭資訊來獲取數據;

很多APP最多到此步既可獲得該API接口的數據,而且是非常便於處理的json格式,而評論APP到此處直接返回的是一堆看上去是經過壓縮的亂碼數據: 關於PHP寫入APP介面的安全性問題探討一

這有點類似於PC端gzip，伺服器端返回的是gzip的壓縮數據，而瀏覽器來解壓這個gzip來獲取真正的數據，然後再顯示出來;
我不知道點評的這個亂碼數據是否也是這個原理，如果是的話，不得不說真的是"棒棒噠"，因為解壓的算法是發生在自己的APP端，這不僅保證了資料的安全性，而且還節省頻寬流量，加快的資料傳輸速度。具體是怎麼樣做的，暫時還不得而知；關於PHP寫入APP介面的安全性問題探討一
表單介面

即類似html中的from表單，主要是往伺服器提交資料的。一般是post方式的http請求，主要的危險是來自於強刷HTTP請求，撐爆資料庫;在PC端我們一般透過驗證碼來解決這個問題,而在APP端,我能想到的也只有透過驗證碼的方式,只不過PC端的是把驗證碼存進session,而APP端是存進cache裡面；但如果加上驗證碼的話，在用戶體驗上肯定會大打折扣，關於這一點肯定有更好的方式解決，具體怎麼解決，暫時還不得而知；

會員接口

所謂會員接口，就是類似

http://Example.com/index.php?module=users&action=info&user_id=333

的請求，然後伺服器端直接根據user_id來做相應的會員操作，這是及其危險的接口處理，等於把當前的會員系統全暴露出來了,只要對方改一下user_id既可操作所有會員對應的接口。

通常在PC端，我們是透過加密的cookie來做會員的辨識和維持會話的；但是cookie是屬於瀏覽器的本地儲存功能。 APP端不能用，所以我們得透過token參數來辨識會員；而這個token該如何處理呢？首先,先說說在做該介面加密前，我一共經歷的四個方案：

方案一

與APP端開發人員約定特定的md5組合演算法，然後兩端比對一下，如果相同就allow ，不相同就deny；

但是，這也是不安全的，如果APP程式被反編譯，這些約定的演算法就會暴露，特別是在安卓APP中，有了演算法，完全就可以模擬介面請求通過驗證；

方案二
資料庫會員表的password是帶上了隨機密竄並經過雙重加密的md5值;在用戶登入的時候,我回會員對應的uid和password,password雖然是明文的,別人知道也不能登入,畢竟是經過加密的,然後每次請求接口的時候user_id=333&token=aa37e10c7137ac849eab8a2d5020568f,通過主鍵uid可以很快的找到當前uidomple 到然後比對非常匹配的,抓包的人雖然不能透過密文密碼來登入該會員,然而一旦知道了這個token,除非用戶更改密碼,否則也可以一直透過這個token來操作該會員的相關介面;

方案三

通過對稱加密演算法，該加密演算法對
uid+網站公鑰進行時效加密，在一定時效內可用。當會員登入成功時，伺服器端對該ID加密後返回給客戶端，客戶端每次請求介面的時候帶上該參數，伺服器端透過解密認證；但是這樣做，也是不安全的。因為，防外不防內，聽說這次的攜程宕機就是因為內部離職人員的惡意操作。內部不懷好意的人員如果知道相應的算法規則後，就算沒有數據庫權限，也可以通過接口來操作相關會員；

方案四

會員登錄的時候請求登錄接口，然後服務器端返回給客戶端一個token ，該token產生的規則是
網站公鑰+ 當前uid + 當前時間戳+ 一段隨機數雙重加密，根據需求決定是把該token放進cache等一段時間自動失效，還是放進資料庫（如果要放進資料庫的話，單獨拎出一張表來，順便記錄用戶的登錄，登出時間），在用戶登出登錄的時候改變一下，確保該token只能在用戶人為登出登錄之間有用。 為保安全，應確保讓使用者在一段時間內自動退出；此方案配合Linux和資料庫的權限管理可以防外又防內；

其他介面開發的注意事項

以上就介紹了關於PHP寫APP介面的安全性問題探討一，包括了方面的內容，希望對PHP教程有興趣的朋友有所幫助。