、簡介

在PHP中，htmlspecialchars()函數是一個常用的字符串處理函數，用于將字符串中的特殊字符（如<>等）轉換為HTML實體，以防止跨站點腳本攻擊（XSS）。

二、語法

htmlspecialchars(string $string, int $flags=ENT_COMPAT | ENT_HTML401, string|null $encoding=ini_get("default_charset"), bool $double_encode=true)

三、參數解釋

$string：必需，要處理的字符串，字符串類型。

$flags：可選，指定轉換過程中的一些規則和選項，整數類型，默認為ENT_COMPAT | ENT_HTML401。

$encoding：可選，指定要使用的字符編碼，字符串類型，如果未指定，則使用ini_get("default_charset")函數獲取默認字符編碼。

$double_encode：可選，指定是否對已存在的HTML實體進行轉義，布爾類型，默認為true。

四、返回值

htmlspecialchars()函數返回一個新的字符串，其中的特殊字符被轉換為了HTML實體。

五、使用實例

下面是一個簡單的使用實例：

在上面的例子中，我們使用htmlspecialchars()函數將字符串中的特殊字符（如<>等）轉換為了HTML實體，以防止跨站點腳本攻擊（XSS）。

六、注意事項

1、在使用htmlspecialchars()函數時，需要注意轉換規則。例如，它只會將特殊字符轉換為HTML實體，但不會對其他類型的攻擊進行防護，例如SQL注入攻擊、跨站點請求偽造（CSRF）攻擊等。

2、在使用htmlspecialchars()函數時，需要注意字符編碼。例如，如果在使用htmlspecialchars()函數時未指定字符編碼，可能會導致轉換結果不正確，從而引發安全性問題。

3、在處理用戶輸入的文本時，我們需要注意安全性問題。例如，可以使用addslashes()函數來防止SQL注入攻擊，在輸出到HTML頁面中時，需要使用htmlspecialchars()函數防止跨站點腳本攻擊（XSS）。

七、常用場景

htmlspecialchars()函數可以在很多場景中使用，例如：

1、在開發PHP應用程序時，需要將用戶輸入的文本輸出到HTML頁面中。使用htmlspecialchars()函數可以防止跨站點腳本攻擊（XSS）。

2、在開發PHP應用程序時，需要將用戶輸入的文本存儲到數據庫中。使用addslashes()函數可以防止SQL注入攻擊，在從數據庫中讀取數據時，需要使用htmlspecialchars()函數防止跨站點腳本攻擊（XSS）。

3、在開發PHP應用程序時，需要將用戶輸入的文本輸出到JavaScript中。使用htmlspecialchars()函數可以將其中的特殊字符轉換為HTML實體，以防止跨站點腳本攻擊（XSS）。

4、在開發PHP應用程序時，需要將用戶輸入的文本輸出到電子郵件中。使用htmlspecialchars()函數可以將其中的特殊字符轉換為HTML實體，以便正確地顯示出原本的文本。

<?php

<form method="post" action="<?php echo htmlspecialchars($_SERVER['PHP_SELF']);?>">

eb安全是指保護Web應用程序、Web服務器和Web瀏覽器免受各種網絡攻擊和惡意行為的方法和技術。隨著越來越多的業務和活動轉移到互聯網上，Web安全成為越來越重要的問題。

Web安全包括以下方面:

• 認證和授權:確保只有經過身份驗證和授權的用戶可以訪問敏感信息；
• 輸入驗證:檢查用戶輸入的數據是否合法，避免惡意用戶通過輸入惡意數據來攻擊應用程序；
• 防止跨站點腳本攻擊(XSS):防止攻擊者在Web頁面上注入惡意腳本，從而獲取用戶信息或執行其他惡意操作；
• 防止跨站點請求偽造(CSRF):防止攻擊者利用受害者的Web瀏覽器發起偽造請求；

以下以編碼安全、邏輯安全、數據安全展開說明。

本文介紹編碼安全，邏輯安全、數據安全在下一篇文章中介紹。

1. 什么是編碼安全？

安全編碼規范是一種定義編碼要求的標準化方法。它確保代碼是高質量、可重用和安全的。安全編碼規范應該適用于代碼開發、測試和維護的所有階段。

安全編碼規范應該涵蓋以下方面：身份驗證、授權、輸入驗證、輸出編碼、錯誤處理和安全配置管理等。

2. 編碼安全-輸入驗證

任何來自客戶端的數據，如 URL 和參數、HTTP 頭部、Javascript 或其他嵌入代碼提交的信息，都屬于不可信數據。在應用外部邊界或內部每個組件或功能邊界，都將其當做潛在的惡意輸入來校驗。

輸入驗證通常采用以下幾點：

a. 白名單

不可信數據可以設定白名單校驗的，應接受所有和白名單匹配的數據，并阻止其他數據。

b. 黑名單

不可信數據中包含不良輸入字符時，如空字節(%00)、換行符(%0d，%0a)、路徑字符(../或..)等，建議直接阻止該數據，若需要接受該數據，則應做不同方式的凈化處理。

c. 規范化/合法性校正

不可信數據需實施各種凈化處理時，應徹底刪除惡意字符，只留下已知安全的字符，或者在處理前對它們進行適當編碼或“轉義”，如數據輸出到應用頁面時對其進行HTML編碼可防止腳本攻擊、不可信數據的合法性校驗包括:數據類型如字符。數字、日期等特征;數據長度等。

d. 防范SQL注入

不可信數據進入后端數據庫揉作前，建議使用正確的參數化查詢來處理，禁止拼接 SQL 語句，避免出現 SQL 注入。

e. 訪問控制

不可信數據通過上述校驗后，還應確認所提交的內容是否與用戶的身份匹配，避免越權訪問。

3. 編碼安全-輸出驗證：

考慮目標編譯器的安全性，對所有輸出字符進行正確編碼。

輸入驗證通常采用以下幾點

a. 編碼輸出

不可信數據輸出到前后端頁面時，根據輸出場景對其進行相關編碼，如 HTML 實體編碼、UR 編碼。

b. 凈化輸出

針對操作系統命令、SQL 和 LDAP查詢，凈化所有輸出的敏感信息，如銀行卡、手機號、系統信息等

c. 規范輸出

可以采用JSON 格式作為統一的返回值格式這樣方便客戶端和服務器端進行數據交換（包括返回的狀態碼、消息、數據等信息）

4. Sql注入

SQL注入就是在Web表單提交數據/傳輸數據時，將預先準備好的SQL語句添加進去，達到欺騙服務器、修改SQL語句執行結果，非法獲取服務器端數據的目的。

4.1 Sql注入原理

攻擊者猜測Web系統的數據驗證過程，在輸入數據的最后加上一段SQL語句，讓服務器端的SQL執行出現偏差，從而欺騙服務器，甚至可獲取數據庫的管理權限，然后將數據庫管理用戶權限提升至操作系統管理用戶權限，控制服務器操作系統，獲取重要信息及機密文件

4.2 SQL注入流程

?判斷是否存在注入，注入是字符型還是數字型

?猜解SQL查詢語句中的字段數

?確定顯示位置

?獲取當前數據庫

?獲取數據庫中的表

?獲取表中的字段名

?下載數據

4.3 尋找SQL注入點

SQL注入可以出現在任何從系統或用戶接收數據輸入的前端應用程序中，這些應用程序之后被用于訪問數據庫服務器。如果要對一個網站進行SQL注入攻擊，首先就需要找到存在SQL注入漏洞的地方，也就是尋找所謂的注入點。可能的SQL注入點一般存在于登錄頁面、查找頁面或添加頁面等用戶可以查找或修改數據的地方。最常用的尋找SQL注入點的方法，是在網站中尋找如下形式的頁面鏈接：http://www.abc.com/xyz.xxx?id=yy，其中“yy”可能是數字，也有可能是字符串，分別被稱為整數類型數據或者字符型數據。

4.4 Sql注入判斷

a.整型參數的判斷

當輸入的參數YY為整型時，通常xyz.asp中SQL語句原貌大致如下：

select * from表名where字段=YY，所以可以用以下步驟測試SQL注入是否存在。

http://www.abc.com/xyz.xx?p=YY’(附加一個單引號)，此時xyz.asp中的SQL語句變成了select * from表名where字段=YY’，xyz.asp運行異常；

http://www.abc.com/xyz.xx?p=YYand 1=1，xyz.asp運行正常，而且與http://www.abc.com/xyz.xxp?p=YY運行結果相同；

http://www.abc.com/xyz.xx?p=YYand1=2，xyz.asp運行異常；

如果以上三步全面滿足，xyz.asp中一定存在SQL注入漏洞。

b.字符串型參數的判斷

當輸入的參數YY為字符串時，通常xyz.asp中SQL語句原貌大致如下：

select * from表名where字段='YY'，所以可以用以下步驟測試SQL注入是否存在。

http://www.abc.com/xyz.xx?p=YY’(附加一個單引號)，此時xyz.asp中的SQL語句變成了select * from表名where字段=YY’，xyz.asp運行異常；

http://www.abc.com/xyz.xx?p=YY&nb...39;1'='1'，xyz.asp運行正常，而且與http://www.abc.com/xyz.xx?p=YY運行結果相同；

http://www.abc.com/xyz.xx?p=YY&nb...39;1'='2'，xyz.asp運行異常；

如果以上三步全面滿足，xyz.asp中一定存在SQL注入漏洞

c.特殊情況的處理

有時程序員會在程序員過濾掉單引號等字符，以防止SQL注入。此時可以用以下幾種方法試一試。

大小寫混合法：某些語言并不區分大小寫(如asp)，此時可將SQL語句中的命令字進行大小寫混合來規避過濾技術，如用wHeRe代替where等。

ASCII碼法：將輸入內容的部分或全部字符使用ASCII碼來代替，這樣也有可能規避過濾技術，如A=chr(65)，a=chr(97)等

d.Sql注入示例

5. XSS攻擊

5.1 什么是XSS攻擊

XSS攻擊又稱為跨站腳本，XSS的重點不在于跨站點，而是在于腳本的執行。XSS是一種經常出現在Web應用程序中的計算機安全漏洞，是由于Web應用程序對用戶的輸入過濾不足而產生的，它允許惡意web用戶將代碼植入到提供給其它用戶使用的頁面中。

5.2 XSS漏洞的危害

a.竊取管理員帳號或Cookie。入侵者可以冒充管理員的身份登錄后臺，使得入侵者具有惡意操縱后臺數據的能力，包括讀取、更改、添加、刪除一些信息。

b.竊取用戶的個人信息或者登錄帳號。對網站的用戶安全產生巨大的威脅。例如冒充用戶身份進行各種操作。

c.網站掛馬。先將惡意攻擊代碼嵌入到Web應用程序之中。當用戶瀏覽該掛馬頁面時，用戶的計算機會被植入木馬。

d.發送廣告或者垃圾信息。攻擊者可以利用XSS漏洞植入廣告，或者發送垃圾信息，嚴重影響到用戶的正常使用。

5.3 Xss漏洞分類

a.反射型XSS

反射型XSS，也稱為非持久性XSS，是最常見的一種XSS。

XSS代碼常常出現在URL請求中，當用戶訪問帶有XSS代碼的URL請求時，服務器端接收請求并處理，然后將帶有XSS代碼的數據返回給瀏覽器，瀏覽器解析該段帶有XSS代碼的數據并執行，整個過程就像一次反射，故稱為反射型XSS。

該類攻擊的主要特點是它的及時性和一次性，即用戶提交請求后，響應信息會立即反饋給用戶。該類攻擊常發生在搜索引擎、錯誤提示頁面等對用戶的輸入做出直接反應的場景中。

b.存儲型XSS

存儲型XSS，也稱為持久性XSS。

在存儲型XSS中，XSS代碼被存儲到服務器端，因此允許用戶存儲數據到服務器端的Web應用程序可能存在該類型XSS漏洞。攻擊者提交一段XSS代碼后，服務器接收并存儲，當其他用戶訪問包含該XSS代碼的頁面時，XSS代碼被瀏覽器解析并執行。

存儲型XSS攻擊的特點之一是提交的惡意內容會被永久存儲，因而一個單獨的惡意代碼就會使多個用戶受害，故被稱為持久性XSS，它也是跨站腳本攻擊中最危險的一類。二是被存儲的用戶提交的惡意內容不一定被頁面使用，因此存在危險的響應信息不一定被立即返回，也許在訪問那些在時間上和空間上沒有直接關聯的頁面時才會引發攻擊，因此存在不確定性和更好的隱蔽性。

這類攻擊的一個典型場景是留言板、博客和論壇等，當惡意用戶在某論壇頁面發布含有惡意的Javascript代碼的留言時，論壇會將該用戶的留言內容保存在數據庫或文件中并作為頁面內容的一部分顯示出來。當其他用戶查看該惡意用戶的留言時，惡意用戶提交的惡意代碼就會在用戶瀏覽器中解析并執行。

c.DOM型XSS

DOM (Document Objet Model)指文檔對象模型。

DOM常用來表示在HTML和XML中的對象。DOM可以允許程序動態的訪問和更新文檔的內容、結構等。客戶端JavaScript可以訪問瀏覽器的文檔對象模型。也就是說，通過JavaScript代碼控制DOM節點就可以不經過服務器端的參與重構HTML頁面。

該類攻擊是反射型XSS的變種。它通常是由于客戶端接收到的腳本代碼存在邏輯錯誤或者使用不當導致的。比如Javascript代碼不正確地使用各種DOM方法(如document.write)和Javascript內部函數(如eval函數)，動態拼接HTML代碼和腳本代碼就容易引發DOM型的跨站腳本攻擊。

因此，DOM型XSS與前面兩種XSS的區別就在于DOM型XSS攻擊的代碼不需要與服務器端進行交互，DOM型XSS的觸發基于瀏覽器端對DOM數據的解析來完成，也就是完全是客戶端的事情。

5.4 Xss漏洞分類判斷

如何判斷是哪一種XSS， 發送一次帶XSS代碼的請求，若只能在當前返回的數據包里發現XSS代碼，則是反射型；若以后這個頁面的返回包里都會有XSS代碼，則是存儲型；若在返回包里找不到XSS代碼，則是DOM型。

5.5 XSS漏洞的檢測與防御

a.手工檢測

手工檢測重點要考慮數據輸入的地方，且需要清楚輸入的數據輸出到什么地方。

在檢測的開始，可以輸入一些敏感字符，比如“<、>、（）”等，提交后查看網頁源代碼的變化以發現輸入被輸出到什么地方，且可以發現相關敏感字符是否被過濾。

手工檢測結果相對準確，但效率較低。

b.工具檢測

常用工具有AVWS（Acunetix Web Vulnerability Scanner）、BurpSuite等。還有一些專門針對XSS漏洞的檢測工具，如：XSSer、XSSF（跨站腳本攻擊框架）、BeEF(The Browser Exploitation Framework)等

c.防御

使用黑名單進行：

●對HTML標簽或特殊字符進行過濾

●使用內容安全的CSP

●使用設計上就會自動編碼的框架，如：OWASP ESAPI、React JS、JSOUP等，對于JAVA而言，可以使用ESAPI.encoder().encodeForHTML()對字符串進行HTML編碼。

●對于反射型和存儲型XSS，可以在數據返回給客戶端瀏覽器時，將敏感字符進行轉義，如：將單引號進行編碼替換（十進制編碼'、十六進制編碼'、HTML編碼&apos、Unicode編碼\u0027等）。

●對于DOM型XSS，可以使用上下文敏感數據編碼。如：在PHP中的htmlspecialchars（）、htmlentities（）函 數可以將一些預定義的字符轉換為HTML實體，如：小于轉化為<、大于轉化為>、雙引號轉化為"、單引號轉化為&apos、轉化為&等。

●啟用瀏覽器的HttpOnly特性可以組織客戶端腳本訪問cookie。如：在PHP中可以通過下面的代碼設置cookie并啟用HttpOnly。

案例1：某app搜索接口越權獲取敏感信息

cloud/search/group/userstaff_id 可枚舉，通過遍歷將任意的用戶拉入群聊，直接獲取大量員工的個人敏感信息，涉及組織機構、手機號

案例2：“某某查”付費資源泄露

5. 文件管理-上傳/下載

5.1 文件上傳

a. 身份校驗

進行文件上傳時，在服務端對用戶的身份進行合法性校驗。

b. 文件類型限制

須在服務器端采用白名單方式對上傳或下載的文件類型、大小進行嚴格的限制。僅允許業務所需文件類型上傳，避免上傳.jsp、.jspx、.class、.java 等可執行文件

c.禁止外部文件存儲于可執行目錄

禁止外部文件存儲于 WEB 容器的可執行目錄。建議保存在專門的文件服務器中。

d.隱藏文件路徑

進行文件保存時，成功上傳的文件需要進行隨機化重命名，禁止給客戶端返回保存的路徑信息。

5.2 文件下載

a.身份校驗

進行文件下載時，在服務端對用戶的身份進行合法性校驗。

b.文件訪問設置

進行文件下載時，應以二進制形式下載，建議不提供直接訪問(防止木馬文件)。

c.目錄跳轉

禁止客戶端自定義文件下載路徑(如:使用../../../../../或..%2F..%2F..%2F..%2F 進行跳轉)

下一篇更新邏輯安全和數據安全，敬請期待！