關於介面安全，
一般非常簡單的作用，只是使用者驗證，即合法性檢查。我乙個老同事一直這樣用
,個人感覺也未嘗不可
。每次請求
介面的時候 驗證下access_token，比如這個token是個
md5值，再在這個值上面加幾個隨機數，這這值就不是md5的值了，可破解的難道就大大增加了。 if
($_post
['access_token'
]!=$access_token)
系統安全
的使用，據說使用這個有一定的成本，包括客戶端執行效率成本和費用成本（需要向
ca申請證書
）。除非高要求的，一般不會採用這種方式。具體怎麼用，還不甚了解，需要學習學習。 1，
傳輸過程中的安全問題
為了防止在不安全的網路環境下傳輸的資料被截獲和篡改，api 介面必須使用 https 協議
（網上抄的，感覺不是很對，什麼叫必須）。
2，客戶端的安全問題
在客戶端對資料進行對稱加密再提交的意義是非常有限的，因為key被暴露在客戶端**中。如果一定要加密，可以使用非對稱加密演算法。客戶端加密的主要目的是避免關鍵資料以明文儲存於記憶體甚至磁碟中，防止這些資料被使用者篡改。 3，
服務端的安全問題
這個問題涉及面太廣，關鍵就是不要信任任何從客戶端提交上來的資料（無論你的客戶端設計得多麼天衣無縫），每乙個引數都要做校驗。
實際開發中，乙個同事的做法是，
md5加密當前日期，他再解密，這個應該是認證，但是資料並沒有加密。
Web安全之CSRF攻擊
csrf是什麼？csrf cross site request forgery 中文是跨站點請求偽造。csrf攻擊者在使用者已經登入目標 之後，誘使使用者訪問乙個攻擊頁面，利用目標 對使用者的信任，以使用者身份在攻擊頁面對目標 發起偽造使用者操作的請求，達到攻擊目的。舉個例子 簡單版 假如有個加關注...
Web安全之CSRF攻擊
源文位址 csrf是什麼？csrf cross site request forgery 中文是跨站點請求偽造。csrf攻擊者在使用者已經登入目標 之後，誘使使用者訪問乙個攻擊頁面，利用目標 對使用者的信任，以使用者身份在攻擊頁面對目標 發起偽造使用者操作的請求，達到攻擊目的。舉個例子 簡單版 假如...
Web安全之CSRF攻擊
跨站點請求偽造 cross site request forgery 攻擊者盜用合法使用者的身份，傳送惡意請求到伺服器，然而對伺服器來說，請求是完全合法的，於是伺服器在完全不知情的情況下完成了攻擊者所期望的操作。首先使用者瀏覽並登入了受信任站點a，通過站點a驗證後，授權資料儲存在站點a產生的cook...