Web 安全是互聯(lián)網(wǎng)中不可或缺的一個領(lǐng)域，這個領(lǐng)域中誕生了大量的黑帽子與白帽子，他們都是安全領(lǐng)域的王者，在平時里，他們利用各種巧妙的技術(shù)互相博弈，時不時就會掀起一場 Web 安全浪潮，真可謂神仙打架，各顯神通。

本文從一個吃瓜群眾的角度，聊一聊 Web 安全的一些有趣故事。

安全世界觀

安全攻防案例

總結(jié)與思考

安全世界觀

在互聯(lián)網(wǎng)發(fā)展之初，IE 瀏覽器壟斷的時期，大家上網(wǎng)的目的都很單純，主要通過瀏覽器分享信息，獲取新聞。但隨著互聯(lián)網(wǎng)的不斷發(fā)展發(fā)展，一個網(wǎng)頁能做的事情越來越多，除了看新聞，我們還可以看視頻、玩游戲、購物、聊天等，這些功能都大大豐富了我們的生活。

隨著網(wǎng)頁功能的逐漸增多，就開始出現(xiàn)了一些黑帽子，他們試圖通過一些技術(shù)手段來牟取利益。在我小的時候，印象最深的就是木馬病毒，它可以監(jiān)控你的鍵盤，將你在鍵盤上敲打的內(nèi)容發(fā)送到黑客的機器上，黑客通過分析這些內(nèi)容，很容易就能得到你的游戲賬號和密碼。

在這之后，就誕生出了一些殺毒軟件，致力于解決網(wǎng)絡(luò)上的各種病毒，隨著不斷地發(fā)展，殺毒軟件已經(jīng)成為一臺電腦必不可少的軟件。

為什么會出現(xiàn)這樣的安全問題？

安全歸根到底是信任的問題，如果所有人都按照正常的流程去上網(wǎng)，不去謀取私利，也就沒有安全問題可談了。

安全的根本在于信任，但要讓所有人互相信任談何容易。在當(dāng)前階段，我們可以做到：持續(xù)做好安全防護，讓漏洞越來越少，非法攻擊越來越困難，這樣就能逐漸減少黑帽子的數(shù)量，讓病毒制造者越來越少。

如何做好安全

要做好安全，首先得理解安全問題的屬性，前人通過無數(shù)實踐，最后將安全的屬性總結(jié)為安全三要素，分別為：機密性、完整性、可用性。

機密性

保護數(shù)據(jù)內(nèi)容不被泄露。

通常使用加密的方法。

完整性

保護數(shù)據(jù)內(nèi)容是完整的、沒有被篡改。

通常使用數(shù)字簽名的方法。

可用性

數(shù)據(jù)隨時都能夠使用。

通常是在防御 DOS。

有了安全 3 要素之后，我們就可以對安全問題進行評估了。

資產(chǎn)等級劃分

找出最重要的數(shù)據(jù)。

找出最重要數(shù)據(jù)的宿主空間，如：在數(shù)據(jù)庫里，那么數(shù)據(jù)庫就得重點防御。

找出數(shù)據(jù)庫的宿主空間，如：在一臺服務(wù)器上，那么這臺服務(wù)器就得做次等防御。

找出服務(wù)器的宿主空間，如：在 OSI 網(wǎng)絡(luò)層級上，那么在網(wǎng)絡(luò)層面就得做一般防御。

威脅分析

找出威脅（可能造成危害的來源）。

找出風(fēng)險（可能出現(xiàn)的損失叫做風(fēng)險）。

風(fēng)險分析

采取多標(biāo)準(zhǔn)決策分析，即：風(fēng)險 = 威脅等級 * 威脅可行性。

計算所有的威脅，將最終的風(fēng)險進行排序，優(yōu)先解決風(fēng)險大的問題。

確認(rèn)解決方案

找出不安全的實現(xiàn)方式，并確定解決方案。

解決方案不要改變商業(yè)需求的初衷。

解決方案需對用戶透明，不要改變用戶的習(xí)慣。

做好安全評估之后，我們就有了一份安全解決方案，后續(xù)的安全工作只需按照這個方案去做，就沒有任何問題。

安全的原則

有了安全解決方案之后，我們還可以制定一些安全原則，遵守原則做事，可以讓我們事半功倍。

黑名單、白名單原則

白名單方案指的是給安全的資源授權(quán)。

黑名單方案指的是禁用不安全的資源。

我們應(yīng)該優(yōu)先使用白名單方案，因為黑名單通常統(tǒng)計不完所有的不安全資源。

如：XSS 攻擊的方式非常多，可以通過 script、css、image 標(biāo)簽等，盡管你將這些標(biāo)簽都加入黑名單，也不能保證其他的標(biāo)簽都沒有 XSS 的攻擊隱患。

最小權(quán)限原則

只授予必要的權(quán)限，不要過度授權(quán)，減少出錯機會。

如：普通權(quán)限的 Linux 用戶只能操作 ~ 文件夾下的目錄，如果有人想刪庫跑路，在執(zhí)行 rm -rf / 時，就會提示無權(quán)限。

縱深防御原則

這條原則類似 木桶理論，安全水平往往取決于最短的那塊板。

即：不要留下短板，黑帽子們往往可以利用短板為突破口，挖掘更大的漏洞。

數(shù)據(jù)與代碼分離原則

當(dāng)用戶數(shù)據(jù)被當(dāng)成代碼執(zhí)行時，混淆了數(shù)據(jù)和代碼的邊界，從而導(dǎo)致安全問題。

如：XSS 就是利用這一點去攻擊的。

不可預(yù)測性原則

這條原則是為了提高攻擊門檻，有效防止基于篡改、偽造的攻擊。

如：數(shù)據(jù)庫中使用 uuid 代替 number 型的自增主鍵，可以避免 id 被攻擊者猜到，從而進行批量操作。

token 也是利用不可預(yù)測性，攻擊者無法構(gòu)造 token 也就無法進行攻擊。

有了這些安全原則，我們就可以開干了，接下來介紹幾個常見的攻防案例。

安全攻防案例

安全攻防的案例非常多，這里主要介紹幾個出鏡率比較高的安全問題。

客戶端攻擊

XSS 攻擊

CSRF 攻擊

點擊劫持

XSS 攻擊

XSS 攻擊的本質(zhì)是將用戶數(shù)據(jù)當(dāng)成了 HTML 代碼一部分來執(zhí)行，從而混淆原本的語義，產(chǎn)生新的語義。

如圖所示，我們注冊了一個 <script>alert(document.cookie)</script> 的用戶名，所有能看到此用戶名字的頁面，都會彈出當(dāng)前瀏覽器的 Cookie，如果代碼的邏輯是將 Cookie 發(fā)送到攻擊者的網(wǎng)站，攻擊者就能冒充當(dāng)前用戶進行登錄了。

XSS 攻擊方式有很多，所有和用戶交互的地方，都有可能存在 XSS 攻擊。

例如：

所有 input 框。

window.location。

window.name。

document.referrer。

document.cookie。

localstorage。

...

由于頁面中與用戶交互的地方非常多，肯定還有一些 XSS 的攻擊方式?jīng)]有被發(fā)現(xiàn)，而一旦被黑帽子發(fā)現(xiàn)，就可能造成嚴(yán)重的影響，所以我們務(wù)必引起重視。

XSS 攻擊影響

被 XSS 攻擊成功后，攻擊者就可以獲取大量的用戶信息，例如：

識別用戶 UA。

識別用戶瀏覽器擴展。

識別用戶瀏覽過的網(wǎng)站。

通過 CSS 的 Visited 屬性。

獲取用戶真實的 IP。

通過 WebRTC 等。

盜取 Cookie

偽造用戶登錄，竊取用戶資料。

XSS 釣魚。

向頁面注入一個登錄彈窗，讓用戶認(rèn)為是網(wǎng)站內(nèi)的登錄彈窗（其實是釣魚網(wǎng)站的），一旦用戶登錄，賬號密碼就泄露給了釣魚網(wǎng)站。

XSS 攻擊防御

目前來說，XSS 已經(jīng)得到了互聯(lián)網(wǎng)行業(yè)的重視，許多開發(fā)框架都內(nèi)置了安全的 HTML 渲染方法。

我們也可以自定義進行一些安全配置。

配置 HTTP 中的 http-only 頭，讓前端 JS 不能操作 Cookie。

輸入檢查，在用戶提交數(shù)據(jù)時，使用 XssFilter 過濾掉不安全的數(shù)據(jù)。

輸出檢查，在頁面渲染的時候，過濾掉危險的數(shù)據(jù)。

CSRF 攻擊

CSRF（Cross-site request forgery）跨站請求偽造，是一種利用用戶身份，執(zhí)行一些用戶非本意的操作。

如圖所示：

用戶先登錄了服務(wù)器 B，然后去訪問服務(wù)器 C。

服務(wù)器 C 通過惡意腳本，冒充 A 去調(diào)用服務(wù)器 B 上的某個功能，

對于服務(wù)器 B 來說，還以為這是 A 發(fā)起的請求，就當(dāng)作正常請求處理了。

試想一下，如果 C 冒充 A 進行了一次轉(zhuǎn)賬，必定會造成大量的經(jīng)濟損失。

CSRF 防御方式

防御 CSRF 主要有以下幾種方式：

驗證碼

每一次請求都要求用戶驗證，以確保請求真實可靠。

即：利用惡意腳本不能識別復(fù)雜的驗證碼的特點，保證每次請求都是合法的。

Referer 檢查

檢查發(fā)起請求的服務(wù)器，是否為目標(biāo)服務(wù)器。

即：HTTP 請求中的 Referer 頭傳遞了當(dāng)前請求的域名，如果此域名是非法服務(wù)器的域名，則需要禁止訪問。

Token

利用不可預(yù)測性原則，每一請求必須帶上一段隨機碼，這段隨機碼由正常用戶保存，黑帽子不知道隨機碼，也就無法冒充用戶進行請求了。

點擊劫持

點擊劫持是一種視覺欺騙的攻擊手段。攻擊者將需要攻擊的網(wǎng)站通過 iframe 嵌套的方式嵌入自己的網(wǎng)頁中，并將 iframe 設(shè)置為透明，在頁面中透出一個按鈕誘導(dǎo)用戶點擊。

就像一張圖片上面鋪了一層透明的紙一樣，你看到的是攻擊者的頁面，但是其實這個頁面只是在底部，而你真正點擊的是被攻擊者透明化的另一個網(wǎng)頁。

如果所示，當(dāng)你點擊了頁面上的按鈕之后，本以為會...... ，而真正執(zhí)行的操作是關(guān)注了某人的博客。

點擊劫持防御

由于點擊劫持主要通過 iframe，所以在防御時，主要基于 iframe 去做。

方案一：frame busting

正常網(wǎng)站使用 JS 腳本判斷是否被惡意網(wǎng)站嵌入，如：博客網(wǎng)站監(jiān)測到被一個 iframe 打開，自動跳轉(zhuǎn)到正常的頁面即可。

if (self !== top) {  // 跳回原頁面  top.location = self.location;}

方案二：使用 HTTP 中的 x-frame-options 頭，控制 iframe 的加載，它有 3 個值可選：

DENY，表示頁面不允許通過 iframe 的方式展示。

SAMEORIGIN，表示頁面可以在相同域名下通過 iframe 的方式展示。

ALLOW-FROM，表示頁面可以在指定來源的 iframe 中展示。

配置 iframe 的 sandbox 屬性

sandbox = "allow-same-origin" 則只能加載與主站同域的資源。

服務(wù)器端攻擊

服務(wù)器端的攻擊的方式也非常多，這里列舉幾個常見的。

SQL 注入攻擊

文件上傳漏洞

登錄認(rèn)證攻擊

應(yīng)用層拒絕服務(wù)攻擊

webServer 配置安全

SQL 注入攻擊

SQL 注入和 XSS 一樣，都是違背了數(shù)據(jù)和代碼分離原則導(dǎo)致的攻擊方式。

如圖所示，我們利用 SQL 注入，就能在不需要密碼的情況下，直接登錄管理員的賬號。

攻擊的前提是：后端只用了簡單的拼接 SQL 的方式去查詢數(shù)據(jù)。

# 拼接出來的 sql 如下：select * from user where username = 'admin' or 1=1 and password = 'xxx'# 無論密碼輸入什么，這條 sql 語句都能查詢到管理員的信息

除此之外，SQL 注入還有以下幾種方式：

使用 SQL 探測，猜數(shù)據(jù)庫表名，列名。

通過 MySQL 內(nèi)置的 benchmark 探測數(shù)據(jù)庫字段。

如：一段偽代碼 select database as current if current[0]==='a',benchmark（10000,'猜對了'） 如果表明猜對了，就延遲 10 s 并返回成功。

使用存儲過程執(zhí)行系統(tǒng)命令

通過內(nèi)置的方法或存儲過程執(zhí)行 shell 腳本。

如：xp_cmdshell、sys_eval、sys_exec 等。

字符串截斷

如：MySQL 在處理超長的字符串時，會顯示警告，但會執(zhí)行成功。

注冊一個 admin + 50 個空格的用戶，會觸發(fā)截斷，最終新增一個 admin 用戶，這樣就能擁有管理員權(quán)限了。

SQL 注入防御

防止 SQL 注入的最好的辦法就是，不要手動拼接 SQL 語句。

最佳方案，使用預(yù)編譯語句綁定變量

通常是指框架提供的拼接 SQL 變量的方法。

這樣的語義不會發(fā)生改變，變量始終被當(dāng)成變量。

嚴(yán)格限制數(shù)據(jù)類型，如果注入了其他類型的數(shù)據(jù)，直接報錯，不允許執(zhí)行。

使用安全的存儲過程和系統(tǒng)函數(shù)。

CRLF 注入

在注入攻擊中，換行符注入也是非常常見的一種攻擊方式。

如果在 HTTP 請求頭中注入 2 個換行符，會導(dǎo)致?lián)Q行符后面的所有內(nèi)容都被解析成請求實體部分。

攻擊者通常在 Set-Cookie 時，注入換行符，控制請求傳遞的內(nèi)容。

文件上傳漏洞

上傳文件是網(wǎng)頁開發(fā)中的一個常見功能，如果不加處理，很容易就會造成攻擊。

如圖所示，攻擊者上傳了一個木馬文件，并且通過返回的 URL 進行訪問，就能控制服務(wù)器。

通常我們會控制上傳文件的后綴名，但也不能完全解決問題，攻擊者還可以通過以下方式進行攻擊：

偽造正常文件

將木馬文件偽裝成正常的后綴名進行上傳。

如果要避免這個問題，我們可以繼續(xù)判斷上傳文件的文件頭前 10 個字節(jié)。

Apache 解析方式是從后往前解析，直到找到一個認(rèn)識的后綴名為止

如：上傳一個 abc.php.rar.rar.rar 能繞過后綴名檢查，但在執(zhí)行時，被當(dāng)成一個 php 文件進行執(zhí)行。

IIS 會截斷分號進行解析

如：abc.asp;xx.png 能繞過后綴名檢查，但在執(zhí)行時，被當(dāng)成一個 asp 文件進行執(zhí)行。

HTTP PUT 方法允許將文件上傳到指定位置

通過 HTTP MOVE 方法，還能修改上傳的文件名。

通過二者配合，就能先上傳一個正常的后綴名，然后改為一個惡意的后綴名。

PHP CGI 路徑問題

執(zhí)行 http://abc.com/test.png/xxx.php 時，會把 test.png 當(dāng)做 php 文件去解析。

如果用戶正好是把一段惡意的 php 腳本當(dāng)做一張圖片進行上傳，就會觸發(fā)這個攻擊。

文件上傳漏洞防御

防御文件上傳漏洞，可以從以下幾點考慮：

將文件上傳的目錄設(shè)置為不可執(zhí)行。

判斷文件類型

檢查 MIME Type，配置白名單。

檢查后綴名，配置白名單。

使用隨機數(shù)改寫文件名和文件路徑

上傳文件后，隨機修改文件名，讓攻擊者無法執(zhí)行攻擊。

單獨設(shè)置文件服務(wù)器的域名

單獨做一個文件服務(wù)器，并使用單獨的域名，利用同源策略，規(guī)避客戶端攻擊。

通常做法是將靜態(tài)資源存放在 CDN 上。

登錄認(rèn)證攻擊

登錄認(rèn)證攻擊可以理解為一種破解登錄的方法。攻擊者通常采用以下幾種方式進行破解：

彩虹表

攻擊者通過搜集大量明文和 MD5 的對應(yīng)關(guān)系，用于破解 MD5 密文找出原文。

對于彩虹表中的 MD5 密碼，我們可以加鹽，進行二次加密，避免被破解。

Session Fixation 攻擊

利用應(yīng)用系統(tǒng)在服務(wù)器的 SessionID 固定不變機制，借助他人用相同的 SessionID 獲取認(rèn)證和授權(quán)。

攻擊者登錄失敗后，后端返回了 SessionID，攻擊者將 SessionID 交給正常用戶去登錄，登錄成功后，攻擊者就能使用這個 SessionID 冒充正常用戶登錄了。

如果瀏覽器每一次登錄都刷新 SessionID 可以避免這個問題。

Session 保持攻擊

有些時候，后端出于用戶體驗考慮，只要這個用戶還活著，就不會讓這個用戶的 Session 失效。

攻擊者可以通過不停發(fā)起請求，可以讓這個 Session 一直活下去。

登錄認(rèn)證防御方式

多因素認(rèn)證

密碼作為第一道防御，但在密碼驗證成功后，我們還可以繼續(xù)驗證：動態(tài)口令，數(shù)字證書，短信驗證碼等，以保證用戶安全。

由于短信和網(wǎng)頁完全是 2 套獨立的系統(tǒng)，攻擊者很難獲取到短信驗證碼，也就無法進行攻擊。

除此之外，前端登錄認(rèn)證還有多種方式，如果你對此感興趣，可以參考我之前寫的 前端登錄，這一篇就夠了。

應(yīng)用層拒絕服務(wù)攻擊

應(yīng)用層拒絕服務(wù)攻擊，又叫 DDOS 攻擊，它指的是利用大量的請求造成資源過載，導(dǎo)致服務(wù)器不可用。

通常有以下幾種 DDOS 攻擊方式：

SYN Flood 洪水攻擊

利用 HTTP 3 次握手機制，消耗服務(wù)器連接資源。

如：攻擊者發(fā)起大量的 HTTP 請求，但并不完成 3 次握手，而是只握手 2 次，這時服務(wù)器端會繼續(xù)等待直至超時。這時的服務(wù)器會一直忙于處理大量的垃圾請求，而無暇顧及正常請求。

Slowloris 攻擊

以非常低的速度發(fā)送 HTTP 請求頭，消耗服務(wù)器連接資源。

如：攻擊者發(fā)送大量 HTTP 請求，但每個請求頭都發(fā)的很慢，每隔 10s 發(fā)送一個字符，服務(wù)器為了等待數(shù)據(jù)，不得始終保持連接，這樣一來，服務(wù)器連接數(shù)很快就被占光了。

HTTP POST DOS

發(fā)送 HTTP 時，指定一個非常大的 Content-Length 然后以很長的間隔發(fā)送，消耗服務(wù)器連接資源。

CC 攻擊

針對一些非常消耗資源的頁面，不斷發(fā)起請求。

如：頁面中的某些頁面，需要后端做大量的運算，或者需要做非常耗時的數(shù)據(jù)庫查詢。在大量的請求下，服務(wù)器的 CPU、內(nèi)存等資源可能就被占光了。

Server Limit DOS

通過 XSS 注入一段超長的 Cookie，導(dǎo)致超出 Web 服務(wù)器所能承受的 Request Header 長度，服務(wù)器端就會拒絕此服務(wù)。

ReDOS

針對一些缺陷的正則表達(dá)式，發(fā)起大量請求，耗光系統(tǒng)資源。

應(yīng)用層拒絕服務(wù)攻擊防御

對于應(yīng)用層拒絕服務(wù)攻擊，目前也沒有特別完美的解決方案，不過我們還是可以進行一些優(yōu)化。

應(yīng)用代碼做好性能優(yōu)化

合理使用 Redis、Memcache 等緩存方案，減少 CPU 資源使用率。

網(wǎng)絡(luò)架構(gòu)上做好優(yōu)化

后端搭建負(fù)載均衡。

靜態(tài)資源使用 CDN 進行管理。

限制請求頻率

服務(wù)器計算所有 IP 地址的請求頻率，篩選出異常的 IP 進行禁用。

可以使用 LRU 算法，緩存前 1000 條請求的 IP，如果有 IP 請求頻率過高，就進行禁用。

其實，處理 DDOS 核心思路就是禁用不可信任的用戶，確保資源都是被正常的用戶所使用。

WebServer 配置安全

我們在部署 web 應(yīng)用的時候，經(jīng)常會用到 Nginx、Apache、IIS、Tomcat、Jboss 等 Web 服務(wù)器，這些服務(wù)器本身也存在一些安全隱患，如果配置不當(dāng)，很容易收到攻擊。

在配置 Web 服務(wù)器時，可以參考以下幾點：

以用戶權(quán)限運行 Web 服務(wù)器

遵守最小權(quán)限原則，以最小權(quán)限身份運行 Web 服務(wù)器，限制被入侵后的權(quán)限。

刪除可視化后臺

運行 Tomcat、Jboss 等 Web 服務(wù)器時，默認(rèn)會開啟一個可視化的運營后臺，運行在 8080 端口，并且第一次訪問是沒有認(rèn)證的。

攻擊者可以利用可視化后臺，遠(yuǎn)程加載一段 war 包或者上傳木馬文件，進行控制。

及時更新版本

主流的 Web 服務(wù)器，每隔一段時間就會修復(fù)一些漏洞，所以記得及時更新版本。

總結(jié)與思考

本文介紹了 Web 安全的基本概念，以及大量的攻防技巧，其實這只是 Web 安全中的冰山一角，如果你對此感興趣，不妨在安全領(lǐng)域繼續(xù)深耕學(xué)習(xí)，一定能看到更廣闊一片天。

對于一個開發(fā)者來說，我們應(yīng)該在寫代碼時就將安全考慮其中，形成自己的一套安全開發(fā)體系，做到心中有安全，時時考慮安全，就能無形之中化解不法分子的攻擊。

藍(lán)藍(lán)設(shè)計( m.cqzjtgb.com )是一家專注而深入的界面設(shè)計公司，為期望卓越的國內(nèi)外企業(yè)提供卓越的UI界面設(shè)計、BS界面設(shè)計 、 cs界面設(shè)計 、 ipad界面設(shè)計 、 包裝設(shè)計 、 圖標(biāo)定制 、 用戶體驗 、交互設(shè)計、 網(wǎng)站建設(shè) 、平面設(shè)計服務(wù)