轉載自https://www.toutiao.com/a6642147029348778509/?iid=56038047054&app=news_article&group_id=6642147029348778509&timestamp=1546567148

今天，從開發人員的角度，說說《如何防範常見的Web攻擊》話題。

SQL注入攻擊

SQL注入攻擊，這個是最常聊到的話題，使用過Java的開發人員，第一個反應就是一定要使用預編譯的PrepareStatement，是吧？

什麼是SQL注入攻擊

攻擊者在HTTP請求中注入惡意的SQL程式碼，伺服器使用引數構建資料庫SQL命令時，惡意SQL被一起構造，並在資料庫中執行。

使用者登入，輸入使用者名稱 lianggzone，密碼 ‘ or ‘1’=’1 ，如果此時使用引數構造的方式，就會出現

select * from user 
 where name = 'lianggzone' 
 and password = '' or '1'='1'

不管使用者名稱和密碼是什麼內容，使查詢出來的使用者列表不為空。

現在還會存在SQL注入攻擊麼

這個問題在使用了預編譯的PrepareStatement後，安全性得到了很大的提高，但是真實情況下，很多同學並不重視，還是會留下漏洞的。舉個例子，看看，大家的程式碼中對 sql 中 in 操作，使用了預編譯，還是仍然還是通過字串拼接呢？

如何防範SQL注入攻擊

使用預編譯的PrepareStatement是必須的，但是一般我們會從兩個方面同時入手。

Web端

• 有效性檢驗。
• 限制字串輸入的長度。

服務端

• 不用拼接 SQL 字串。
• 使用預編譯的 PrepareStatement。
• 有效性檢驗。(為什麼服務端還要做有效性檢驗？第一準則，外部都是不可信的，防止攻擊者繞過Web端請求)
• 過濾 SQL 需要的引數中的特殊字元。比如單引號、雙引號。

XSS攻擊

什麼是XSS攻擊

跨站點指令碼攻擊，指攻擊者通過篡改網頁，嵌入惡意指令碼程式，在使用者瀏覽網頁時，控制使用者瀏覽器進行惡意操作的一種攻擊方式。

假設頁面上有一個表單

<input type="text" name="name" value="樑桂釗"/>

如果，使用者輸入的不是一個正常的字串，而是

"/><script>alert("haha")</script><!-

此時，頁面變成下面的內容，在輸入框input的後面帶上了一段指令碼程式碼。

<input type="text" name="name" value="樑桂釗"/><script>alert("haha")</script><!-"/>

這端指令碼程式只是彈出一個訊息框，並不會造成什麼危害，攻擊的威力取決於使用者輸入了什麼樣的指令碼，只要稍微修改，便可使攻擊極具攻擊性。

XSS攻擊有多可怕

蠻早之前，我曾經找了幾個網站做個測試，其實大家對XSS攻擊的防範還是不夠，都成功的注入了測試指令碼。

甚至，還有攻擊者提交惡意的javascript程式碼的評論資訊或者反饋資訊（這些資訊，正常客戶端沒有做xss校驗，會存在客戶端注入問題），所有訪問者訪問該內容時，都會執行這段惡意的javascript程式碼。

如何防範XSS攻擊

• 前端，服務端，同時需要字串輸入的長度限制。
• 前端，服務端，同時需要對HTML轉義處理。將其中的”<”,”>”等特殊字元進行轉義編碼。

CSRF攻擊

什麼是CSRF攻擊

跨站點請求偽造，指攻擊者通過跨站請求，以合法的使用者的身份進行非法操作。可以這麼理解CSRF攻擊：攻擊者盜用你的身份，以你的名義向第三方網站傳送惡意請求。CRSF能做的事情包括利用你的身份發郵件，發簡訊，進行交易轉賬，甚至盜取賬號資訊。

如何防範CSRF攻擊

• 安全框架，例如Spring Security。
• token機制。在HTTP請求中進行token驗證，如果請求中沒有token或者token內容不正確，則認為CSRF攻擊而拒絕該請求。
• 驗證碼。通常情況下，驗證碼能夠很好的遏制CSRF攻擊，但是很多情況下，出於使用者體驗考慮，驗證碼只能作為一種輔助手段，而不是最主要的解決方案。
• referer識別。在HTTP Header中有一個欄位Referer，它記錄了HTTP請求的來源地址。如果Referer是其他網站，就有可能是CSRF攻擊，則拒絕該請求。但是，伺服器並非都能取到Referer。很多使用者出於隱私保護的考慮，限制了Referer的傳送。在某些情況下，瀏覽器也不會發送Referer，例如HTTPS跳轉到HTTP。

檔案上傳漏洞

什麼是檔案上傳漏洞

檔案上傳漏洞，指的是使用者上傳一個可執行的指令碼檔案，並通過此指令碼檔案獲得了執行服務端命令的能力。

許多第三方框架、服務，都曾經被爆出檔案上傳漏洞，比如很早之前的Struts2，以及富文字編輯器等等，可能被一旦被攻擊者上傳惡意程式碼，有可能服務端就被人黑了。

如何防範檔案上傳漏洞

• 檔案上傳的目錄設定為不可執行。
• 判斷檔案型別。在判斷檔案型別的時候，可以結合使用MIME Type，字尾檢查等方式。因為對於上傳檔案，不能簡單地通過後綴名稱來判斷檔案的型別，因為攻擊者可以將可執行檔案的字尾名稱改為圖片或其他字尾型別，誘導使用者執行。
• 對上傳的檔案型別進行白名單校驗，只允許上傳可靠型別。
• 上傳的檔案需要進行重新命名，使攻擊者無法猜想上傳檔案的訪問路徑，將極大地增加攻擊成本，同時向shell.php.rar.ara這種檔案，因為重新命名而無法成功實施攻擊。
• 限制上傳檔案的大小。
• 單獨設定檔案伺服器的域名。

訪問控制

一般來說，“基於URL的訪問控制”是最常見的。

垂直許可權管理

訪問控制實際上是建立使用者與許可權之間的對應關係，即“基於角色的訪問控制”，RBAC。不同角色的許可權有高低之分。高許可權角色訪問低許可權角色的資源往往是被允許的，而低許可權角色訪問高許可權的資源往往被禁止的。在配置許可權時，應當使用“最小許可權原則”，並使用“預設拒絕”的策略，只對有需要的主體單獨配置”允許”的策略，這在很多時候能夠避免發生“越權訪問”。

例如，Spring Security， Apache Shiro都可以建立垂直許可權管理。

水平許可權管理

水平許可權問題在同一個角色上，系統只驗證了訪問資料的角色，沒有對角色內的使用者做細分，由於水平許可權管理是系統缺乏一個數據級的訪問控制所造成的，因此水平許可權管理又可以稱之為“基於資料的訪問控制”。

舉個理解，比如我們之前的一個助手產品，客戶端使用者刪除評論功能，如果沒有做水平許可權管理，即設定只有本人才可以刪除自己的評論，那麼使用者通過修改評論id就可以刪除別人的評論這個就存在危險的越權操作。

這個層面，基本需要我們業務層面去處理，但是這個也是最為經常遺落的安全點。

總結

上面列舉的幾個話題，都是我在開發過程中，遇到的比較常見的Web安全話題，以及一些防範方案，需要我們在開發過程中及時規避，而不是依靠安全人員或者真正使用者，甚至惡意的攻擊者幫我們去發現問題。當然，還有很多Web安全話題，例如遠端執行漏洞、拒絕服務攻擊、Session保持攻擊等等