在互聯網時代,數據安全與我的隱私受到了史無前例的挑戰,各類新奇的攻擊技術層出不窮。如何才能更好地保護咱們的數據?本文主要側重於分析幾種常見的攻擊的類型以及防護的方法。php
想閱讀更多優質原創文章請猛戳GitHub博客html
XSS (Cross-Site Scripting),跨站腳本攻擊,由於縮寫和 CSS重疊,因此只能叫 XSS。跨站腳本攻擊是指經過存在安全漏洞的Web網站註冊用戶的瀏覽器內運行非法的HTML標籤或JavaScript進行的一種攻擊。前端
跨站腳本攻擊有可能形成如下影響:mysql
XSS 的原理是惡意攻擊者往 Web 頁面裏插入惡意可執行網頁腳本代碼,當用戶瀏覽該頁之時,嵌入其中 Web 裏面的腳本代碼會被執行,從而能夠達到攻擊者盜取用戶信息或其餘侵犯用戶安全隱私的目的。git
XSS 的攻擊方式變幻無窮,但仍是能夠大體細分爲幾種類型。github
非持久型 XSS 漏洞,通常是經過給別人發送帶有惡意腳本代碼參數的 URL,當 URL 地址被打開時,特有的惡意代碼參數被 HTML 解析、執行。web
舉一個例子,好比頁面中包含有如下代碼:面試
<select> <script> document.write('' + '<option value=1>' + location.href.substring(location.href.indexOf('default=') + 8) + '</option>' ); document.write('<option value=2>English</option>'); </script> </select>
攻擊者能夠直接經過 URL (相似:https://xxx.com/xxx?default=<script>alert(document.cookie)</script>
) 注入可執行的腳本代碼。不過一些瀏覽器如Chrome其內置了一些XSS過濾器,能夠防止大部分反射型XSS攻擊。正則表達式
非持久型 XSS 漏洞攻擊有如下幾點特徵:sql
爲了防止出現非持久型 XSS 漏洞,須要確保這麼幾件事情:
URL
,document.referrer
,document.forms
等這種 DOM API 中獲取數據直接渲染。eval
, new Function()
,document.write()
,document.writeln()
,window.setInterval()
,window.setTimeout()
,innerHTML
,document.createElement()
等可執行字符串的方法。持久型 XSS 漏洞,通常存在於 Form 表單提交等交互功能,如文章留言,提交文本信息等,黑客利用的 XSS 漏洞,將內容經正常功能提交進入數據庫持久保存,當前端頁面得到後端從數據庫中讀出的注入代碼時,剛好將其渲染執行。
舉個例子,對於評論功能來講,就得防範持久型 XSS 攻擊,由於我能夠在評論中輸入如下內容
主要注入頁面方式和非持久型 XSS 漏洞相似,只不過持久型的不是來源於 URL,referer,forms 等,而是來源於後端從數據庫中讀出來的數據 。持久型 XSS 攻擊不須要誘騙點擊,黑客只須要在提交表單的地方完成注入便可,可是這種 XSS 攻擊的成本相對仍是很高。
攻擊成功須要同時知足如下幾個條件:
持久型 XSS 有如下幾個特色:
對於 XSS 攻擊來講,一般有兩種方式能夠用來防護。
CSP 本質上就是創建白名單,開發者明確告訴瀏覽器哪些外部資源能夠加載和執行。咱們只須要配置規則,如何攔截是由瀏覽器本身實現的。咱們能夠經過這種方式來儘可能減小 XSS 攻擊。
一般能夠經過兩種方式來開啓 CSP:
這裏以設置 HTTP Header 來舉例:
Content-Security-Policy: default-src 'self'
Content-Security-Policy: img-src https://*
Content-Security-Policy: child-src 'none'
如需瞭解更多屬性,請查看Content-Security-Policy文檔
對於這種方式來講,只要開發者配置了正確的規則,那麼即便網站存在漏洞,攻擊者也不能執行它的攻擊代碼,而且 CSP 的兼容性也不錯。
用戶的輸入永遠不可信任的,最廣泛的作法就是轉義輸入輸出的內容,對於引號、尖括號、斜槓進行轉義
function escape(str) { str = str.replace(/&/g, '&') str = str.replace(/</g, '<') str = str.replace(/>/g, '>') str = str.replace(/"/g, '&quto;') str = str.replace(/'/g, ''') str = str.replace(/`/g, '`') str = str.replace(/\//g, '/') return str }
可是對於顯示富文原本說,顯然不能經過上面的辦法來轉義全部字符,由於這樣會把須要的格式也過濾掉。對於這種狀況,一般採用白名單過濾的辦法,固然也能夠經過黑名單過濾,可是考慮到須要過濾的標籤和標籤屬性實在太多,更加推薦使用白名單的方式。
const xss = require('xss') let html = xss('<h1 id="title">XSS Demo</h1><script>alert("xss");</script>') // -> <h1>XSS Demo</h1><script>alert("xss");</script> console.log(html)
以上示例使用了 js-xss 來實現,能夠看到在輸出中保留了 h1 標籤且過濾了 script 標籤。
這是預防XSS攻擊竊取用戶cookie最有效的防護手段。Web應用程序在設置cookie時,將其屬性設爲HttpOnly,就能夠避免該網頁的cookie被客戶端惡意JavaScript竊取,保護用戶cookie信息。
CSRF(Cross Site Request Forgery),即跨站請求僞造,是一種常見的Web攻擊,它利用用戶已登陸的身份,在用戶絕不知情的狀況下,以用戶的名義完成非法操做。
下面先介紹一下CSRF攻擊的原理:
完成 CSRF 攻擊必需要有三個條件:
咱們來看一個例子: 當咱們登入轉帳頁面後,忽然眼前一亮驚現"XXX隱私照片,不看後悔一生"的連接,耐不住心裏躁動,立馬點擊了該危險的網站(頁面代碼以下圖所示),但當這頁面一加載,便會執行submitForm
這個方法來提交轉帳請求,從而將10塊轉給黑客。
防範 CSRF 攻擊能夠遵循如下幾種規則:
能夠對 Cookie 設置 SameSite 屬性。該屬性表示 Cookie 不隨着跨域請求發送,能夠很大程度減小 CSRF 的攻擊,可是該屬性目前並非全部瀏覽器都兼容。
HTTP Referer是header的一部分,當瀏覽器向web服務器發送請求時,通常會帶上Referer信息告訴服務器是從哪一個頁面連接過來的,服務器籍此能夠得到一些信息用於處理。能夠經過檢查請求的來源來防護CSRF攻擊。正常請求的referer具備必定規律,如在提交表單的referer一定是在該頁面發起的請求。因此經過檢查http包頭referer的值是否是這個頁面,來判斷是否是CSRF攻擊。
但在某些狀況下如從https跳轉到http,瀏覽器處於安全考慮,不會發送referer,服務器就沒法進行check了。若與該網站同域的其餘網站有XSS漏洞,那麼攻擊者能夠在其餘網站注入惡意腳本,受害者進入了此類同域的網址,也會遭受攻擊。出於以上緣由,沒法徹底依賴Referer Check做爲防護CSRF的主要手段。可是能夠經過Referer Check來監控CSRF攻擊的發生。
目前比較完善的解決方案是加入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錯誤。
應用程序和用戶進行交互過程當中,特別是帳戶交易這種核心步驟,強制用戶輸入驗證碼,才能完成最終請求。在一般狀況下,驗證碼夠很好地遏制CSRF攻擊。但增長驗證碼下降了用戶的體驗,網站不能給全部的操做都加上驗證碼。因此只能將驗證碼做爲一種輔助手段,在關鍵業務點設置驗證碼。
點擊劫持是一種視覺欺騙的攻擊手段。攻擊者將須要攻擊的網站經過 iframe 嵌套的方式嵌入本身的網頁中,並將 iframe 設置爲透明,在頁面中透出一個按鈕誘導用戶點擊。
用戶在登錄 A 網站的系統後,被攻擊者誘惑打開第三方網站,而第三方網站經過 iframe 引入了 A 網站的頁面內容,用戶在第三方網站中點擊某個按鈕(被裝飾的按鈕),其實是點擊了 A 網站的按鈕。
接下來咱們舉個例子:我在優酷發佈了不少視頻,想讓更多的人關注它,就能夠經過點擊劫持來實現
iframe { width: 1440px; height: 900px; position: absolute; top: -0px; left: -0px; z-index: 2; -moz-opacity: 0; opacity: 0; filter: alpha(opacity=0); } button { position: absolute; top: 270px; left: 1150px; z-index: 1; width: 90px; height:40px; } </style> ...... <button>點擊脫衣</button> <img src="http://pic1.win4000.com/wallpaper/2018-03-19/5aaf2bf0122d2.jpg"> <iframe src="http://i.youku.com/u/UMjA0NTg4Njcy" scrolling="no"></iframe>
從上圖可知,攻擊者經過圖片做爲頁面背景,隱藏了用戶操做的真實界面,當你按耐不住好奇點擊按鈕之後,真正的點擊的實際上是隱藏的那個頁面的訂閱按鈕,而後就會在你不知情的狀況下訂閱了。
X-FRAME-OPTIONS
是一個 HTTP 響應頭,在現代瀏覽器有一個很好的支持。這個 HTTP 響應頭 就是爲了防護用 iframe 嵌套的點擊劫持攻擊。
該響應頭有三個值可選,分別是
對於某些遠古瀏覽器來講,並不能支持上面的這種方式,那咱們只有經過 JS 的方式來防護點擊劫持了。
<head> <style id="click-jack"> html { display: none !important; } </style> </head> <body> <script> if (self == top) { var style = document.getElementById('click-jack') document.body.removeChild(style) } else { top.location = self.location } </script> </body>
以上代碼的做用就是當經過 iframe 的方式加載頁面時,攻擊者的網頁直接不顯示全部內容了。
定義:藉助未驗證的URL跳轉,將應用程序引導到不安全的第三方區域,從而致使的安全問題。
黑客利用URL跳轉漏洞來誘導安全意識低的用戶點擊,致使用戶信息泄露或者資金的流失。其原理是黑客構建惡意連接(連接須要進行假裝,儘量迷惑),發在QQ羣或者是瀏覽量多的貼吧/論壇中。
安全意識低的用戶點擊後,通過服務器或者瀏覽器解析後,跳到惡意的網站中。
惡意連接須要進行假裝,常常的作法是熟悉的連接後面加上一個惡意的網址,這樣才迷惑用戶。
諸如假裝成像以下的網址,你是否可以識別出來是惡意網址呢?
http://gate.baidu.com/index?act=go&url=http://t.cn/RVTatrd http://qt.qq.com/safecheck.html?flag=1&url=http://t.cn/RVTatrd http://tieba.baidu.com/f/user/passport?jumpUrl=http://t.cn/RVTatrd
這裏咱們舉個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
這個惡意網址。
若是肯定傳遞URL參數進入的來源,咱們能夠經過該方式實現安全限制,保證該URL的有效性,避免惡意用戶本身生成跳轉連接
咱們保證全部生成的連接都是來自於咱們可信域的,經過在生成的連接里加入用戶不可控的Token對生成的連接進行校驗,能夠避免用戶生成本身的惡意連接從而被利用,可是若是功能自己要求比較開放,可能致使有必定的限制。
SQL注入是一種常見的Web安全漏洞,攻擊者利用這個漏洞,能夠訪問或修改數據,或者利用潛在的數據庫漏洞進行攻擊。
咱們先舉一個萬能鑰匙的例子來講明其原理:
<form action="/login" method="POST"> <p>Username: <input type="text" name="username" /></p> <p>Password: <input type="password" name="password" /></p> <p><input type="submit" value="登錄" /></p> </form>
後端的 SQL 語句多是以下這樣的:
let querySQL = ` SELECT * FROM user WHERE username='${username}' AND psw='${password}' `; // 接下來就是執行 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注入的必備條件:
1.能夠控制輸入的數據
2.服務器要執行的代碼拼接了控制的數據**。
咱們會發現SQL注入流程中與正常請求服務器相似,只是黑客控制了數據,構造了SQL查詢,而正常的請求不會SQL查詢這一步,SQL注入的本質:數據和代碼未分離,即數據當作了代碼來執行。
獲取數據庫信息
OS命令注入和SQL注入差很少,只不過SQL注入是針對數據庫的,而OS命令注入是針對操做系統的。OS命令注入攻擊指經過Web應用,執行非法的操做系統命令達到攻擊的目的。只要在能調用Shell函數的地方就有存在被攻擊的風險。假若調用Shell時存在疏漏,就能夠執行插入的非法命令。
命令注入攻擊能夠向Shell發送命令,讓Windows或Linux操做系統的命令行啓動程序。也就是說,經過命令注入攻擊可執行操做系統上安裝着的各類程序。
黑客構造命令提交給web應用程序,web應用程序提取黑客構造的命令,拼接到被執行的命令中,因黑客注入的命令打破了原有命令結構,致使web應用執行了額外的命令,最後web應用程序將執行的結果輸出到響應頁面中。
咱們經過一個例子來講明其原理,假如須要實現一個需求:用戶提交一些內容到服務器,而後在服務器執行一些系統命令去返回一個結果給用戶
// 以 Node.js 爲例,假如在接口中須要從 github 下載用戶指定的 repo const exec = require('mz/child_process').exec; let params = {/* 用戶輸入的參數 */}; exec(`git clone ${params.repo} /some/path`);
若是 params.repo
傳入的是 https://github.com/admin/admin.github.io.git
確實能從指定的 git repo 上下載到想要的代碼。
可是若是 params.repo
傳入的是 https://github.com/xx/xx.git && rm -rf /* &&
剛好你的服務是用 root 權限起的就糟糕了。
shell-escape npm
包給你們推薦一個好用的BUG監控工具Fundebug,歡迎免費試用!