30 常見的 Web 攻擊與防範
今天我們來聊一聊常見的 Web 安全相關的問題，也會在接下來的一節中說一說 Django 在 Web 安全方面做了哪些工作。瞭解了這些才有可能防範出現一些低階的安全問題，避免給開發的專案留下十分明顯的安全隱患。當然，完美的應用肯定是不存在的，都會有未被發現的漏洞，我們在開發中只需要保證不要出現太過於明顯的問題即可。
1. DDoS攻擊
全稱 Distributed Denial of Service，中文意思為“分散式拒絕服務”，就是利用大量合法的分散式伺服器對目標傳送請求，從而導致正常合法使用者無法獲得服務。DDoS 攻擊方式簡單粗暴，可以達到直接摧毀目標的目的。
另外，相對其他攻擊手段 DDoS 的技術要求和發動攻擊的成本很低，只需要購買部分伺服器許可權或通過技術手段控制一批肉雞即可。另一方面，DDoS 具有攻擊易防守難的特徵，服務提供商為了保證正常客戶的需求需要耗費大量的資源才能和攻擊發起方進行對抗。這些特點使得 DDoS 成為黑客們手中的一把很好使的利劍，而且所向披靡。
DDos 的攻擊形式多種多樣，有針對資源消耗類攻擊、服務消耗性攻擊、反射性攻擊、混合型攻擊等等，最終達到對端服務不可用的目的。
網際網路發展至今，DDoS 攻擊就一直存在，而且隨著技術的發展，DDoS 的攻擊方式也變化多端。目前而言，對於 DDoS 攻擊仍舊是一個令人頭疼的問題，許多創業公司或者規模較小的公司，不願過多投入到防禦體系的建設上，這就導致大部分公司面對高流量的 DDoS 攻擊時都是直接投降，毫無還手之力。
目前，安全產業對 DDoS 的防護系統本質上是一個基於資源較量和規則過濾的智慧化系統，主要的防禦手段和策略包括：
- 資源隔離
- 使用者規則
- 大資料智慧分析
- 資源對抗
隨著目前人工智慧和深度學習技術的火熱發展，在 Web 安全領域已經開展了許多關於這方面的實踐研究，也相信不久的將來，DDoS 攻擊能徹底被深度學習技術打敗，不再成為大部分業內公司的噩夢。
2. CSRF攻擊
CSRF(Cross-site request forgery)，中文名稱：跨站請求偽造。可以這麼簡單理解CSRF攻擊：攻擊者盜用了你的身份(獲取登入正規網站的 cookie 資訊)， 並以你的名義傳送惡意請求(比如轉賬、提交訂單等)。CSRF 主要會導致個人的隱私洩露並威脅財產安全。我們用下面一幅圖來描述一下 CSRF 攻擊的形成與危害：
從上面的示例過程可以看出，要完成一次 CSRF 攻擊，受害者必須依次完成兩個步驟：
- 登入受信任網站A，並在本地生成Cookie；
- 在不登出A的情況下，訪問危險網站B；
上面這幾種情況看似很難一起發生，但在現實場景中卻是很容易發生的。這主要是基於以下幾個原因導致的：
-
我們往往登入了一個網站後，開啟多個 tab 頁面去訪問多個其他網站，類似於下圖：
-
關閉瀏覽器了後，本地的 Cookie 並不會立即過期，上次會話也並不意味著結束，除非我們點選登出(logout)或者主動清除瀏覽器快取；
-
所謂的危險網站，可能是經常被人訪問的正規網站。該網站由於存在某種漏洞被人惡意攻擊，並在網站中放入惡意連結誘導使用者點選；
基於以上三點，CSRF 攻擊很可能每天在我們身邊上演。但是網站必須要確保不存在相應的 CSRF 漏洞，否則極容易黑客攻擊。
關於 CSRF 攻擊的主要防禦手段便是在網頁上新增一個隨機的校驗 token 值。由於 CSRF 的本質在於攻擊者欺騙使用者去訪問自己設定的地址，所以如果要求在訪問敏感資料請求時，要求使用者瀏覽器提供不儲存在 cookie 中，並且攻擊者無法偽造的資料作為校驗，那麼攻擊者就無法再執行 CSRF 攻擊。這種資料通常是表單中的一個數據項。伺服器將其生成並附加在表單中，其內容是一個偽亂數。當客戶端通過表單提交請求時，這個偽亂數也一併提交上去以供校驗。正常的訪問時，客戶端瀏覽器能夠正確得到並傳回這個偽亂數，而通過 CSRF 傳來的欺騙性攻擊中，攻擊者無從事先得知這個偽亂數的值，伺服器端就會因為校驗 token 的值為空或者錯誤，並拒絕這個可疑請求。
3. XSS攻擊
XSS 攻擊又稱 CSS，全稱Cross Site Script (跨站指令碼攻擊)，其原理是攻擊者向有 XSS 漏洞的網站中輸入惡意的 HTML 程式碼，當用戶瀏覽該網站時，這段 HTML 程式碼會自動執行，從而達到攻擊的目的。
XSS 攻擊可以分成兩種型別：
- 非持久型 XSS 攻擊：顧名思義，非持久型 XSS 攻擊是一次性的，僅對當次的頁面訪問產生影響。非持久型 XSS 攻擊要求使用者訪問一個被攻擊者篡改後的連結，使用者訪問該連結時，被植入的攻擊指令碼被使用者遊覽器執行，從而達到攻擊目的；
- 持久型 XSS 攻擊：持久型 XSS，會把攻擊者的惡意程式碼資料儲存在伺服器端，攻擊行為將伴隨著惡意程式碼的存在而一直存在。
XSS 的攻擊防範主要是對提交的各種字串資料進行校驗，避免出現可執行的前端程式碼。主要的防範措施有：
- 對輸入內容的特定字元進行編碼，例如表示 html 標記的 < > 等符號；
- 對重要的 cookie 設定 httpOnly，防止客戶端通過
document.cookie讀取 cookie，此 HTTP 頭在服務端設定； - 將不可信的值輸出 URL 引數之前，進行 URLEncode 操作，而對於從 URL 引數中獲取值一定要進行格式校驗；
- 不要使用
eval來解析並執行不確定的資料或程式碼，對於 JSON 解析可使用JSON.parse()方法； - 後端介面也要對關鍵的字元進行過濾，防止將惡意的指令碼程式碼儲存到資料庫中。
4. SQL注入攻擊
SQL 注入是網站存在最多也是最簡單的漏洞，主要原因是程式設計師在開發使用者和資料庫互動的系統時沒有對使用者輸入的字串進行過濾，轉義，限制或處理不嚴謹，導致使用者可以通過輸入精心構造的字串去非法獲取到資料庫中的資料。SQL 注入是一種注入攻擊，可以執行惡意 SQL 語句。它通過將任意 SQL 程式碼插入資料庫查詢，使攻擊者能夠完全控制 Web 應用程式後面的資料庫伺服器。攻擊者可以使用 SQL 注入漏洞繞過應用程式安全措施；可以繞過網頁或 Web 應用程式的身份驗證和授權，並檢索整個 SQL 資料庫的內容；還可以使用 SQL 注入來新增，修改和刪除資料庫中的記錄。有一個經典的例子如下：
一個網站後臺管理系統存在 SQL 注入漏洞。它使用 url 傳遞的引數 username 和 password 去資料庫校驗對應的使用者名稱和密碼是否正確，形成的 SQL 語句如下：
SELECT * FROM user WHERE username='admin' AND password='passwd'
如果後臺服務對輸入的使用者名稱和密碼做任何處理，前臺直接構造使用者名稱為：’ or 1=1#。此時後臺形成的查詢 SQL 語句為：
SELECT * FROM user WHERE username='' or 1=1#' AND password='xxx'
這條語句也是可以執行的，而且可以得到所有的使用者記錄。因為 “or 1” 讓 SQL 的查詢條件永遠為 True，而 ‘#’ 遮蔽了後面的密碼校驗。
早期這種後臺管理系統的漏洞屢見不鮮。很多人只需要通過黑客工具找到存在 SQL 注入漏洞的後臺管理系統，然後使用這個萬能密碼就能直接進入網站的管理系統頁面，達到入侵的目的。
SQL 注入攻擊方式主要有以下三種：
- 帶內注入：攻擊者可以通過相同的通訊通道發起攻擊並獲得結果，主要通過以下兩種方式完成。
- 基於錯誤的SQL注入：從顯示的錯誤訊息中獲取有關資料庫的資訊
- 基於聯合的SQL注入：依賴於攻擊者能夠將UNION ALL被盜資訊的結果與合法結果連線起來
- 盲注入：也稱為推理SQL注入；
- 帶外注入：攻擊者通過精心製作的 SQL 語句注入到資料庫，可以觸發資料庫系統建立與攻擊者控制的外部伺服器的連線。通過這種方式，攻擊者可以收集資料或可能控制資料庫的行為。
對於 SQL 的注入攻擊，在開發 Web 系統時只需要遵循以下幾點建議，就能避免絕大部分的 SQL 注入漏洞了：
- 避免將使用者提供的輸入直接放入 SQL 語句中，最好使用準備好的語句和引數化查詢；
- 不要將敏感資料保留在純文字中；
- 限制資料庫許可權和特權；
- 避免直接向用戶顯示資料庫錯誤。大部分的時候，我們需要攔截相關異常，然後定製化輸出資料庫異常資訊；
- 對訪問資料庫的Web應用程式使用Web應用程式防火牆(WAF)；
- 及時更新資料庫至最新版，防止黑客利用舊版本漏洞發起攻擊。
5. 小結
本小節中我們詳細介紹了 Web 攻擊的幾種常見方式以及相應的防範手段。伺服器上任何一個應用的漏洞都有可能是黑客攻陷伺服器的突破口。筆者之前在公司內部部署 saltstack 運維管理系統時，不小心讓 saltstack 中的 API 服務也對外可訪問(服務啟動以 0.0.0.0 的方式)，而由於 saltstack 自身的漏洞原因導致被人掃描並藉助該服務向伺服器內部植入了病毒，導致我們主機卡頓、並被病毒佔用大量頻寬，對外發送資料。最後不得已，只能重灌系統，浪費了幾天時間在重灌所有應用和服務上，教訓慘痛，當切記切記！