如何保證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 洪水攻擊

• 利用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伺服器安全性

以上是如何保證web安全的詳細內容。更多資訊請關注PHP中文網其他相關文章！