如何保證web安全

一、前言

互聯網發展初期，那還是IE瀏覽器的時代，那時大家上網的目的就是通過瀏覽器分享信息、獲取新聞。隨著互聯網的快速發展，網頁能做的事情越來越多，不僅可以看新聞、玩游戲，還能購物、聊天，這些功能極大地豐富了我們的生活。

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

為什么會出現這樣的安全問題？

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

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

1、如何做好安全

要做好安全，首先得理解安全問題的屬性，前人通過無數實踐，最后將安全的屬性總結為安全三要素，分別為：

1）機密性

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

2）完整性

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

3）可用性。

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

2、安全評估

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

1）資產等級劃分

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

2）威脅分析

找出威脅（可能造成危害的來源）。找出風險（可能出現的損失叫做風險）。

3）風險分析

采取多標準決策分析，即：風險 = 威脅等級 * 威脅可行性。計算所有的威脅，將最終的風險進行排序，優先解決風險大的問題。

4）確認解決方案

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

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

3、安全的原則

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

1）黑名單、白名單原則

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

2）最小權限原則

只授予必要的權限，不要過度授權，減少出錯機會。如：普通權限的 linux 用戶只能操作?~?文件夾下的目錄，如果有人想刪庫跑路，在執行?rm -rf /?時，就會提示無權限。

3）縱深防御原則

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

4）數據與代碼分離原則

當用戶數據被當成代碼執行時，混淆了數據和代碼的邊界，從而導致安全問題。如：XSS 就是利用這一點去攻擊的。

5）不可預測性原則

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

有了這些安全原則，接下來介紹幾個常見的攻防案例。

二、安全攻防案例

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

（一）客戶端攻擊

主要有：XSS 攻擊、csrf 攻擊、點擊劫持。

1、XSS攻擊

XSS 攻擊的本質是將用戶數據當成了 html 代碼一部分來執行，從而混淆原本的語義，產生新的語義。

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

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

• 所有 input 框。

• window.location。

• window.name。

• document.referrer。

• document.cookie。

• localstorage。

• …

由于頁面中與用戶交互的地方非常多，肯定還有一些 XSS 的攻擊方式沒有被發現，而一旦被黑帽子發現，就可能造成嚴重的影響，所以我們務必引起重視。

1）XSS 攻擊影響

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

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

2）XSS 攻擊防御

目前來說，XSS 已經得到了互聯網行業的重視，許多開發框架都內置了安全的 HTML 渲染方法。

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

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

簡單就是說需要：禁止js操作cookie、提交時檢查html、輸出時檢查html（可以通過轉碼）

2、CSRF 攻擊

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

比如：

用戶先登錄了服務器 B，然后去訪問服務器 C。服務器 C 通過惡意腳本，冒充 A 去調用服務器 B 上的某個功能，對于服務器 B 來說，還以為這是 A 發起的請求，就當作正常請求處理了。

試想一下，如果 C 冒充 A 進行了一次轉賬，必定會造成大量的經濟損失。

1）CSRF 防御方式

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

a、驗證碼Referer 檢查

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

b、Referer 檢查

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

c、Token

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

（學習視頻分享：php視頻教程）

3、點擊劫持

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

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

1）點擊劫持防御

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

方案一：frame busting

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

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

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

DENY，表示頁面不允許通過 iframe 的方式展示。SAMEORIGIN，表示頁面可以在相同域名下通過 iframe 的方式展示。ALLOW-FROM，表示頁面可以在指定來源的 iframe 中展示。

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

（二）服務端攻擊

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

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

1、SQL 注入攻擊

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

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

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

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

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

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

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

b、使用存儲過程執行系統命令

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

c、字符串截斷

如：MySQL 在處理超長的字符串時，會顯示警告，但會執行成功。注冊一個 admin + 50 個空格的用戶，會觸發截斷，最終新增一個 admin 用戶，這樣就能擁有管理員權限了。

1）SQL 注入防御

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

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

2、CRLF 注入

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

如果在 HTTP 請求頭中注入 2 個換行符，會導致換行符后面的所有內容都被解析成請求實體部分。攻擊者通常在 Set-Cookie 時，注入換行符，控制請求傳遞的內容。

3、文件上傳漏洞

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

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

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

• 偽造正常文件

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

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

• apache 解析方式是從后往前解析，直到找到一個認識的后綴名為止

• 如：上傳一個?abc.php.rar.rar.rar?能繞過后綴名檢查，但在執行時，被當成一個 php 文件進行執行。

• iis 會截斷分號進行解析

• 如：abc.asp;xx.png?能繞過后綴名檢查，但在執行時，被當成一個 asp 文件進行執行。

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

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

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

• PHP CGI 路徑問題

• 執行?http://abc.com/test.png/xxx.php?時，會把 test.png 當做 php 文件去解析。

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

1）文件上傳漏洞防御

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

將文件上傳的目錄設置為不可執行。判斷文件類型檢查 MIME Type，配置白名單。檢查后綴名，配置白名單。使用隨機數改寫文件名和文件路徑上傳文件后，隨機修改文件名，讓攻擊者無法執行攻擊。單獨設置文件服務器的域名單獨做一個文件服務器，并使用單獨的域名，利用同源策略，規避客戶端攻擊。通常做法是將靜態資源存放在 CDN 上。

4、登錄認證攻擊

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

• 彩虹表

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

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

• Session Fixation攻擊

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

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

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

• Session 保持攻擊

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

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

1）登錄認證防御方式

多因素認證密碼作為第一道防御，但在密碼驗證成功后，我們還可以繼續驗證：動態口令，數字證書，短信驗證碼等，以保證用戶安全。由于短信和網頁完全是 2 套獨立的系統，攻擊者很難獲取到短信驗證碼，也就無法進行攻擊。

5、應用層拒絕服務攻擊

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

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

• SYN Flood 洪水攻擊

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

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

• Slowloris 攻擊

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

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

• HTTP POST DOS

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

• CC 攻擊

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

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

• Server Limit DOS

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

• ReDOS

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

1）應用層拒絕服務攻擊防御

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

應用代碼做好性能優化合理使用 redis、memcache 等緩存方案，減少 CPU 資源使用率。網絡架構上做好優化后端搭建負載均衡。靜態資源使用 CDN 進行管理。限制請求頻率服務器計算所有 IP 地址的請求頻率，篩選出異常的 IP 進行禁用。可以使用 LRU 算法，緩存前 1000 條請求的 IP，如果有 IP 請求頻率過高，就進行禁用。

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

三、WebServer 配置安全

我們在部署 web 應用的時候，經常會用到 nginx、Apache、IIS、tomcat、Jboss 等 Web 服務器，這些服務器本身也存在一些安全隱患，如果配置不當，很容易收到攻擊。

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

1、以用戶權限運行 Web 服務器

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

2、刪除可視化后臺

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

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

3、及時更新版本

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

相關推薦：php視頻教程