002.web安全 · 每天一道面試題

> 題目：前端常見的安全問題有哪些？ Web 前端的安全問題，能回答出下文的兩個問題，這個題目就能基本過關了。開始之前，先說一個最簡單的攻擊方式 —— SQL 注入。上學的時候就知道有一個「SQL注入」的攻擊方式。例如做一個系統的登錄界面，輸入用戶名和密碼，提交之后，后端直接拿到數據就拼接 SQL 語句去查詢數據庫。如果在輸入時進行了惡意的 SQL 拼裝，那么最后生成的 SQL 就會有問題。但是現在稍微大型一點的系統，都不會這么做，從提交登錄信息到最后拿到授權，要經過層層的驗證。因此，SQL 注入都只出現在比較低端小型的系統上。 ### XSS（Cross Site Scripting，跨站腳本攻擊）這是前端最常見的攻擊方式，很多大型網站（如 Facebook）都被 XSS 攻擊過。舉一個例子，我在一個博客網站正常發表一篇文章，輸入漢字、英文和圖片，完全沒有問題。但是如果我寫的是惡意的 JS 腳本，例如獲取到`document.cookie`然后傳輸到自己的服務器上，那我這篇博客的每一次瀏覽都會執行這個腳本，都會把訪客 cookie 中的信息偷偷傳遞到我的服務器上來。其實原理上就是黑客通過某種方式（發布文章、發布評論等）將一段特定的 JS 代碼隱蔽地輸入進去。然后別人再看這篇文章或者評論時，之前注入的這段 JS 代碼就執行了。**JS 代碼一旦執行，那可就不受控制了，因為它跟網頁原有的 JS 有同樣的權限**，例如可以獲取 server 端數據、可以獲取 cookie 等。于是，攻擊就這樣發生了。 #### XSS的危害 XSS 的危害相當大，如果頁面可以隨意執行別人不安全的 JS 代碼，輕則會讓頁面錯亂、功能缺失，重則會造成用戶的信息泄露。比如早些年社交網站經常爆出 XSS 蠕蟲，通過發布的文章內插入 JS，用戶訪問了感染不安全 JS 注入的文章，會自動重新發布新的文章，這樣的文章會通過推薦系統進入到每個用戶的文章列表面前，很快就會造成大規模的感染。還有利用獲取 cookie 的方式，將 cookie 傳入入侵者的服務器上，入侵者就可以模擬 cookie 登錄網站，對用戶的信息進行篡改。 #### XSS的預防那么如何預防 XSS 攻擊呢？—— 最根本的方式，就是對用戶輸入的內容進行驗證和替換，需要替換的字符有： ~~~ & 替換為：& < 替換為：< > 替換為：> ” 替換為：" ‘ 替換為：' / 替換為：/ ~~~ 替換了這些字符之后，黑客輸入的攻擊代碼就會失效，XSS 攻擊將不會輕易發生。除此之外，還可以通過對 cookie 進行較強的控制，比如對敏感的 cookie 增加`http-only`限制，讓 JS 獲取不到 cookie 的內容。 ### CSRF（Cross-site request forgery，跨站請求偽造） CSRF 是借用了當前操作者的權限來偷偷地完成某個操作，而不是拿到用戶的信息。例如，一個支付類網站，給他人轉賬的接口是`http://buy.com/pay?touid=999&money=100`，而這個接口在使用時沒有任何密碼或者 token 的驗證，只要打開訪問就直接給他人轉賬。一個用戶已經登錄了`http://buy.com`，在選擇商品時，突然收到一封郵件，而這封郵件正文有這么一行代碼`<img src="http://buy.com/pay?touid=999&money=100"/>`，他訪問了郵件之后，其實就已經完成了購買。 CSRF 的發生其實是借助了一個 cookie 的特性。我們知道，登錄了`http://buy.com`之后，cookie 就會有登錄過的標記了，此時請求`http://buy.com/pay?touid=999&money=100`是會帶著 cookie 的，因此 server 端就知道已經登錄了。而如果在`http://buy.com`去請求其他域名的 API 例如`http://abc.com/api`時，是不會帶 cookie 的，這是瀏覽器的同源策略的限制。但是 ——**此時在其他域名的頁面中，請求`http://buy.com/pay?touid=999&money=100`，會帶著`buy.com`的 cookie ，這是發生 CSRF 攻擊的理論基礎。** 預防 CSRF 就是加入各個層級的權限驗證，例如現在的購物網站，只要涉及現金交易，肯定要輸入密碼或者指紋才行。除此之外，敏感的接口使用`POST`請求而不是`GET`也是很重要的。 ## **文檔** [web安全](http://www.hmoore.net/freya001/security/1214610)