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