對於前後端完全分離的網站,後端採用PHP/Java/Python向前端輸出json格式的資料,而前端通過ajax向後端調用介面擷取資料。這種情況下,後端的介面如果沒有採取一定的保護措施是很容易被其他人惡意調用來做一些非法操作。那麼,現在在這種前後端完全分離的網站架構下有哪些主流的對後端介面保護的做法?
回複內容:
對於前後端完全分離的網站,後端採用PHP/Java/Python向前端輸出json格式的資料,而前端通過ajax向後端調用介面擷取資料。這種情況下,後端的介面如果沒有採取一定的保護措施是很容易被其他人惡意調用來做一些非法操作。那麼,現在在這種前後端完全分離的網站架構下有哪些主流的對後端介面保護的做法?
1)給你API的使用者發放驗證Key,對請求的資料內容按雙方定義的規則結合Key進行編碼,後端拿到請求後解碼校正是否符合預期,並設定每個Key的訪問頻率~~
內容不符合預期直接拒絕響應
訪問過於頻繁,那麼此使用者在一定時間內不允許訪問~~~
2)還可以發放SSH私密金鑰/公開金鑰的方式來保證~~~
用Access-Control-Allow-Origin
header 和 csrf的token來控制。
有的需要限制次數的還會在headers中加入X-RateLimit-Limit
和X-RateLimit-Remaining
來控制訪問
目前我的想法更多是限制操作頻度來控制,因為無論你怎麼做,會Chrome外掛程式開發的指令碼小王子總能利用你的使用者體驗需求繞過所有限制。
同時也建議你開放出去的api許可權控制好,比如
http://api.xxx.com/customer/user/get?id=12345
不要將這個api設計為隨意更換id就能查詢到所有使用者的資訊,要在filter中對傳入的id和session中維護的登入使用者資訊做鑒權校正。
如果這個頁面被設計為不需要使用者登入即可查看的偏靜態頁面,那我會推薦你不要用方案來實現這種頁面。因為很難去做SEQ和CDN化
給你一個簡單的方案:判斷請求來源是不是ajax,如果不是,則拒絕請求。那麼來自ajax的請求,可以進行計數,如果單位時間請求過於頻繁的話,禁止請求(這樣會武斷的屏蔽掉一個IP後面有一家大公司的情況)。
如果是ajax的話,你根本不能判斷對方是不是惡意請求,因為它很有可能真的來源於你自己的頁面。
做個token驗證。在前端要調用後端介面的時候,傳個加密過的token過來就行啦
一般就是token,還有就是來源。。。這就殺了一片了。
做好後端驗證是最重要的。
傳遞的資料可以用js加個密,能略微增加一些抓包的難度
最近我也在思考這個問題
試試Oauth驗證
後端沒有記錄session,怎麼擷取資料?
後來,我大致想了一下,一些不是非常敏感的資料,不需要登入就可以載入,如果是敏感的資料需要使用者登入了之後才可以用非同步呼叫。
驗證碼,session,限制ip 這些都是可以做的…
所見即所得 (WYSIWYG),沒辦法。
http協議的無狀態特性決定了是無法徹底避免第三方調用你的後台服務。前面幾位說的方法都有一定的作用,包括crsf、介面調用頻率、使用者行為分析等從某一些方面來說都是只能增加第三方調用的難度而已。
12306網站就是最好的執行個體。
登入資料可以用session,如果不需要登入的,可以用參數密鑰時間認證。
test.php?a=1&b=2&time=12345678&code=xxxx
xxxx就是認證碼,簡單點可以用md5(a1b2time12345678passwd),即參數列表,加上目前時間,加上密碼。你可以使用多個密碼,即一個用戶端一個密碼,每個用戶端發一個appid,即增加一個參數,
`test.php?appid=1&a=1&b=2&time=12345678&code=xxxx`,
這樣可以隨時修改一個用戶端的密碼,或者丟棄某個用戶端請求。
非法訪問通常使用認證來解決,方法很多session,oauth等等。
對於合法的認證訪問通常需要進行訪問頻率和次數的限制,各種API架構都有支援,比如Django restframework的throttling。
對於拒絕服務時的訪問,通常需要在更前端做控制,比如在nginx上配置rate limit。
參照各大開放介面,做一個token驗證,每次發起請求必須帶驗證。就不會被隨意調用了。
HTTP請求支援鑒權,用base auth 做訪問身分識別驗證.或者用oauth2對請求做認證.
lz 可以參考下js 的介面