說明:基於前后端,尤其是使用Ajax請求的接口,現在市面上網頁上調用的Ajax基本都是沒有驗證的,如果單獨提取之后可以無線的刷數據。
繼上一篇http://www.cnblogs.com/EasonJim/p/6178402.html文檔所提到的Ajax請求的接口驗證問題,現在基本上有了解決思路了,就是JWT標准,注意,這個是一個標准協議,和oAuth這種協議類似。
JWT主要實現的Token機制,為每一個需要調用的接口生成驗證的Token,然后后端進行驗證合法性。
JWT是一個標准,那么實現這個標准的語言就非常多,比如C,C++,Java等,具體的參考官方提供的文檔即可。
生成原理:比如我們請求一個接口時,會使用JWT生成的Token,一同傳遞到后端進行驗證合法性,對於生成Token可以是頁面載入的時候寫到Cookie,或者寫到頁面的固定位置。
可能遇到的問題和解決方案:
1、如果基於Java Web系統,前后端沒有做分離時,基本頁面輸出使用了Java Web的模板引擎的,可以為輸出的頁面帶上生成Token字符串,然后這些Ajax請求全部帶上這個Token。
1.1、可能會出現這個Token暴露在頁面,然后用工具提取到,然后進行請求;對於這個問題可以這樣做,Token本身有過期機制,比如2個小時過期,這樣一般能杜絕絕對部分的請求。
1.2、再加強一下,比如請求的接口上做一個驗證,比如獲取請求時判斷上一個請求的頭上Referer值,看下是否為當前域名下的。
1.2、比如生成Token時,帶上請求的參數進行生成再輸出,這樣也就一個Token只能做一個參數的請求,也能杜絕掉一大部分的偽造請求。
1.3、對於生成Token,可以是單獨的接口,但這樣有點危險,可能會讓人提取去用,但是如果判斷只能當前域名下使用可能會有效。
1.4、也可以這樣生成這個Token,比如我們要訪問的B頁面,那么先請求A頁面再跳轉到B頁面,此時就會帶上Token在Cookie上,然后再請求。不過同樣也會被提取的風險。
1.5、學微信的做法,微信的前端JS做了Token的驗證,比如頁面上寫好AppID,然后Token是服務端生成好放入到頁面的,並且與域名進行綁定,如果域名變了,就無法使用這個Token請求。那么我們還是回到Referer的判斷上進行判斷,是否是本域名發出的請求。
2、如果是別的系統進行調用時,比如前后端分離的方案,需要使用到Ajax進行請求第三方接口的。
2.1、沒辦法,這個Token只能有后端生成好給你,然后你再使用它進行請求,並且第三方接口上也會判斷Referer的來源域名。
2.2、還是使用上面的A和B頁面進行跳轉,然后獲取Token,當然這個A頁面可以是第三方去做,然后針對域名寫Cookie。
3、綜上,基本上是生成Token要過期時間,要判斷請求的來源域名。、
4、針對Ajax是沒有絕對安全的,只能做到比較安全;最明顯的例子就是微信Web端,網上同樣針對微信的Web API進行抓包分析,然后實現了請求的。既然加了Token機制只是為了再復雜多一步,使刷包的人做多一步難的操作。
參考:
http://m.blog.csdn.net/zwz568017880/article/details/61197587