常見(XSS|CSRF)六大Web安全攻防解析

前言

在互聯網時代，數據安全與我的隱私受到了史無前例的挑戰，各類新奇的攻擊技術層出不窮。如何才能更好地保護咱們的數據？本文主要側重於分析幾種常見的攻擊的類型以及防護的方法。

1、XSS

XSS (Cross-Site Scripting)，跨站腳本攻擊，由於縮寫和 CSS重疊，因此只能叫 XSS。跨站腳本攻擊是指經過存在安全漏洞的Web網站註冊用戶的瀏覽器內運行非法的HTML標籤或JavaScript進行的一種攻擊。

跨站腳本攻擊有可能形成如下影響:

• 利用虛假輸入表單騙取用戶我的信息。

• 利用腳本竊取用戶的Cookie值，被害者在不知情的狀況下，幫助攻擊者發送惡意請求。

• 顯示僞造的文章或圖片。

XSS 的原理是惡意攻擊者往 Web 頁面裏插入惡意可執行網頁腳本代碼，當用戶瀏覽該頁之時，嵌入其中 Web 裏面的腳本代碼會被執行，從而能夠達到攻擊者盜取用戶信息或其餘侵犯用戶安全隱私的目的。

XSS 的攻擊方式變幻無窮，但仍是能夠大體細分爲幾種類型。

1.非持久型 XSS（反射型 XSS ）

非持久型 XSS 漏洞，通常是經過給別人發送帶有惡意腳本代碼參數的 URL，當 URL 地址被打開時，特有的惡意代碼參數被 HTML 解析、執行。

舉一個例子，好比頁面中包含有如下代碼：

攻擊者可直接經過URL (相似：https://xxx.com/xxx?default=<script>alert(document.cookie)</script>) 注入可執行的腳本代碼。不過一些瀏覽器如Chrome其內置了一些XSS過濾器，能夠防止大部分反射型XSS攻擊。

非持久型 XSS 漏洞攻擊有如下幾點特徵：

• 即時性，不通過服務器存儲，直接經過 HTTP 的 GET 和 POST 請求就能完成一次攻擊，拿到用戶隱私數據。

• 攻擊者須要誘騙點擊,必需要經過用戶點擊連接才能發起

• 反饋率低，因此較難發現和響應修復

• 盜取用戶敏感保密信息

爲了防止出現非持久型 XSS 漏洞，須要確保這麼幾件事情：

• Web 頁面渲染的全部內容或者渲染的數據都必須來自於服務端。

• 儘可能不要從 URL，document.referrer，document.forms 等這種 DOM API 中獲取數據直接渲染。

• 儘可能不要使用eval, new Function()，document.write()，document.writeln()，window.setInterval()，window.setTimeout()，innerHTML，document.createElement() 等可執行字符串的方法。

• 若是作不到以上幾點，也必須對涉及 DOM 渲染的方法傳入的字符串參數作 escape 轉義。

• 前端渲染的時候對任何的字段都須要作 escape 轉義編碼。

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

持久型 XSS 漏洞，通常存在於 Form 表單提交等交互功能，如文章留言，提交文本信息等，黑客利用的 XSS 漏洞，將內容經正常功能提交進入數據庫持久保存，當前端頁面得到後端從數據庫中讀出的注入代碼時，剛好將其渲染執行。

舉個例子，對於評論功能來講，就得防範持久型 XSS 攻擊，由於我能夠在評論中輸入如下內容

主要注入頁面方式和非持久型 XSS 漏洞相似，只不過持久型的不是來源於 URL，referer，forms 等，而是來源於後端從數據庫中讀出來的數據 。持久型 XSS 攻擊不須要誘騙點擊，黑客只須要在提交表單的地方完成注入便可，可是這種 XSS 攻擊的成本相對仍是很高。

攻擊成功須要同時知足如下幾個條件：

• POST 請求提交表單後端沒作轉義直接入庫。

• 後端從數據庫中取出數據沒作轉義直接輸出給前端。

• 前端拿到後端數據沒作轉義直接渲染成 DOM。

持久型 XSS 有如下幾個特色：

• 持久性，植入在數據庫中

• 盜取用戶敏感私密信息

• 危害面廣

3.如何防護

對於 XSS 攻擊來講，一般有兩種方式能夠用來防護。

1) CSP

CSP 本質上就是創建白名單，開發者明確告訴瀏覽器哪些外部資源能夠加載和執行。咱們只須要配置規則，如何攔截是由瀏覽器本身實現的。咱們能夠經過這種方式來儘可能減小 XSS 攻擊。

一般能夠經過兩種方式來開啓 CSP：

• 設置 HTTP Header 中的 Content-Security-Policy

• 設置 meta 標籤的方式

這裏以設置 HTTP Header 來舉例：

• 只容許加載本站資源

Content-Security-Policy: default-src 'self'複製代碼

• 只容許加載 HTTPS 協議圖片

Content-Security-Policy: img-src https://*複製代碼

• 容許加載任何來源框架

Content-Security-Policy: child-src 'none'複製代碼

如需瞭解更多屬性，請查看Content-Security-Policy文檔

對於這種方式來講，只要開發者配置了正確的規則，那麼即便網站存在漏洞，攻擊者也不能執行它的攻擊代碼，而且 CSP 的兼容性也不錯。

2) 轉義字符

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

可是對於顯示富文原本說，顯然不能經過上面的辦法來轉義全部字符，由於這樣會把須要的格式也過濾掉。對於這種狀況，一般採用白名單過濾的辦法，固然也能夠經過黑名單過濾，可是考慮到須要過濾的標籤和標籤屬性實在太多，更加推薦使用白名單的方式。

以上示例使用了 js-xss 來實現，能夠看到在輸出中保留了 h1 標籤且過濾了 script 標籤。

3) HttpOnly Cookie。

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

2、CSRF

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

1.CSRF攻擊的原理

下面先介紹一下CSRF攻擊的原理：

完成 CSRF 攻擊必需要有三個條件：

• 用戶已經登陸了站點 A，並在本地記錄了 cookie

• 在用戶沒有登出站點 A 的狀況下（也就是 cookie 生效的狀況下），訪問了惡意攻擊者提供的引誘危險站點 B (B 站點要求訪問站點A)。

• 站點 A 沒有作任何 CSRF 防護

咱們來看一個例子： 當咱們登入轉帳頁面後，忽然眼前一亮驚現"XXX隱私照片，不看後悔一生"的連接，耐不住心裏躁動，立馬點擊了該危險的網站（頁面代碼以下圖所示），但當這頁面一加載，便會執行submitForm這個方法來提交轉帳請求，從而將10塊轉給黑客。

2.如何防護

防範 CSRF 攻擊能夠遵循如下幾種規則：

• Get 請求不對數據進行修改

• 不讓第三方網站訪問到用戶 Cookie

• 阻止第三方網站請求接口

• 請求時附帶驗證信息，好比驗證碼或者 Token

1) SameSite

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

2) Referer Check

HTTP Referer是header的一部分，當瀏覽器向web服務器發送請求時，通常會帶上Referer信息告訴服務器是從哪一個頁面連接過來的，服務器籍此能夠得到一些信息用於處理。能夠經過檢查請求的來源來防護CSRF攻擊。正常請求的referer具備必定規律，如在提交表單的referer一定是在該頁面發起的請求。因此經過檢查http包頭referer的值是否是這個頁面，來判斷是否是CSRF攻擊。

但在某些狀況下如從https跳轉到http，瀏覽器處於安全考慮，不會發送referer，服務器就沒法進行check了。若與該網站同域的其餘網站有XSS漏洞，那麼攻擊者能夠在其餘網站注入惡意腳本，受害者進入了此類同域的網址，也會遭受攻擊。出於以上緣由，沒法徹底依賴Referer Check做爲防護CSRF的主要手段。可是能夠經過Referer Check來監控CSRF攻擊的發生。

3) Anti CSRF Token

目前比較完善的解決方案是加入Anti-CSRF-Token。即發送請求時在HTTP 請求中以參數的形式加入一個隨機產生的token，並在服務器創建一個攔截器來驗證這個token。服務器讀取瀏覽器當前域cookie中這個token值，會進行校驗該請求當中的token和cookie當中的token值是否都存在且相等，才認爲這是合法的請求。不然認爲此次請求是違法的，拒絕該次服務。

這種方法相比Referer檢查要安全不少，token能夠在用戶登錄後產生並放於session或cookie中，而後在每次請求時服務器把token從session或cookie中拿出，與本次請求中的token 進行比對。因爲token的存在，攻擊者沒法再構造出一個完整的URL實施CSRF攻擊。但在處理多個頁面共存問題時，當某個頁面消耗掉token後，其餘頁面的表單保存的仍是被消耗掉的那個token，其餘頁面的表單提交時會出現token錯誤。

4) 驗證碼

應用程序和用戶進行交互過程當中，特別是帳戶交易這種核心步驟，強制用戶輸入驗證碼，才能完成最終請求。在一般狀況下，驗證碼夠很好地遏制CSRF攻擊。但增長驗證碼下降了用戶的體驗，網站不能給全部的操做都加上驗證碼。因此只能將驗證碼做爲一種輔助手段，在關鍵業務點設置驗證碼。

3、點擊劫持

點擊劫持是一種視覺欺騙的攻擊手段。攻擊者將須要攻擊的網站經過 iframe 嵌套的方式嵌入本身的網頁中，並將 iframe 設置爲透明，在頁面中透出一個按鈕誘導用戶點擊。

1. 特色

• 隱蔽性較高，騙取用戶操做

• "UI-覆蓋攻擊"

• 利用iframe或者其它標籤的屬性

2. 點擊劫持的原理

用戶在登錄 A 網站的系統後，被攻擊者誘惑打開第三方網站，而第三方網站經過 iframe 引入了 A 網站的頁面內容，用戶在第三方網站中點擊某個按鈕（被裝飾的按鈕），其實是點擊了 A 網站的按鈕。
接下來咱們舉個例子：我在優酷發佈了不少視頻，想讓更多的人關注它，就能夠經過點擊劫持來實現

從上圖可知，攻擊者經過圖片做爲頁面背景，隱藏了用戶操做的真實界面，當你按耐不住好奇點擊按鈕之後，真正的點擊的實際上是隱藏的那個頁面的訂閱按鈕，而後就會在你不知情的狀況下訂閱了。

3. 如何防護

1）X-FRAME-OPTIONS

X-FRAME-OPTIONS是一個 HTTP 響應頭，在現代瀏覽器有一個很好的支持。這個 HTTP 響應頭 就是爲了防護用 iframe 嵌套的點擊劫持攻擊。

該響應頭有三個值可選，分別是

• DENY，表示頁面不容許經過 iframe 的方式展現

• SAMEORIGIN，表示頁面能夠在相同域名下經過 iframe 的方式展現

• ALLOW-FROM，表示頁面能夠在指定來源的 iframe 中展現

2）JavaScript 防護

對於某些遠古瀏覽器來講，並不能支持上面的這種方式，那咱們只有經過 JS 的方式來防護點擊劫持了。

以上代碼的做用就是當經過 iframe 的方式加載頁面時，攻擊者的網頁直接不顯示全部內容了。

4、URL跳轉漏洞

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

1.URL跳轉漏洞原理

黑客利用URL跳轉漏洞來誘導安全意識低的用戶點擊，致使用戶信息泄露或者資金的流失。其原理是黑客構建惡意連接(連接須要進行假裝,儘量迷惑),發在QQ羣或者是瀏覽量多的貼吧/論壇中。
安全意識低的用戶點擊後,通過服務器或者瀏覽器解析後，跳到惡意的網站中。

惡意連接須要進行假裝,常常的作法是熟悉的連接後面加上一個惡意的網址，這樣才迷惑用戶。

諸如假裝成像以下的網址，你是否可以識別出來是惡意網址呢？

2.實現方式：

• Header頭跳轉

• Javascript跳轉

• META標籤跳轉

這裏咱們舉個Header頭跳轉實現方式：

<?php
    $url=$_GET['jumpto'];
    header("Location: $url");
?>
http://www.wooyun.org/login.php?jumpto=http://www.evil.com複製代碼

這裏用戶會認爲www.wooyun.org都是可信的，可是點擊上述連接將致使用戶最終訪問www.evil.com這個惡意網址。

3.如何防護

1)referer的限制

若是肯定傳遞URL參數進入的來源，咱們能夠經過該方式實現安全限制，保證該URL的有效性，避免惡意用戶本身生成跳轉連接

2)加入有效性驗證Token

咱們保證全部生成的連接都是來自於咱們可信域的，經過在生成的連接里加入用戶不可控的Token對生成的連接進行校驗，能夠避免用戶生成本身的惡意連接從而被利用，可是若是功能自己要求比較開放，可能致使有必定的限制。

5、SQL注入

SQL注入是一種常見的Web安全漏洞，攻擊者利用這個漏洞，能夠訪問或修改數據，或者利用潛在的數據庫漏洞進行攻擊。

1.SQL注入的原理

咱們先舉一個萬能鑰匙的例子來講明其原理：

後端的 SQL 語句多是以下這樣的：

這是咱們常常見到的登陸頁面，但若是有一個惡意攻擊者輸入的用戶名是 admin' --，密碼隨意輸入，就能夠直接登入系統了。why! ----這就是SQL注入

咱們以前預想的SQL 語句是:

SELECT * FROM user WHERE username='admin' AND psw='password'複製代碼

可是惡意攻擊者用奇怪用戶名將你的 SQL 語句變成了以下形式：

SELECT * FROM user WHERE username='admin' --' AND psw='xxxx'複製代碼

在 SQL 中,' --是閉合和註釋的意思，-- 是註釋後面的內容的意思，因此查詢語句就變成了：

SELECT * FROM user WHERE username='admin'複製代碼

所謂的萬能密碼,本質上就是SQL注入的一種利用方式。

一次SQL注入的過程包括如下幾個過程：

• 獲取用戶請求參數

• 拼接到代碼當中

• SQL語句按照咱們構造參數的語義執行成功

SQL注入的必備條件： 1.能夠控制輸入的數據 2.服務器要執行的代碼拼接了控制的數據。

咱們會發現SQL注入流程中與正常請求服務器相似，只是黑客控制了數據，構造了SQL查詢，而正常的請求不會SQL查詢這一步，SQL注入的本質:數據和代碼未分離，即數據當作了代碼來執行。

2.危害

• 獲取數據庫信息

• 管理員後臺用戶名和密碼

• 獲取其餘數據庫敏感信息：用戶名、密碼、手機號碼、身份證、銀行卡信息……

• 整個數據庫：脫褲

• 獲取服務器權限

• 植入Webshell，獲取服務器後門

• 讀取服務器敏感文件

3.如何防護

• 嚴格限制Web應用的數據庫的操做權限，給此用戶提供僅僅可以知足其工做的最低權限，從而最大限度的減小注入攻擊對數據庫的危害

• 後端代碼檢查輸入的數據是否符合預期，嚴格限制變量的類型，例如使用正則表達式進行一些匹配處理。

• 對進入數據庫的特殊字符（'，"，\，<，>，&，*，; 等）進行轉義處理，或編碼轉換。基本上全部的後端語言都有對字符串進行轉義處理的方法，好比 lodash 的 lodash._escapehtmlchar 庫。

• 全部的查詢語句建議使用數據庫提供的參數化查詢接口，參數化的語句使用參數而不是將用戶輸入變量嵌入到 SQL 語句中，即不要直接拼接 SQL 語句。例如 Node.js 中的 mysqljs 庫的 query 方法中的 ? 佔位參數。

6、OS命令注入攻擊

OS命令注入和SQL注入差很少，只不過SQL注入是針對數據庫的，而OS命令注入是針對操做系統的。OS命令注入攻擊指經過Web應用，執行非法的操做系統命令達到攻擊的目的。只要在能調用Shell函數的地方就有存在被攻擊的風險。假若調用Shell時存在疏漏，就能夠執行插入的非法命令。

命令注入攻擊能夠向Shell發送命令，讓Windows或Linux操做系統的命令行啓動程序。也就是說，經過命令注入攻擊可執行操做系統上安裝着的各類程序。

1.原理

黑客構造命令提交給web應用程序，web應用程序提取黑客構造的命令，拼接到被執行的命令中，因黑客注入的命令打破了原有命令結構，致使web應用執行了額外的命令，最後web應用程序將執行的結果輸出到響應頁面中。

咱們經過一個例子來講明其原理，假如須要實現一個需求：用戶提交一些內容到服務器，而後在服務器執行一些系統命令去返回一個結果給用戶

params.repo傳入的是 https://github.com/admin/admin.github.io.git 確實能從指定的 git repo 上下載到想要的代碼。
可是若是 params.repo 傳入的是 https://github.com/xx/xx.git && rm -rf /* && 剛好你的服務是用 root 權限起的就糟糕了。

2.如何防護

• 後端對前端提交內容進行規則限制（好比正則表達式）。

• 在調用系統命令前對全部傳入參數進行命令行參數轉義過濾。

• 不要直接拼接命令語句，藉助一些工具作拼接、轉義預處理，例如 Node.js 的 shell-escape npm包

參考資料

• 常見Web 安全攻防總結

• 前端面試之道

• 圖解Http

• Web安全知多少

• web安全之點擊劫持(clickjacking)

• URL重定向/跳轉漏洞

• 網易web白帽子

ps：轉自公衆號 浪裏行舟 IT平頭哥聯盟