先後端分離項目安全漏洞修復總結

最近項目被安全掃描因爲項目設計有問題，暴出來了一些漏洞，在修復的過程當中特把經驗總結分享。

1.先後端分離和傳統架構介紹

項目架構

1.1 先後端不分離

在先後端不分離的應用模式中，前端頁面看到的效果都是由後端控制，由後端渲染頁面或重定向，也就是後端須要控制前端的展現，前端與後端的耦合度很高。
這種應用模式比較適合純網頁應用，可是當後端對接App時，App可能並不須要後端返回一個HTML網頁，而僅僅是數據自己，因此後端本來返回網頁的接口再也不適用於前端App應用，爲了對接App後端還需再開發一套接口。
請求的數據交互以下圖:

1.2 先後端分離

在先後端分離的應用模式中，後端僅返回前端所需的數據，再也不渲染HTML頁面，再也不控制前端的效果。至於前端用戶看到什麼效果，從後端請求的數據如何加載到前端中，都由前端本身決定，網頁有網頁的處理方式，App有App的處理方式，但不管哪一種前端，所需的數據基本相同，後端僅需開發一套邏輯對外提供數據便可。
在先後端分離的應用模式中 ，前端與後端的耦合度相對較低。
在先後端分離的應用模式中，咱們一般將後端開發的每一個視圖都稱爲一個接口，或者API，前端經過訪問接口來對數據進行增刪改查。
對應的數據交互以下圖 :

1.3 總結

不分離項目中咱們作鑑權很容易，採用過濾器、攔截器（基於session存儲）或者apache shiro、spring security，比較容易實現。可是先後端分離就稍微有點麻煩了，下面給出解決方案。

2.應對方案

2.1 先後端分離鑑權採用JWT

Json web token (JWT), 是爲了在網絡應用環境間傳遞聲明而執行的一種基於JSON的開放標準（(RFC 7519).該token被設計爲緊湊且安全的，特別適用於分佈式站點的單點登陸（SSO）場景。JWT的聲明通常被用來在身份提供者和服務提供者間傳遞被認證的用戶身份信息，以便於從資源服務器獲取資源，也能夠增長一些額外的其它業務邏輯所必須的聲明信息，該token也可直接被用於認證，也可被加密。

傳統的session認證

咱們知道，http協議自己是一種無狀態的協議，而這就意味着若是用戶向咱們的應用提供了用戶名和密碼來進行用戶認證，那麼下一次請求時，用戶還要再一次進行用戶認證才行，由於根據http協議，咱們並不能知道是哪一個用戶發出的請求，因此爲了讓咱們的應用能識別是哪一個用戶發出的請求，咱們只能在服務器存儲一份用戶登陸的信息，這份登陸信息會在響應時傳遞給瀏覽器，告訴其保存爲cookie,以便下次請求時發送給咱們的應用，這樣咱們的應用就能識別請求來自哪一個用戶了,這就是傳統的基於session認證。
可是這種基於session的認證使應用自己很可貴到擴展，隨着不一樣客戶端用戶的增長，獨立的服務器已沒法承載更多的用戶，而這時候基於session認證應用的問題就會暴露出來

於session認證所顯露的問題

Session: 每一個用戶通過咱們的應用認證以後，咱們的應用都要在服務端作一次記錄，以方便用戶下次請求的鑑別，一般而言session都是保存在內存中，而隨着認證用戶的增多，服務端的開銷會明顯增大。
擴展性: 用戶認證以後，服務端作認證記錄，若是認證的記錄被保存在內存中的話，這意味着用戶下次請求還必需要請求在這臺服務器上,這樣才能拿到受權的資源，這樣在分佈式的應用上，相應的限制了負載均衡器的能力。這也意味着限制了應用的擴展能力。
CSRF: 由於是基於cookie來進行用戶識別的, cookie若是被截獲，用戶就會很容易受到跨站請求僞造的攻擊。

基於token的鑑權機制

基於token的鑑權機制相似於http協議也是無狀態的，它不須要在服務端去保留用戶的認證信息或者會話信息。這就意味着基於token認證機制的應用不須要去考慮用戶在哪一臺服務器登陸了，這就爲應用的擴展提供了便利。
流程上是這樣的：

• 用戶使用用戶名密碼來請求服務器
• 服務器進行驗證用戶的信息
• 服務器經過驗證發送給用戶一個token
• 客戶端存儲token，並在每次請求時附送上這個token值
• 服務端驗證token值，並返回數據

這個token必需要在每次請求時傳遞給服務端，它應該保存在請求頭裏， 另外，服務端要支持CORS(跨來源資源共享)策略，通常咱們在服務端這麼作就能夠了Access-Control-Allow-Origin: *。

2.2 接口隱藏涉密信息

採用java棧作後臺接口，常常會用到orm框架，一個查詢就把一個實體查出來返回前端，不免會把涉密字段帶出來返回前端。應對方案：

• 涉密字段加密存儲
• 返回涉密字段的時候，把字段設置爲空。
• 或者採用aop統一處理涉密字段。
  

2.3 sql注入、xss、webshell注入

暴露在互聯網上不免被掃描攻擊，黑客利用掃描攻擊掃應用的版本，嘗試各類注入。應對方案：

• 攔截器或過濾器，監測Http請求中有敏感字符的好比:cmd、eval、shell等，就攔截直接返回拒絕訪問。
• 若是某個ip一直掃描瘋狂探測而且請求中帶有敏感字符，就把該ip放入黑名單，黑名單能夠用緩存實現、存放禁用Ip，建議能夠用redis存儲。

具體實現能夠看個人文章《nodejs http-proxy 開發反向代理服務器，防火牆，過濾常見的web滲透》
《spring 防止SQL注入的攔截器》

2.4 越權訪問他人信息

不要信任前端的參數，記得作後臺權限判斷

好比咱們的訂單id是數字類型的，黑客能夠用工具去循環遍歷，獲取全部用戶的訂單信息，這樣就很不安全。
這個時候後臺要作權限判斷，根據前端傳的訂單id和token信息，判斷該訂單是不是token對應用戶的訂單，若是不是就不返會信息。

2.5 短信轟炸

針對短信炸彈漏洞，建議限制每一個手機號的每日發送次數，每一個ip最大發送次數，限制 每一個手機號發送的時間間隔，以及應具備頁面圖片驗證碼、IP訪問次數限制功能。實現方式能夠採用redis過時緩存。

2.6 避免報錯信息返回前端

異常信息可能把ip端口號之類的返回到前端了，這樣會給黑客滲透留下提示，怎麼辦吶？

• 採用攔截器、aop過濾返回信息，若是攜帶有Exception關鍵字，就去掉報錯信息。

參考

什麼是 JWT -- JSON WEB TOKEN https://www.jianshu.com/p/576dbf44b2ae

總結不易歡迎在看或轉發，更多精彩關注微信公衆號【lovepythoncn】
**