常見的web安全問題及解決方案

隨着互聯網的快速發展和前端的多樣性，瀏覽器已經成一種十分重要的上網工具，也是要有愈來愈多的交互操做須要瀏覽器來支持，因此針對瀏覽器的安全問題也愈來愈重要。
瀏覽器安全實際上是受同源策略（同域名、同端口、同協議名）保護的，可是<script>、<img>、<iframe>、<link>等標籤均可以跨域加載資源，而不受同源策略的限制。
1》這些帶"src"屬性的標籤每次加載時，瀏覽器會發起一次GET請求。
2》經過src屬性加載的資源，瀏覽器限制了javascript的權限，使其不能讀、寫返回的內容。
常見的六大安全問題有：XSS、CSRF、點擊劫持、URL跳轉漏洞、SQL注入、OS命令注入攻擊

===1.XSS===

XSS (Cross-Site Scripting)，跨站腳本攻擊，由於縮寫和 CSS重疊，因此只能叫 XSS。
XSS 的原理是惡意攻擊者往 Web 頁面裏插入惡意可執行網頁腳本代碼，當用戶瀏覽該頁之時，嵌入其中 Web 裏面的腳本代碼會被執行，從而能夠達到攻擊者盜取用戶信息或其餘侵犯用戶安全隱私的目的。
1.非持久型 XSS（反射型 XSS ）

通常是經過給別人發送帶有惡意腳本代碼參數的 URL，當 URL 地址被打開時，特有的惡意代碼參數被 HTML 解析、執行。
非持久型 XSS 漏洞攻擊有如下幾點特徵：
1>即時性，不通過服務器存儲，直接經過 HTTP 的 GET 和 POST 請求就能完成一次攻擊，拿到用戶隱私數據。
2>攻擊者須要誘騙點擊,必需要經過用戶點擊連接才能發起
3>反饋率低，因此較難發現和響應修復
4>盜取用戶敏感保密信息

2.持久型 XSS（存儲型 XSS）

持久型 XSS 漏洞，通常存在於 Form 表單提交等交互功能，如文章留言，提交文本信息等，黑客利用的 XSS 漏洞，將內容經正常功能提交進入數據庫持久保存，當前端頁面得到後端從數據庫中讀出的注入代碼時，剛好將其渲染執行。
持久型 XSS 有如下幾個特色：
1.持久性，植入在數據庫中
2.盜取用戶敏感私密信息
3.危害面廣

如何防護？

1》設置白名單CSP
一般能夠經過兩種方式來開啓 CSP：
設置 HTTP Header 中的 Content-Security-Policy
設置 meta 標籤的方式 <meta http-equiv="Content-Security-Policy">
Content-Security-Policy: default-src 'self' //只容許加載本站資源
Content-Security-Policy: img-src https://* //只容許加載 HTTPS 協議圖片
Content-Security-Policy: child-src 'none' //容許加載任何來源框架

2》用戶的輸入永遠不可信任的，最廣泛的作法就是轉義輸入輸出的內容，對於引號、尖括號、斜槓進行轉義

3》HttpOnly Cookie。
這是預防XSS攻擊竊取用戶cookie最有效的防護手段。Web應用程序在設置cookie時，將其屬性設爲HttpOnly，就能夠避免該網頁的cookie被客戶端惡意JavaScript竊取，保護用戶cookie信息。

===2.CSRF===

CSRF(Cross Site Request Forgery)，即跨站請求僞造，是一種常見的Web攻擊，它利用用戶已登陸的身份，在用戶絕不知情的狀況下，以用戶的名義完成非法操做。

如何防護？

1》能夠對 Cookie 設置 SameSite 屬性。該屬性表示 Cookie 不隨着跨域請求發送，能夠很大程度減小 CSRF 的攻擊，可是該屬性目前並非全部瀏覽器都兼容。

2》經過Referer限制！Referer信息告訴服務器是從哪一個頁面連接過來的

3》目前比較完善的解決方案是加入Anti-CSRF-Token,即發送請求時在HTTP 請求中以參數的形式加入一個隨機產生的token，服務器讀取瀏覽器當前域cookie中這個token值，進行比較校驗。

4》驗證碼操做，體驗上不是很好

===3.點擊劫持===

經過iframe透明化，漏出來一個按鈕，誘惑用戶點擊。

如何防護？

1》X-FRAME-OPTIONS是一個 HTTP 響應頭，在現代瀏覽器有一個很好的支持。這個 HTTP 響應頭 就是爲了防護用 iframe 嵌套的點擊劫持攻擊。X-FRAME-OPTIONS有3個值可選：
DENY，表示頁面不容許經過 iframe 的方式展現
SAMEORIGIN，表示頁面能夠在相同域名下經過 iframe 的方式展現
ALLOW-FROM，表示頁面能夠在指定來源的 iframe 中展現
2》經過js的方法判斷，來隱藏iframe顯示的頁面。

<script>
    if (self == top) {
      var style = document.getElementById('click-jack')
      document.body.removeChild(style)
    } else {
      top.location = self.location
    }
  </script>

===4.url跳轉漏洞===

藉助未驗證的URL跳轉，將應用程序引導到不安全的第三方區域，從而致使的安全問題。

1》referer的限制
若是肯定傳遞URL參數進入的來源，咱們能夠經過該方式實現安全限制，保證該URL的有效性，避免惡意用戶本身生成跳轉連接
2》加入有效性驗證Token
咱們保證全部生成的連接都是來自於咱們可信域的，經過在生成的連接里加入用戶不可控的Token對生成的連接進行校驗，能夠避免用戶生成本身的惡意連接從而被利用，可是若是功能自己要求比較開放，可能致使有必定的限制。

===5.SQL注入===

SQL注入的本質:數據和代碼未分離，即數據當作了代碼來執行。
有可能會形成獲取數據庫信息、管理員後臺用戶名和密碼、讀取服務器敏感文件等問題，甚至修改數據庫內容。

如何防護？

1》嚴格限制Web應用的數據庫的操做權限，給此用戶提供僅僅可以知足其工做的最低權限，從而最大限度的減小注入攻擊對數據庫的危害
2》後端代碼檢查輸入的數據是否符合預期，嚴格限制變量的類型，例如使用正則表達式進行一些匹配處理。
3》對進入數據庫的特殊字符（'，"，，<，>，&，，; 等）進行轉義處理，或編碼轉換*。基本上全部的後端語言都有對字符串進行轉義處理的方法，好比 lodash 的 lodash._escapehtmlchar 庫。
4》全部的查詢語句建議使用數據庫提供的參數化查詢接口，參數化的語句使用參數而不是將用戶輸入變量嵌入到 SQL 語句中，即不要直接拼接 SQL 語句。例如 Node.js 中的 mysqljs 庫的 query 方法中的 ? 佔位參數。

===6.OS命令注入攻擊===

OS命令注入攻擊指經過Web應用，執行非法的操做系統命令達到攻擊的目的。

如何防護？

1》後端對前端提交內容進行規則限制（好比正則表達式）。2》在調用系統命令前對全部傳入參數進行命令行參數轉義過濾。3》不要直接拼接命令語句，藉助一些工具作拼接、轉義預處理，例如 Node.js 的 shell-escape npm包