本篇文章給大家帶來的內容是關於php介面安全:php介面加密的四個方案,有一定的參考價值,有需要的朋友可以參考一下,希望對你有所協助。
作為一名互連網Coder,無論你是前端或者後端你都要對http請求要有一定的瞭解,知道http特性,要清楚的瞭解http裡面的Request與Response是什麼,知道為什麼網站會存在cookie,session,驗證碼的意義和必要性。因為探討APP介面的安全性就是在探討HTTP請求的安全性。
一般在PC端,我們是通過加密的cookie來做會員的辨識和維持會話的;但是cookie是屬於瀏覽器的本機存放區功能。APP端不能用,所以我們得通過token參數來辨識會員;而這個token該如何處理呢?
首先,先說說在做該介面加密前,我一共經曆的四個方案:
方案一
與APP端開發人員約定特定的md5組合演算法,然後兩端比對一下,如果相同就allow,不相同就deny;
但是,這也是不安全的,如果APP程式被反編譯,這些約定的演算法就會暴露,特別是在安卓APP中,有了演算法,完全就可以類比介面請求通過驗證;
方案二
資料庫會員表的password是帶上了隨機密竄並經過雙重加密的md5值;在使用者登入的時候,我返回會員相應的uid和password,password雖然是明文的,別人知道也不能登入,畢竟是經過加密的,然後每次請求介面的時候user_id=333&token=aa37e10c7137ac849eab8a2d5020568f
,通過主鍵uid可以很快的找到當前uid對應的token,然後再來比對;
但是這樣想法是too yang too simple的,抓包的人雖然不能通過密文密碼來登入該會員,然而一旦知道了這個token,除非使用者更改密碼,否則也可以一直通過這個token來操作該會員的相關介面;
方案三
通過對稱式加密演算法,該密碼編譯演算法對uid+網站公開金鑰
進行時效加密,在一定時效內可用。在會員登入成功時,伺服器端對該ID加密後返回給用戶端,用戶端每次請求介面的時候帶上該參數,伺服器端通過解密認證;
但是這樣做,也是不安全的。因為,防外不防內,聽說這次的攜程宕機就是因為內部離職人員的惡意操作。內部不懷好意的人員如果知道相應的演算法規則後,就算沒有資料庫許可權,也可以通過介面來操作相關會員;
方案四
會員登入的時候請求登入介面,然後伺服器端返回給用戶端一個token,該token產生的規則是 網站公開金鑰 + 當前uid + 目前時間戳 + 一段隨機數
雙重加密,根據需求決定是把該token放進cache等一段時間自動失效,還是放進資料庫(如果要放進資料庫的話,單獨拎出一張表來,順便記錄使用者的登入,登出時間),在使用者登出登入的時候改變一下,確保該token只能在使用者人為登出登入之間有用。
為保安全,應保證讓使用者在一段時間內自動結束;此方案配合Linux和資料庫的許可權管理可以防外又防內;
其他介面開發的注意事項
資料格式最好使用JSON格式資料,因為JSON有較好的跨平台性。在產生JSON的時候,要注意json的兩種格式:對象(字典) 與 數組;mobile端開發語言中沒有類似PHP中的foreach不能遍曆對象,只能遍曆數組,他們對對象的操作一般都是通過鍵名去取索引值。
不管是成功,還是失敗。介面必須提供明確的資料狀態資訊,並且不能返回NULL,如果返回NULL的話,在IOS端會崩掉。