[[352781]]

網站安全

從從互聯網發展開始，各種網絡安全問題也就伴隨而生。

近些年來有很多網站遭到攻擊，如新浪微博遭XSS攻擊，以CSDN為代表的多個網站泄露用戶密碼和個人信息。

特別是后者，因為影響人群廣泛，部分受影響網站涉及用戶實體資產和交易安全，一時成為輿論焦點。

那么新浪微博是如何被攻擊的?CSDN的密碼為何會泄露?如何防護網站免遭攻擊，保護好用戶的敏感信息呢?

常見的攻擊與防御

XSS攻擊，它和SQL注入攻擊構成網站應用攻擊最主要的兩種手段，全球大約70%的Web應用攻擊都來自XSS攻擊和SQL注入攻擊。此外，常用的Web應用還包括CSRF、Session劫持等手段。

XSS攻擊

XSS攻擊又稱CSS,全稱Cross Site Script (跨站腳本攻擊)，其原理就是攻擊者像有XSS漏洞的網站注入惡意HTML腳本，在用戶瀏覽網頁時，這段惡意的HTML 腳本會自動執行，從而達到攻擊的目的。

常見的XSS攻擊類型：

• 反射型，通過在請求地址上加入惡意的HTML代碼
• dom型 ，通過一些API向網站注入惡意HTML
• 持久型，將惡意代碼內容發給服務器，服務器沒過濾就存儲到數據庫中了，下次再請求這個頁面時就會從數據庫中讀取出惡意代碼拼接到頁面HTML上

1、反射型XSS攻擊

攻擊步驟：

1、攻擊者構造出特殊的URL，其中包含惡意代碼。

2、當用戶打開帶有惡意代碼的URL時，網站服務端將惡意代碼從URL中取出，拼接在HTML中返回瀏覽器，之后用戶瀏覽器收到響應后解析執行混入其中的惡意代碼。

3、惡意代碼竊取用戶數據并發送到攻擊者的網站，或者冒充用戶行為，調用目標網站接口執行攻擊者指定的操作。

常見于通過 URL 傳遞參數的功能，如網站搜索、跳轉等。由于需要用戶主動打開惡意的 URL 才能生效，攻擊者往往會結合多種手段誘導用戶點擊。

舉個栗子：

新浪微博以前被攻擊就是一種反射型XSS攻擊。攻擊者發布的微博中有一個含有惡意腳本的URL，用戶點擊該URL，腳本會自動關注攻擊者的新浪微博ID，發布含有惡意腳本URL的微博，攻擊就被擴散了。

現實中，攻擊者可以采用XSS攻擊，偷取用戶Cookie、密碼等重要數據，進而偽造交易、盜竊用戶財產、竊取情報

2、存儲型XSS攻擊

攻擊步驟：

1、攻擊者將惡意代碼提交到目標網站的數據庫中

2、用戶打開網站時，網站服務端將惡意代碼從數據庫中取出，拼接在HTML中返回瀏覽器

3、用戶瀏覽器收到響應后解析執行混入其中的惡意代碼，惡意代碼竊取用戶數據并發送到攻擊者的網站，或者冒充用戶行為，調用目標網站接口執行攻擊者指定的操作。

常見于帶有用戶保存數據的網站功能，比如論壇發帖、商品評價、用戶私信等等。

反射型 XSS 跟存儲型 XSS 的區別是：存儲型 XSS 的惡意代碼存在數據庫里，反射型 XSS 的惡意代碼存在 URL 里。

DOM型XSS

攻擊步驟：

1、攻擊者構造出特殊的URL，其中包含惡意代碼

2、用戶打開帶有惡意代碼的URL，用戶瀏覽器打開帶有惡意代碼的URL，之后用戶瀏覽器收到響應后解析執行，前端JS取出URL中的惡意代碼并執行

3、惡意代碼竊取用戶數據并發送到攻擊者的網站，或者冒充用戶行為，調用目標網站接口執行攻擊者指定的操作。

DOM 型 XSS 跟前兩種 XSS 的區別：

DOM 型 XSS 攻擊中，取出和執行惡意代碼由瀏覽器端完成，屬于前端 JavaScript 自身的安全漏洞，而其他兩種 XSS 都屬于服務端的安全漏洞。

XSS的防御手段主要有兩種：

• 消毒
• HttpOnly

XSS的防御-消毒

XSS攻擊者一般都是通過在請求中嵌入惡意腳本達到攻擊的目的，這些腳本是一般用戶輸入中不使用的，如果進行過濾和消毒處理，即對某些html危險字符轉義。

如 “>” 轉義為“>” 、“<”轉義為 “<”等，就可以防止大部分攻擊。

為了避免對不必要的內容錯誤轉義，如“3<5”中的 “<” 需要進行文本匹配后再轉義，如 “

事實上，消毒幾乎是所有網站最必備的XSS防攻擊手段。

XSS的防御-HttpOnly

瀏覽器禁止頁面 JavaScript訪問帶有HttpOnly 屬性的敏感 Cookie。

HttpOnly并不是直接對抗XSS攻擊的，而是防止XSS攻擊者竊取Cookie，就算完成XSS注入后也無法竊取此Cookie屬性，防止冒充用戶提交請求。

注入攻擊

注入攻擊主要有兩種形式：

• SQL注入攻擊
• OS注入攻擊

SQL注入攻擊

攻擊者在HTTP請求中注入惡意SQL命令(drop table users;)，服務器用請求參數構造數據庫SQL命令時，惡意SQL被一起構造，并在數據庫中執行。

攻擊者獲取數據庫表結構信息的手段：

• 開源，比如一些開源的博客數據庫表是公開的，攻擊者可以直接獲得。
• 錯誤回顯，如果網站開啟錯誤回顯，即服務器內部500錯誤會顯示到瀏覽器上。攻擊者通過故意構造非法參數，使服務端異常信息輸出到瀏覽器端，為攻擊猜測數據庫表結構提供了便利。
• 盲注，網站關閉錯誤回顯，攻擊者根據頁面變化情況判斷SQL語句的執行情況，據此猜測數據庫表結構。

預防SQL注入

• 消毒，和防XSS攻擊一樣，請求參數編碼是一種比較簡單粗暴又有效的手段。通過正則匹配，過濾請求數據中可能注入的SQL，如“drop table”、“\b(?:update\b.?\bset|delete\b\W?\bfrom)\b”等
• 參數綁定，使用預編譯手段，綁定參數是最好的防SQL注入方法。目前許多數據訪問層框架，如IBatis，Hibernate等，都實現SQL預編譯和參數綁定，攻擊者的惡意SQL會被當做SQL的參數，而不是SQL命令被執行。

除了SQL注入，攻擊者還根據具體應用，注入OS命令、編程語言代碼等，利用程序漏洞，達到攻擊目的。

CSRF攻擊

CSRF(Cross Site Request Forgery，跨站點請求偽造)，是一種劫持授信用戶向服務器發送非預期請求的攻擊方式，也就是以合法用戶的身份進行非法操作。

攻擊者會誘導受害者訪問第三方網站，利用受害者獲得的被攻擊網站的憑證來冒充正常用戶對被攻擊網站進行某些操作的目的。

如轉賬交易、發表評論等。CSRF的主要手法是利用跨站請求，在用戶不知情的情況下，以用戶的身份偽造請求。

其核心是利用了瀏覽器Cookie或服務器Session策略，盜取用戶身份

CSRF的防御

CSRF的防御手段主要是識別請求者身份，防止第三方網站進行冒充，主要有下面幾種方法：

盡量POST，限制GET

GET接口太容易被拿來做CSRF攻擊，看第一個示例就知道，只要構造一個img標簽，而img標簽又是不能過濾的數據。接口最好限制為POST使用，GET則無效，降低攻擊風險。

當然POST并不是萬無一失，攻擊者只要構造一個form就可以，但需要在第三方頁面做，這樣就增加暴露的可能性。

表單Token

CSRF是一個偽造用戶請求的操作，所以需要構造用戶請求的所有參數才可以。

表單Token通過在請求參數中增加隨機數的辦法來阻止攻擊者獲得所有請求參數：

在頁面表單中增加一個隨機數作為Token，每次響應頁面的Token都不相同，從正常頁面提交的請求會包含該Token值，而偽造的請求無法獲得該值，服務器檢查請求參數中Token的值是否存在并且正確以確定請求提交者是否合法。

驗證碼

相對說來，驗證碼則更加簡單有效，即請求提交時，需要用戶輸入驗證碼，以避免在用戶不知情的情況下被攻擊者偽造請求。

Referer check

HTTP請求頭的Referer域中記錄著請求來源，可通過檢查請求來源，驗證其是否合法。很多網站使用這個功能實現圖片防盜鏈(如果圖片訪問的頁面來源不是來自自己網站的網頁就拒絕)。

本文轉載自微信公眾號「架構技術專欄」，可以通過以下二維碼關注。轉載本文請聯系架構技術專欄公眾號。