// 每日前端夜話(huà) 第369篇
Web 安全是互聯(lián)網(wǎng)中不可或缺的一個(gè)領(lǐng)域，這個(gè)領(lǐng)域中誕生了大量的黑帽子與白帽子，他們都是安全領(lǐng)域的王者，在平時(shí)里，他們利用各種巧妙的技術(shù)互相博弈，時(shí)不時(shí)就會(huì)掀起一場(chǎng) Web 安全浪潮，真可謂神仙打架，各顯神通。
本文從一個(gè)吃瓜群眾的角度，聊一聊 Web 安全的一些有趣故事。
安全世界觀 在互聯(lián)網(wǎng)發(fā)展之初，IE 瀏覽器壟斷的時(shí)期，大家上網(wǎng)的目的都很單純，主要通過(guò)瀏覽器分享信息，獲取新聞。但隨著互聯(lián)網(wǎng)的不斷發(fā)展發(fā)展，一個(gè)網(wǎng)頁(yè)能做的事情越來(lái)越多，除了看新聞，我們還可以看視頻、玩游戲、購(gòu)物、聊天等，這些功能都大大豐富了我們的生活。
隨著網(wǎng)頁(yè)功能的逐漸增多，就開(kāi)始出現(xiàn)了一些黑帽子，他們?cè)噲D通過(guò)一些技術(shù)手段來(lái)牟取利益。在我小的時(shí)候，印象最深的就是木馬病毒，它可以監(jiān)控你的鍵盤(pán)，將你在鍵盤(pán)上敲打的內(nèi)容發(fā)送到黑客的機(jī)器上，黑客通過(guò)分析這些內(nèi)容，很容易就能得到你的游戲賬號(hào)和密碼。
在這之后，就誕生出了一些殺毒軟件，致力于解決網(wǎng)絡(luò)上的各種病毒，隨著不斷地發(fā)展，殺毒軟件已經(jīng)成為一臺(tái)電腦必不可少的軟件。
? 為什么會(huì)出現(xiàn)這樣的安全問(wèn)題？
安全歸根到底是信任的問(wèn)題 ，如果所有人都按照正常的流程去上網(wǎng)，不去謀取私利，也就沒(méi)有安全問(wèn)題可談了。
? 安全的根本在于信任，但要讓所有人互相信任談何容易。在當(dāng)前階段，我們可以做到：持續(xù)做好安全防護(hù)，讓漏洞越來(lái)越少，非法攻擊越來(lái)越困難，這樣就能逐漸減少黑帽子的數(shù)量，讓病毒制造者越來(lái)越少。
要做好安全，首先得理解安全問(wèn)題的屬性，前人通過(guò)無(wú)數(shù)實(shí)踐，最后將安全的屬性總結(jié)為安全三要素，分別為：機(jī)密性、完整性、可用性。
保護(hù)數(shù)據(jù)內(nèi)容不被泄露。 保護(hù)數(shù)據(jù)內(nèi)容是完整的、沒(méi)有被篡改。 有了安全 3 要素之后，我們就可以對(duì)安全問(wèn)題進(jìn)行評(píng)估了。
找出最重要數(shù)據(jù)的宿主空間，如：在數(shù)據(jù)庫(kù)里，那么數(shù)據(jù)庫(kù)就得重點(diǎn)防御。 找出數(shù)據(jù)庫(kù)的宿主空間，如：在一臺(tái)服務(wù)器上，那么這臺(tái)服務(wù)器就得做次等防御。 找出服務(wù)器的宿主空間，如：在 OSI 網(wǎng)絡(luò)層級(jí)上，那么在網(wǎng)絡(luò)層面就得做一般防御。 找出風(fēng)險(xiǎn)（可能出現(xiàn)的損失叫做風(fēng)險(xiǎn)）。 采取多標(biāo)準(zhǔn)決策分析，即：風(fēng)險(xiǎn) = 威脅等級(jí) * 威脅可行性。 計(jì)算所有的威脅，將最終的風(fēng)險(xiǎn)進(jìn)行排序，優(yōu)先解決風(fēng)險(xiǎn)大的問(wèn)題。 找出不安全的實(shí)現(xiàn)方式，并確定解決方案。 解決方案需對(duì)用戶(hù)透明，不要改變用戶(hù)的習(xí)慣。 做好安全評(píng)估之后，我們就有了一份安全解決方案，后續(xù)的安全工作只需按照這個(gè)方案去做，就沒(méi)有任何問(wèn)題。
有了安全解決方案之后，我們還可以制定一些安全原則，遵守原則做事，可以讓我們事半功倍。
我們應(yīng)該優(yōu)先使用白名單方案，因?yàn)楹诿麊瓮ǔ＝y(tǒng)計(jì)不完所有的不安全資源。 如：XSS 攻擊的方式非常多，可以通過(guò) script、css、image 標(biāo)簽等，盡管你將這些標(biāo)簽都加入黑名單，也不能保證其他的標(biāo)簽都沒(méi)有 XSS 的攻擊隱患。 只授予必要的權(quán)限，不要過(guò)度授權(quán)，減少出錯(cuò)機(jī)會(huì)。 如：普通權(quán)限的 Linux 用戶(hù)只能操作 ~ 文件夾下的目錄，如果有人想刪庫(kù)跑路，在執(zhí)行 rm -rf / 時(shí)，就會(huì)提示無(wú)權(quán)限。 這條原則類(lèi)似 木桶理論，安全水平往往取決于最短的那塊板。 即：不要留下短板，黑帽子們往往可以利用短板為突破口，挖掘更大的漏洞。 當(dāng)用戶(hù)數(shù)據(jù)被當(dāng)成代碼執(zhí)行時(shí)，混淆了數(shù)據(jù)和代碼的邊界，從而導(dǎo)致安全問(wèn)題。 這條原則是為了提高攻擊門(mén)檻，有效防止基于篡改、偽造的攻擊。 如：數(shù)據(jù)庫(kù)中使用 uuid 代替 number 型的自增主鍵，可以避免 id 被攻擊者猜到，從而進(jìn)行批量操作。 token 也是利用不可預(yù)測(cè)性，攻擊者無(wú)法構(gòu)造 token 也就無(wú)法進(jìn)行攻擊。 有了這些安全原則，我們就可以開(kāi)干了，接下來(lái)介紹幾個(gè)常見(jiàn)的攻防案例。
安全攻防案例 安全攻防的案例非常多，這里主要介紹幾個(gè)出鏡率比較高的安全問(wèn)題。
XSS 攻擊的本質(zhì)是將用戶(hù)數(shù)據(jù)當(dāng)成了 HTML 代碼一部分來(lái)執(zhí)行，從而混淆原本的語(yǔ)義，產(chǎn)生新的語(yǔ)義。
如圖所示，我們注冊(cè)了一個(gè) <script>alert(document.cookie)</script> 的用戶(hù)名，所有能看到此用戶(hù)名字的頁(yè)面，都會(huì)彈出當(dāng)前瀏覽器的 Cookie，如果代碼的邏輯是將 Cookie 發(fā)送到攻擊者的網(wǎng)站，攻擊者就能冒充當(dāng)前用戶(hù)進(jìn)行登錄了。
XSS 攻擊方式有很多，所有和用戶(hù)交互的地方，都有可能存在 XSS 攻擊。
例如：
由于頁(yè)面中與用戶(hù)交互的地方非常多，肯定還有一些 XSS 的攻擊方式?jīng)]有被發(fā)現(xiàn)，而一旦被黑帽子發(fā)現(xiàn)，就可能造成嚴(yán)重的影響，所以我們務(wù)必引起重視。
XSS 攻擊影響 被 XSS 攻擊成功后，攻擊者就可以獲取大量的用戶(hù)信息，例如：
識(shí)別用戶(hù)瀏覽過(guò)的網(wǎng)站。
通過(guò) CSS 的 Visited 屬性。 向頁(yè)面注入一個(gè)登錄彈窗，讓用戶(hù)認(rèn)為是網(wǎng)站內(nèi)的登錄彈窗（其實(shí)是釣魚(yú)網(wǎng)站的），一旦用戶(hù)登錄，賬號(hào)密碼就泄露給了釣魚(yú)網(wǎng)站。 XSS 攻擊防御 目前來(lái)說(shuō)，XSS 已經(jīng)得到了互聯(lián)網(wǎng)行業(yè)的重視，許多開(kāi)發(fā)框架都內(nèi)置了安全的 HTML 渲染方法。
我們也可以自定義進(jìn)行一些安全配置。
配置 HTTP 中的 http-only 頭，讓前端 JS 不能操作 Cookie。 輸入檢查，在用戶(hù)提交數(shù)據(jù)時(shí)，使用 XssFilter 過(guò)濾掉不安全的數(shù)據(jù)。 輸出檢查，在頁(yè)面渲染的時(shí)候，過(guò)濾掉危險(xiǎn)的數(shù)據(jù)。 CSRF（Cross-site request forgery）跨站請(qǐng)求偽造，是一種利用用戶(hù)身份，執(zhí)行一些用戶(hù)非本意的操作。
如圖所示：
用戶(hù)先登錄了服務(wù)器 B，然后去訪(fǎng)問(wèn)服務(wù)器 C。 服務(wù)器 C 通過(guò)惡意腳本，冒充 A 去調(diào)用服務(wù)器 B 上的某個(gè)功能， 對(duì)于服務(wù)器 B 來(lái)說(shuō)，還以為這是 A 發(fā)起的請(qǐng)求，就當(dāng)作正常請(qǐng)求處理了。 試想一下，如果 C 冒充 A 進(jìn)行了一次轉(zhuǎn)賬，必定會(huì)造成大量的經(jīng)濟(jì)損失。
CSRF 防御方式 防御 CSRF 主要有以下幾種方式：
每一次請(qǐng)求都要求用戶(hù)驗(yàn)證，以確保請(qǐng)求真實(shí)可靠。 即：利用惡意腳本不能識(shí)別復(fù)雜的驗(yàn)證碼的特點(diǎn)，保證每次請(qǐng)求都是合法的。 檢查發(fā)起請(qǐng)求的服務(wù)器，是否為目標(biāo)服務(wù)器。 即：HTTP 請(qǐng)求中的 Referer 頭傳遞了當(dāng)前請(qǐng)求的域名，如果此域名是非法服務(wù)器的域名，則需要禁止訪(fǎng)問(wèn)。 利用不可預(yù)測(cè)性原則，每一請(qǐng)求必須帶上一段隨機(jī)碼，這段隨機(jī)碼由正常用戶(hù)保存，黑帽子不知道隨機(jī)碼，也就無(wú)法冒充用戶(hù)進(jìn)行請(qǐng)求了。 點(diǎn)擊劫持是一種視覺(jué)欺騙的攻擊手段。攻擊者將需要攻擊的網(wǎng)站通過(guò) iframe 嵌套的方式嵌入自己的網(wǎng)頁(yè)中，并將 iframe 設(shè)置為透明，在頁(yè)面中透出一個(gè)按鈕誘導(dǎo)用戶(hù)點(diǎn)擊。
就像一張圖片上面鋪了一層透明的紙一樣，你看到的是攻擊者的頁(yè)面，但是其實(shí)這個(gè)頁(yè)面只是在底部，而你真正點(diǎn)擊的是被攻擊者透明化的另一個(gè)網(wǎng)頁(yè)。
如果所示，當(dāng)你點(diǎn)擊了頁(yè)面上的按鈕之后，本以為會(huì)...... ，而真正執(zhí)行的操作是關(guān)注了某人的博客。
點(diǎn)擊劫持防御 由于點(diǎn)擊劫持主要通過(guò) iframe，所以在防御時(shí)，主要基于 iframe 去做。
方案一：frame busting
if (self !== top) {正常網(wǎng)站使用 JS 腳本判斷是否被惡意網(wǎng)站嵌入，如：博客網(wǎng)站監(jiān)測(cè)到被一個(gè) iframe 打開(kāi)，自動(dòng)跳轉(zhuǎn)到正常的頁(yè)面即可。 方案二：使用 HTTP 中的 x-frame-options 頭，控制 iframe 的加載，它有 3 個(gè)值可選：
DENY，表示頁(yè)面不允許通過(guò) iframe 的方式展示。 SAMEORIGIN，表示頁(yè)面可以在相同域名下通過(guò) iframe 的方式展示。 ALLOW-FROM，表示頁(yè)面可以在指定來(lái)源的 iframe 中展示。 sandbox = 'allow-same-origin' 則只能加載與主站同域的資源。 服務(wù)器端的攻擊的方式也非常多，這里列舉幾個(gè)常見(jiàn)的。
SQL 注入和 XSS 一樣，都是違背了數(shù)據(jù)和代碼分離原則導(dǎo)致的攻擊方式。
如圖所示，我們利用 SQL 注入，就能在不需要密碼的情況下，直接登錄管理員的賬號(hào)。
攻擊的前提是：后端只用了簡(jiǎn)單的拼接 SQL 的方式去查詢(xún)數(shù)據(jù)。
# 拼接出來(lái)的 sql 如下： where username = 'admin' or 1=1 and password = 'xxx' # 無(wú)論密碼輸入什么，這條 sql 語(yǔ)句都能查詢(xún)到管理員的信息
除此之外，SQL 注入還有以下幾種方式：
使用 SQL 探測(cè)，猜數(shù)據(jù)庫(kù)表名，列名。
通過(guò) MySQL 內(nèi)置的 benchmark 探測(cè)數(shù)據(jù)庫(kù)字段。 如：一段偽代碼 select database as current if current[0]==='a',benchmark（10000,'猜對(duì)了'） 如果表明猜對(duì)了，就延遲 10 s 并返回成功。 使用存儲(chǔ)過(guò)程執(zhí)行系統(tǒng)命令
通過(guò)內(nèi)置的方法或存儲(chǔ)過(guò)程執(zhí)行 shell 腳本。 如：xp_cmdshell、sys_eval、sys_exec 等。 如：MySQL 在處理超長(zhǎng)的字符串時(shí)，會(huì)顯示警告，但會(huì)執(zhí)行成功。 注冊(cè)一個(gè) admin + 50 個(gè)空格的用戶(hù)，會(huì)觸發(fā)截?cái)?，最終新增一個(gè) admin 用戶(hù)，這樣就能擁有管理員權(quán)限了。 SQL 注入防御 防止 SQL 注入的最好的辦法就是，不要手動(dòng)拼接 SQL 語(yǔ)句。
這樣的語(yǔ)義不會(huì)發(fā)生改變，變量始終被當(dāng)成變量。 嚴(yán)格限制數(shù)據(jù)類(lèi)型，如果注入了其他類(lèi)型的數(shù)據(jù)，直接報(bào)錯(cuò)，不允許執(zhí)行。
使用安全的存儲(chǔ)過(guò)程和系統(tǒng)函數(shù)。
CRLF 注入 在注入攻擊中，換行符注入也是非常常見(jiàn)的一種攻擊方式。
如果在 HTTP 請(qǐng)求頭中注入 2 個(gè)換行符，會(huì)導(dǎo)致?lián)Q行符后面的所有內(nèi)容都被解析成請(qǐng)求實(shí)體部分。 攻擊者通常在 Set-Cookie 時(shí)，注入換行符，控制請(qǐng)求傳遞的內(nèi)容。 上傳文件是網(wǎng)頁(yè)開(kāi)發(fā)中的一個(gè)常見(jiàn)功能，如果不加處理，很容易就會(huì)造成攻擊。
如圖所示，攻擊者上傳了一個(gè)木馬文件，并且通過(guò)返回的 URL 進(jìn)行訪(fǎng)問(wèn)，就能控制服務(wù)器。
通常我們會(huì)控制上傳文件的后綴名，但也不能完全解決問(wèn)題，攻擊者還可以通過(guò)以下方式進(jìn)行攻擊：
如果要避免這個(gè)問(wèn)題，我們可以繼續(xù)判斷上傳文件的文件頭前 10 個(gè)字節(jié)。 Apache 解析方式是從后往前解析，直到找到一個(gè)認(rèn)識(shí)的后綴名為止
如：上傳一個(gè) abc.php.rar.rar.rar 能繞過(guò)后綴名檢查，但在執(zhí)行時(shí)，被當(dāng)成一個(gè) php 文件進(jìn)行執(zhí)行。 IIS 會(huì)截?cái)喾痔?hào)進(jìn)行解析
如：abc.asp;xx.png 能繞過(guò)后綴名檢查，但在執(zhí)行時(shí)，被當(dāng)成一個(gè) asp 文件進(jìn)行執(zhí)行。 通過(guò) HTTP MOVE 方法，還能修改上傳的文件名。 通過(guò)二者配合，就能先上傳一個(gè)正常的后綴名，然后改為一個(gè)惡意的后綴名。 執(zhí)行 http:///test.png/xxx.php 時(shí)，會(huì)把 test.png 當(dāng)做 php 文件去解析。 如果用戶(hù)正好是把一段惡意的 php 腳本當(dāng)做一張圖片進(jìn)行上傳，就會(huì)觸發(fā)這個(gè)攻擊。 文件上傳漏洞防御 防御文件上傳漏洞，可以從以下幾點(diǎn)考慮：
將文件上傳的目錄設(shè)置為不可執(zhí)行。
使用隨機(jī)數(shù)改寫(xiě)文件名和文件路徑
上傳文件后，隨機(jī)修改文件名，讓攻擊者無(wú)法執(zhí)行攻擊。 單獨(dú)設(shè)置文件服務(wù)器的域名
單獨(dú)做一個(gè)文件服務(wù)器，并使用單獨(dú)的域名，利用同源策略，規(guī)避客戶(hù)端攻擊。 通常做法是將靜態(tài)資源存放在 CDN 上。 登錄認(rèn)證攻擊可以理解為一種破解登錄的方法。攻擊者通常采用以下幾種方式進(jìn)行破解：
攻擊者通過(guò)搜集大量明文和 MD5 的對(duì)應(yīng)關(guān)系，用于破解 MD5 密文找出原文。 對(duì)于彩虹表中的 MD5 密碼，我們可以加鹽，進(jìn)行二次加密，避免被破解。 利用應(yīng)用系統(tǒng)在服務(wù)器的 SessionID 固定不變機(jī)制，借助他人用相同的 SessionID 獲取認(rèn)證和授權(quán)。 攻擊者登錄失敗后，后端返回了 SessionID，攻擊者將 SessionID 交給正常用戶(hù)去登錄，登錄成功后，攻擊者就能使用這個(gè) SessionID 冒充正常用戶(hù)登錄了。 如果瀏覽器每一次登錄都刷新 SessionID 可以避免這個(gè)問(wèn)題。 有些時(shí)候，后端出于用戶(hù)體驗(yàn)考慮，只要這個(gè)用戶(hù)還活著，就不會(huì)讓這個(gè)用戶(hù)的 Session 失效。 攻擊者可以通過(guò)不停發(fā)起請(qǐng)求，可以讓這個(gè) Session 一直活下去。 登錄認(rèn)證防御方式 密碼作為第一道防御，但在密碼驗(yàn)證成功后，我們還可以繼續(xù)驗(yàn)證：動(dòng)態(tài)口令，數(shù)字證書(shū)，短信驗(yàn)證碼等，以保證用戶(hù)安全。 由于短信和網(wǎng)頁(yè)完全是 2 套獨(dú)立的系統(tǒng)，攻擊者很難獲取到短信驗(yàn)證碼，也就無(wú)法進(jìn)行攻擊。 除此之外，前端登錄認(rèn)證還有多種方式，如果你對(duì)此感興趣，可以參考我之前寫(xiě)的《前端登錄，這一篇就夠了》。
應(yīng)用層拒絕服務(wù)攻擊，又叫 DDOS 攻擊，它指的是利用大量的請(qǐng)求造成資源過(guò)載，導(dǎo)致服務(wù)器不可用。
通常有以下幾種 DDOS 攻擊方式：
利用 HTTP 3 次握手機(jī)制，消耗服務(wù)器連接資源。 如：攻擊者發(fā)起大量的 HTTP 請(qǐng)求，但并不完成 3 次握手，而是只握手 2 次，這時(shí)服務(wù)器端會(huì)繼續(xù)等待直至超時(shí)。這時(shí)的服務(wù)器會(huì)一直忙于處理大量的垃圾請(qǐng)求，而無(wú)暇顧及正常請(qǐng)求。 以非常低的速度發(fā)送 HTTP 請(qǐng)求頭，消耗服務(wù)器連接資源。 如：攻擊者發(fā)送大量 HTTP 請(qǐng)求，但每個(gè)請(qǐng)求頭都發(fā)的很慢，每隔 10s 發(fā)送一個(gè)字符，服務(wù)器為了等待數(shù)據(jù)，不得始終保持連接，這樣一來(lái)，服務(wù)器連接數(shù)很快就被占光了。 發(fā)送 HTTP 時(shí)，指定一個(gè)非常大的 Content-Length 然后以很長(zhǎng)的間隔發(fā)送，消耗服務(wù)器連接資源。 針對(duì)一些非常消耗資源的頁(yè)面，不斷發(fā)起請(qǐng)求。 如：頁(yè)面中的某些頁(yè)面，需要后端做大量的運(yùn)算，或者需要做非常耗時(shí)的數(shù)據(jù)庫(kù)查詢(xún)。在大量的請(qǐng)求下，服務(wù)器的 CPU、內(nèi)存等資源可能就被占光了。 通過(guò) XSS 注入一段超長(zhǎng)的 Cookie，導(dǎo)致超出 Web 服務(wù)器所能承受的 Request Header 長(zhǎng)度，服務(wù)器端就會(huì)拒絕此服務(wù)。 針對(duì)一些缺陷的正則表達(dá)式，發(fā)起大量請(qǐng)求，耗光系統(tǒng)資源。 應(yīng)用層拒絕服務(wù)攻擊防御 對(duì)于應(yīng)用層拒絕服務(wù)攻擊，目前也沒(méi)有特別完美的解決方案，不過(guò)我們還是可以進(jìn)行一些優(yōu)化。
合理使用 Redis、Memcache 等緩存方案，減少 CPU 資源使用率。 網(wǎng)絡(luò)架構(gòu)上做好優(yōu)化
靜態(tài)資源使用 CDN 進(jìn)行管理。 服務(wù)器計(jì)算所有 IP 地址的請(qǐng)求頻率，篩選出異常的 IP 進(jìn)行禁用。 可以使用 LRU 算法，緩存前 1000 條請(qǐng)求的 IP，如果有 IP 請(qǐng)求頻率過(guò)高，就進(jìn)行禁用。 其實(shí)，處理 DDOS 核心思路就是禁用不可信任的用戶(hù)，確保資源都是被正常的用戶(hù)所使用。
我們?cè)诓渴?web 應(yīng)用的時(shí)候，經(jīng)常會(huì)用到 Nginx、Apache、IIS、Tomcat、Jboss 等 Web 服務(wù)器，這些服務(wù)器本身也存在一些安全隱患，如果配置不當(dāng)，很容易收到攻擊。
在配置 Web 服務(wù)器時(shí)，可以參考以下幾點(diǎn)：
以用戶(hù)權(quán)限運(yùn)行 Web 服務(wù)器
遵守最小權(quán)限原則，以最小權(quán)限身份運(yùn)行 Web 服務(wù)器，限制被入侵后的權(quán)限。 運(yùn)行 Tomcat、Jboss 等 Web 服務(wù)器時(shí)，默認(rèn)會(huì)開(kāi)啟一個(gè)可視化的運(yùn)營(yíng)后臺(tái)，運(yùn)行在 8080 端口，并且第一次訪(fǎng)問(wèn)是沒(méi)有認(rèn)證的。 攻擊者可以利用可視化后臺(tái)，遠(yuǎn)程加載一段 war 包或者上傳木馬文件，進(jìn)行控制。 主流的 Web 服務(wù)器，每隔一段時(shí)間就會(huì)修復(fù)一些漏洞，所以記得及時(shí)更新版本。 總結(jié)與思考 本文介紹了 Web 安全的基本概念，以及大量的攻防技巧，其實(shí)這只是 Web 安全中的冰山一角，如果你對(duì)此感興趣，不妨在安全領(lǐng)域繼續(xù)深耕學(xué)習(xí)，一定能看到更廣闊一片天。
對(duì)于一個(gè)開(kāi)發(fā)者來(lái)說(shuō)，我們應(yīng)該在寫(xiě)代碼時(shí)就將安全考慮其中，形成自己的一套安全開(kāi)發(fā)體系，做到心中有安全，時(shí)時(shí)考慮安全，就能無(wú)形之中化解不法分子的攻擊。
