如何保證web安全

一、前言

互聯(lián)網(wǎng)發(fā)展初期，那還是IE瀏覽器的時(shí)代，那時(shí)大家上網(wǎng)的目的就是通過(guò)瀏覽器分享信息、獲取新聞。隨著(zhù)互聯(lián)網(wǎng)的快速發(fā)展，網(wǎng)頁(yè)能做的事情越來(lái)越多，不僅可以看新聞、玩游戲，還能購物、聊天，這些功能極大地豐富了我們的生活。

隨著(zhù)網(wǎng)頁(yè)功能的逐漸增多，就開(kāi)始出現了一些黑帽子，他們試圖通過(guò)一些技術(shù)手段來(lái)牟取利益。比如木馬病毒，它可以監控你的鍵盤(pán)，將你在鍵盤(pán)上敲打的內容發(fā)送到黑客的機器上，黑客通過(guò)分析這些內容，很容易就能得到你的游戲賬號和密碼。在這之后，就誕生出了一些殺毒軟件，致力于解決網(wǎng)絡(luò )上的各種病毒，隨著(zhù)不斷地發(fā)展，殺毒軟件已經(jīng)成為一臺電腦必不可少的軟件。

為什么會(huì )出現這樣的安全問(wèn)題？

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

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

1、如何做好安全

要做好安全，首先得理解安全問(wèn)題的屬性，前人通過(guò)無(wú)數實(shí)踐，最后將安全的屬性總結為安全三要素，分別為：

1）機密性

保護數據內容不被泄露。通常使用加密的方法。

2）完整性

保護數據內容是完整的、沒(méi)有被篡改。通常使用數字簽名的方法。

3）可用性。

數據隨時(shí)都能夠使用。通常是在防御 DOS。

2、安全評估

有了安全 3 要素之后，我們就可以對安全問(wèn)題進(jìn)行評估了。

1）資產(chǎn)等級劃分

找出最重要的數據。找出最重要數據的宿主空間，如：在數據庫里，那么數據庫就得重點(diǎn)防御。找出數據庫的宿主空間，如：在一臺服務(wù)器上，那么這臺服務(wù)器就得做次等防御。找出服務(wù)器的宿主空間，如：在 OSI 網(wǎng)絡(luò )層級上，那么在網(wǎng)絡(luò )層面就得做一般防御。

2）威脅分析

找出威脅（可能造成危害的來(lái)源）。找出風(fēng)險（可能出現的損失叫做風(fēng)險）。

3）風(fēng)險分析

采取多標準決策分析，即：風(fēng)險 = 威脅等級 * 威脅可行性。計算所有的威脅，將最終的風(fēng)險進(jìn)行排序，優(yōu)先解決風(fēng)險大的問(wèn)題。

4）確認解決方案

找出不安全的實(shí)現方式，并確定解決方案。解決方案不要改變商業(yè)需求的初衷。解決方案需對用戶(hù)透明，不要改變用戶(hù)的習慣。

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

3、安全的原則

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

1）黑名單、白名單原則

白名單方案指的是給安全的資源授權。黑名單方案指的是禁用不安全的資源。我們應該優(yōu)先使用白名單方案，因為黑名單通常統計不完所有的不安全資源。如：XSS 攻擊的方式非常多，可以通過(guò) script、css、image 標簽等，盡管你將這些標簽都加入黑名單，也不能保證其他的標簽都沒(méi)有 XSS 的攻擊隱患。

2）最小權限原則

只授予必要的權限，不要過(guò)度授權，減少出錯機會(huì )。如：普通權限的 Linux 用戶(hù)只能操作 ~ 文件夾下的目錄，如果有人想刪庫跑路，在執行 rm -rf / 時(shí)，就會(huì )提示無(wú)權限。

3）縱深防御原則

這條原則類(lèi)似 木桶理論，安全水平往往取決于最短的那塊板。即：不要留下短板，黑帽子們往往可以利用短板為突破口，挖掘更大的漏洞。

4）數據與代碼分離原則

當用戶(hù)數據被當成代碼執行時(shí)，混淆了數據和代碼的邊界，從而導致安全問(wèn)題。如：XSS 就是利用這一點(diǎn)去攻擊的。

5）不可預測性原則

這條原則是為了提高攻擊門(mén)檻，有效防止基于篡改、偽造的攻擊。如：數據庫中使用 uuid 代替 number 型的自增主鍵，可以避免 id 被攻擊者猜到，從而進(jìn)行批量操作。token 也是利用不可預測性，攻擊者無(wú)法構造 token 也就無(wú)法進(jìn)行攻擊。

有了這些安全原則，接下來(lái)介紹幾個(gè)常見(jiàn)的攻防案例。

二、安全攻防案例

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

（一）客戶(hù)端攻擊

主要有：XSS 攻擊、CSRF 攻擊、點(diǎn)擊劫持。

1、XSS攻擊

XSS 攻擊的本質(zhì)是將用戶(hù)數據當成了 HTML 代碼一部分來(lái)執行，從而混淆原本的語(yǔ)義，產(chǎn)生新的語(yǔ)義。

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

XSS 攻擊方式有很多，所有和用戶(hù)交互的地方，都有可能存在 XSS 攻擊。例如：

• 所有 input 框。

• window.location。

• window.name。

• document.referrer。

• document.cookie。

• localstorage。

• ...

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

1）XSS 攻擊影響

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

識別用戶(hù) UA。識別用戶(hù)瀏覽器擴展。識別用戶(hù)瀏覽過(guò)的網(wǎng)站。（通過(guò) CSS 的 Visited 屬性。）獲取用戶(hù)真實(shí)的 IP。（通過(guò) WebRTC 等。）盜取 Cookie（偽造用戶(hù)登錄，竊取用戶(hù)資料。）XSS 釣魚(yú)。（向頁(yè)面注入一個(gè)登錄彈窗，讓用戶(hù)認為是網(wǎng)站內的登錄彈窗（其實(shí)是釣魚(yú)網(wǎng)站的），一旦用戶(hù)登錄，賬號密碼就泄露給了釣魚(yú)網(wǎng)站。）

2）XSS 攻擊防御

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

我們也可以自定義進(jìn)行一些安全配置。

配置 HTTP 中的 http-only 頭，讓前端 JS 不能操作 Cookie。輸入檢查，在用戶(hù)提交數據時(shí)，使用 XssFilter 過(guò)濾掉不安全的數據。輸出檢查，在頁(yè)面渲染的時(shí)候，過(guò)濾掉危險的數據。

簡(jiǎn)單就是說(shuō)需要：禁止js操作cookie、提交時(shí)檢查html、輸出時(shí)檢查html（可以通過(guò)轉碼）

2、CSRF 攻擊

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

比如：

用戶(hù)先登錄了服務(wù)器 B，然后去訪(fǎng)問(wèn)服務(wù)器 C。服務(wù)器 C 通過(guò)惡意腳本，冒充 A 去調用服務(wù)器 B 上的某個(gè)功能，對于服務(wù)器 B 來(lái)說(shuō)，還以為這是 A 發(fā)起的請求，就當作正常請求處理了。

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

1）CSRF 防御方式

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

a、驗證碼Referer 檢查

每一次請求都要求用戶(hù)驗證，以確保請求真實(shí)可靠。即：利用惡意腳本不能識別復雜的驗證碼的特點(diǎn)，保證每次請求都是合法的。

b、Referer 檢查

檢查發(fā)起請求的服務(wù)器，是否為目標服務(wù)器。即：HTTP 請求中的 Referer 頭傳遞了當前請求的域名，如果此域名是非法服務(wù)器的域名，則需要禁止訪(fǎng)問(wèn)。

c、Token

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

（學(xué)習視頻分享：）

3、點(diǎn)擊劫持

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

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

1）點(diǎn)擊劫持防御

由于點(diǎn)擊劫持主要通過(guò) iframe，所以在防御時(shí)，主要基于 iframe 去做。

方案一：frame busting

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

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

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

DENY，表示頁(yè)面不允許通過(guò) iframe 的方式展示。SAMEORIGIN，表示頁(yè)面可以在相同域名下通過(guò) iframe 的方式展示。ALLOW-FROM，表示頁(yè)面可以在指定來(lái)源的 iframe 中展示。

配置 iframe 的 sandbox 屬性：sandbox = "allow-same-origin" ，則只能加載與主站同域的資源。

（二）服務(wù)端攻擊

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

SQL 注入攻擊文件上傳漏洞登錄認證攻擊應用層拒絕服務(wù)攻擊webServer 配置安全

1、SQL 注入攻擊

SQL 注入和 XSS 一樣，都是違背了數據和代碼分離原則導致的攻擊方式。

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

攻擊的前提是：后端只用了簡(jiǎn)單的拼接 SQL 的方式去查詢(xún)數據。

// 拼接出來(lái)的 sql 如下：select * from user where username = 'admin' or 1=1 and password = 'xxx'
// 無(wú)論密碼輸入什么，這條 sql 語(yǔ)句都能查詢(xún)到管理員的信息

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

a、使用 SQL 探測，猜數據庫表名，列名。

通過(guò) MySQL 內置的 benchmark 探測數據庫字段。如：一段偽代碼 select database as current if current[0]==='a',benchmark（10000,'猜對了'） 如果表明猜對了，就延遲 10 s 并返回成功。

b、使用存儲過(guò)程執行系統命令

通過(guò)內置的方法或存儲過(guò)程執行 shell 腳本。如：xp_cmdshell、sys_eval、sys_exec 等。

c、字符串截斷

如：MySQL 在處理超長(cháng)的字符串時(shí)，會(huì )顯示警告，但會(huì )執行成功。注冊一個(gè) admin + 50 個(gè)空格的用戶(hù)，會(huì )觸發(fā)截斷，最終新增一個(gè) admin 用戶(hù)，這樣就能擁有管理員權限了。

1）SQL 注入防御

防止 SQL 注入的最好的辦法就是，不要手動(dòng)拼接 SQL 語(yǔ)句。

最佳方案，使用預編譯語(yǔ)句綁定變量：通常是指框架提供的拼接 SQL 變量的方法。這樣的語(yǔ)義不會(huì )發(fā)生改變，變量始終被當成變量。嚴格限制數據類(lèi)型，如果注入了其他類(lèi)型的數據，直接報錯，不允許執行。使用安全的存儲過(guò)程和系統函數。

2、CRLF 注入

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

如果在 HTTP 請求頭中注入 2 個(gè)換行符，會(huì )導致?lián)Q行符后面的所有內容都被解析成請求實(shí)體部分。攻擊者通常在 Set-Cookie 時(shí)，注入換行符，控制請求傳遞的內容。

3、文件上傳漏洞

上傳文件是網(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)行攻擊：

• 偽造正常文件

• 將木馬文件偽裝成正常的后綴名進(jìn)行上傳。

• 如果要避免這個(gè)問(wèn)題，我們可以繼續判斷上傳文件的文件頭前 10 個(gè)字節。

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

• 如：上傳一個(gè) abc.php.rar.rar.rar 能繞過(guò)后綴名檢查，但在執行時(shí)，被當成一個(gè) php 文件進(jìn)行執行。

• IIS 會(huì )截斷分號進(jìn)行解析

• 如：abc.asp;xx.png 能繞過(guò)后綴名檢查，但在執行時(shí)，被當成一個(gè) asp 文件進(jìn)行執行。

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

• 通過(guò) HTTP MOVE 方法，還能修改上傳的文件名。

• 通過(guò)二者配合，就能先上傳一個(gè)正常的后綴名，然后改為一個(gè)惡意的后綴名。

• PHP CGI 路徑問(wèn)題

• 執行 http://abc.com/test.png/xxx.php 時(shí)，會(huì )把 test.png 當做 php 文件去解析。

• 如果用戶(hù)正好是把一段惡意的 php 腳本當做一張圖片進(jìn)行上傳，就會(huì )觸發(fā)這個(gè)攻擊。

1）文件上傳漏洞防御

防御文件上傳漏洞，可以從以下幾點(diǎn)考慮：

將文件上傳的目錄設置為不可執行。判斷文件類(lèi)型檢查 MIME Type，配置白名單。檢查后綴名，配置白名單。使用隨機數改寫(xiě)文件名和文件路徑上傳文件后，隨機修改文件名，讓攻擊者無(wú)法執行攻擊。單獨設置文件服務(wù)器的域名單獨做一個(gè)文件服務(wù)器，并使用單獨的域名，利用同源策略，規避客戶(hù)端攻擊。通常做法是將靜態(tài)資源存放在 cdn/' target='_blank'>CDN 上。

4、登錄認證攻擊

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

• 彩虹表

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

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

• Session Fixation攻擊

• 利用應用系統在服務(wù)器的 SessionID 固定不變機制，借助他人用相同的 SessionID 獲取認證和授權。

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

• 如果瀏覽器每一次登錄都刷新 SessionID 可以避免這個(gè)問(wèn)題。

• Session 保持攻擊

• 有些時(shí)候，后端出于用戶(hù)體驗考慮，只要這個(gè)用戶(hù)還活著(zhù)，就不會(huì )讓這個(gè)用戶(hù)的 Session 失效。

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

1）登錄認證防御方式

多因素認證密碼作為第一道防御，但在密碼驗證成功后，我們還可以繼續驗證：動(dòng)態(tài)口令，ssl/' target='_blank'>數字證書(shū)，短信驗證碼等，以保證用戶(hù)安全。由于短信和網(wǎng)頁(yè)完全是 2 套獨立的系統，攻擊者很難獲取到短信驗證碼，也就無(wú)法進(jìn)行攻擊。

5、應用層拒絕服務(wù)攻擊

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

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

• SYN Flood 洪水攻擊

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

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

• Slowloris 攻擊

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

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

• HTTP POST DOS

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

• CC 攻擊

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

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

• Server Limit DOS

• 通過(guò) XSS 注入一段超長(cháng)的 Cookie，導致超出 Web 服務(wù)器所能承受的 Request Header 長(cháng)度，服務(wù)器端就會(huì )拒絕此服務(wù)。

• ReDOS

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

1）應用層拒絕服務(wù)攻擊防御

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

應用代碼做好性能優(yōu)化合理使用 Redis、Memcache 等緩存方案，減少 CPU 資源使用率。網(wǎng)絡(luò )架構上做好優(yōu)化后端搭建負載均衡。靜態(tài)資源使用 CDN 進(jìn)行管理。限制請求頻率服務(wù)器計算所有 IP 地址的請求頻率，篩選出異常的 IP 進(jìn)行禁用?？梢允褂?LRU 算法，緩存前 1000 條請求的 IP，如果有 IP 請求頻率過(guò)高，就進(jìn)行禁用。

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

三、WebServer 配置安全

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

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

1、以用戶(hù)權限運行 Web 服務(wù)器

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

2、刪除可視化后臺

運行 Tomcat、Jboss 等 Web 服務(wù)器時(shí)，默認會(huì )開(kāi)啟一個(gè)可視化的運營(yíng)后臺，運行在 8080 端口，并且第一次訪(fǎng)問(wèn)是沒(méi)有認證的。

攻擊者可以利用可視化后臺，遠程加載一段 war 包或者上傳木馬文件，進(jìn)行控制，所以我們需要刪除可視化平臺。

3、及時(shí)更新版本

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

相關(guān)推薦：