摘要：應用常見安全漏洞一覽注入注入就是通過給應用接口傳入一些特殊字符，達到欺騙服務器執行惡意的命令。此外，適當的權限控制不曝露必要的安全信息和日志也有助于預防注入漏洞。

SQL 注入就是通過給 web 應用接口傳入一些特殊字符，達到欺騙服務器執行惡意的 SQL 命令。

SQL 注入漏洞屬于后端的范疇，但前端也可做體驗上的優化。

當使用外部不可信任的數據作為參數進行數據庫的增、刪、改、查時，如果未對外部數據進行過濾，就會產生 SQL 注入漏洞。

比如：

name = "外部輸入名稱";

sql = "select * from users where name=" + name;

上面的 SQL 語句目的是通過用戶輸入的用戶名查找用戶信息，因為由于 SQL 語句是直接拼接的，也沒有進行過濾，所以，當用戶輸入 "" or "1"="1" 時，這個語句的功能就是搜索 users 全表的記錄。

select * from users where name="" or "1"="1";

具體的解決方案很多，但大部分都是基于一點：不信任任何外部輸入。

所以，對任何外部輸入都進行過濾，然后再進行數據庫的增、刪、改、查。

此外，適當的權限控制、不曝露必要的安全信息和日志也有助于預防 SQL 注入漏洞。

參考 Web 安全漏洞之 SQL 注入 - 防御方法 了解具體的解決方案。

Web 安全漏洞之 SQL 注入

SQL 注入詳解

XSS 攻擊全稱跨站腳本攻擊（Cross-Site Scripting），簡單的說就是攻擊者通過在目標網站上注入惡意腳本并運行，獲取用戶的敏感信息如 Cookie、SessionID 等，影響網站與用戶數據安全。

XSS 攻擊更偏向前端的范疇，但后端在保存數據的時候也需要對數據進行安全過濾。

當攻擊者通過某種方式向瀏覽器頁面注入了惡意代碼，并且瀏覽器執行了這些代碼。

比如：

在一個文章應用中（如微信文章），攻擊者在文章編輯后臺通過注入 script 標簽及 js 代碼，后端未加過濾就保存到數據庫，前端渲染文章詳情的時候也未加過濾，這就會讓這段 js 代碼執行，引起 XSS 攻擊。

一個基本的思路是渲染前端頁面（不管是客戶端渲染還是服務器端渲染）或者動態插入 HTML 片段時，任何數據都不可信任，都要先做 HTML 過濾，然后再渲染。

參考 前端安全系列（一）：如何防止XSS攻擊？ - 攻擊的預防 了解具體的解決方案。

前端安全系列（一）：如何防止XSS攻擊？

前端防御 XSS

淺說 XSS 和 CSRF

CSRF 攻擊全稱跨站請求偽造（Cross-site Request Forgery），簡單的說就是攻擊者盜用了你的身份，以你的名義發送惡意請求。

一個典型的 CSRF 攻擊有著如下的流程：

受害者登錄 a.com，并保留了登錄憑證（Cookie）

攻擊者引誘受害者訪問了 b.com

b.com 向 a.com 發送了一個請求：a.com/act=xx（瀏覽器會默認攜帶 a.com 的 Cookie）

a.com 接收到請求后，對請求進行驗證，并確認是受害者的憑證，誤以為是受害者自己發送的請求

a.com 以受害者的名義執行了 act=xx

攻擊完成，攻擊者在受害者不知情的情況下，冒充受害者，讓 a.com 執行了自己定義的操作

注：上面的過程摘自 前端安全系列之二：如何防止CSRF攻擊？

防止 CSRF 攻擊需要在服務器端入手，基本的思路是能正確識別是否是用戶發起的請求。

參考 前端安全系列之二：如何防止CSRF攻擊？ - 防護策略 了解具體的解決方案。

前端安全系列之二：如何防止CSRF攻擊？

Web安全漏洞之CSRF

淺說 XSS 和 CSRF

DoS 攻擊全稱拒絕服務（Denial of Service），簡單的說就是讓一個公開網站無法訪問，而 DDoS 攻擊（分布式拒絕服務 Distributed Denial of Service）是 DoS 的升級版。

這個就完全屬于后端的范疇了。

攻擊者不斷地提出服務請求，讓合法用戶的請求無法及時處理，這就是 DoS 攻擊。

攻擊者使用多臺計算機或者計算機集群進行 DoS 攻擊，就是 DDoS 攻擊。

防止 DDoS 攻擊的基本思路是限流，限制單個用戶的流量（包括 IP 等）。

參考 DDoS的攻擊及防御 - 防御 了解具體的解決方案。

DDoS的攻擊及防御

淺談 DDoS 攻擊與防御

使用 Nginx、Nginx Plus 抵御 DDOS 攻擊

XXE 漏洞全稱 XML 外部實體漏洞（XML External Entity），當應用程序解析 XML 輸入時，如果沒有禁止外部實體的加載，導致可加載惡意外部文件和代碼，就會造成任意文件讀取、命令執行、內網端口掃描、攻擊內網網站等攻擊。

這個只在能夠接收 XML 格式參數的接口才會出現。

禁用外部實體

過濾用戶提交的XML數據

參考 xxe漏洞的學習與利用總結 了解具體的解決方案。

好剛: 6分鐘視頻看懂XXE漏洞攻擊

xxe漏洞的學習與利用總結

XXE漏洞攻防學習（上）

JSON 劫持（JSON Hijacking）是用于獲取敏感數據的一種攻擊方式，屬于 CSRF 攻擊的范疇。

一些 Web 應用會把一些敏感數據以 json 的形式返回到前端，如果僅僅通過 Cookie 來判斷請求是否合法，那么就可以利用類似 CSRF 的手段，向目標服務器發送請求，以獲得敏感數據。

比如下面的鏈接在已登錄的情況下會返回 json 格式的用戶信息：

http://www.test.com/userinfo

攻擊者可以在自己的虛假頁面中，加入如下標簽：

如果當前瀏覽器已經登錄了 www.test.com，并且 Cookie 未過期，然后訪問了攻擊者的虛假頁面，那么該頁面就可以拿到 json 形式的用戶敏感信息，因為 script 標簽會自動解析 json 數據，生成對應的 js 對象。然后再通過：

Object.prototype.__defineSetter__

這個函數來觸發自己的惡意代碼。

但是這個函數在當前的新版本 Chrome 和 Firefox 中都已經失效了。

注：上面的過程摘自 JSON和JSONP劫持以及解決方法

X-Requested-With 標識

瀏覽器 JSON 數據識別

禁止 Javascript 執行 JSON 數據

JSON和JSONP劫持以及解決方法

JSONP 安全攻防技術（JSON劫持、 XSS漏洞）

這個一般針對密碼而言，弱密碼（Weak Password）很容易被別人（對你很了解的人等）猜到或被破解工具暴力破解。

密碼復雜度要足夠大，也要足夠隱蔽

限制嘗試次數

HTTP/1.1（RFC2616）規范定義了 HTTP TRACE 方法，主要是用于客戶端通過向 Web 服務器提交 TRACE 請求來進行測試或獲得診斷信息。

當 Web 服務器啟用 TRACE 時，提交的請求頭會在服務器響應的內容（Body）中完整的返回，其中 HTTP 頭很可能包括 Session Token、Cookies 或其它認證信息。攻擊者可以利用此漏洞來欺騙合法用戶并得到他們的私人信息。

禁用 HTTP TRACE 方法。

由于 Web 服務器或應用程序沒有正確處理一些特殊請求，泄露 Web 服務器的一些敏感信息，如用戶名、密碼、源代碼、服務器信息、配置信息等。

所以一般需注意：

應用程序報錯時，不對外產生調試信息

過濾用戶提交的數據與特殊字符

保證源代碼、服務器配置的安全

攻擊者向 Web 服務器發送請求，通過在 URL 中或在有特殊意義的目錄中附加 ../、或者附加 ../ 的一些變形（如 .. 或 ..// 甚至其編碼），導致攻擊者能夠訪問未授權的目錄，以及在 Web 服務器的根目錄以外執行命令。

命令執行漏洞是通過 URL 發起請求，在 Web 服務器端執行未授權的命令，獲取系統信息、篡改系統配置、控制整個系統、使系統癱瘓等。

如果對文件上傳路徑變量過濾不嚴，并且對用戶上傳的文件后綴以及文件類型限制不嚴，攻擊者可通過 Web 訪問的目錄上傳任意文件，包括網站后門文件（webshell），進而遠程控制網站服務器。

所以一般需注意：

在開發網站及應用程序過程中，需嚴格限制和校驗上傳的文件，禁止上傳惡意代碼的文件

限制相關目錄的執行權限，防范 webshell 攻擊

SSLStrip 攻擊

OpenSSL Heartbleed 安全漏洞

CCS 注入漏洞

證書有效性驗證漏洞

一般業務漏洞是跟具體的應用程序相關，比如參數篡改（連續編號 ID / 訂單、1 元支付）、重放攻擊（偽裝支付）、權限控制（越權操作）等。

另外可以參考：6種常見web漏洞坑

WordPress 4.7 / 4.7.1：REST API 內容注入漏洞

Drupal Module RESTWS 7.x：Remote PHP Code Execution

SugarCRM 6.5.23：REST PHP Object Injection Exploit

Apache Struts：REST Plugin With Dynamic Method Invocation Remote Code Execution

Oracle GlassFish Server：REST CSRF

QQ Browser 9.6：API 權限控制問題導致泄露隱私模式

Hacking Docker：Registry API 未授權訪問

更多博客，查看 https://github.com/senntyou/blogs

作者：深予之 (@senntyou)

版權聲明：自由轉載-非商用-非衍生-保持署名（創意共享3.0許可證）