在安全測試中，我們經常會遇到一個特殊的場景：若在輸入框內輸入 javascript:xxxxx 就可能會導致頁面的 XSS 漏洞。這個就是偽協議特性所帶來的漏洞，攻擊者可能利用這個特性進行 XSS 攻擊。因此，本文將詳細介紹偽協議的含義、常見用途和危害，并說明如何通過常見的方法繞過偽協議的攻擊，以避免這種類型的安全問題。

偽協議是指類似于協議的字符串，以“javascript:”開始，后面緊接著其他JavaScript代碼。它是一種用于在Web瀏覽器中調用JavaScript程序的特殊協議。一般來說它已經被廢棄了且不推薦使用，但是在一些老程序開發和測試中仍然存在。

舉一個例子，比如在一些網站的搜索框等輸入框中可以輸入“javascript：alert（'hello'）”，則頁面上就會出現一個彈窗顯示“hello”字樣。這就是一個使用偽協議的例子。

但是偽協議也帶來了很大的安全隱患。因為攻擊者可以通過簡單的設置，將惡意 Javascript 代碼注入目標頁面，達到執行不安全腳本程序的目的。一些比較典型的攻擊方式，常常是構建一個隱藏的iframe或a標簽，比如：

<iframe src="javascript:alert('惡意代碼注入');"></iframe>
<a href="javascript:alert('惡意代碼注入');">危險鏈接</a>

在這個例子中，攻擊者構建了一個iframe和一個a標簽，這些標簽的src或href屬性被設置為“javascript:”偽協議，目的是通過字符串中的JavaScript代碼注入攻擊者的惡意程序，在目標站打開的網頁中執行任意JavaScript代碼。

此時我們需要通過一些方法來繞過偽協議的攻擊，比如：

（1）過濾注入危險代碼，比如在輸入框等處使用富文本編輯器，對用戶的HTML代碼做過濾處理；

function sanitize(html) {
const sanitize = require('sanitize-html');
return sanitize(html, {
allowedTags: []
});
}

（2）過濾掉非 http/https 的協議，只允許特定白名單內的協議，即跨站點腳本攻擊保護策略中的 CSP(Content-Security-Policy)機制。

http-equiv="Content-Security-Policy" content="default-src 'none'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; connect-src 'self' *.domain.com; img-src * data:">

在該例子中，CSP被設置為只允許通過 https 協議傳輸圖像、各種資源、媒體和 JavaScript 腳本，而禁止使用其它的協議。

綜上所述，偽協議具有很高的攻擊性，安全測試中一定要注意避免這種安全風險。本文介紹了一些繞過偽協議攻擊的方法，大家可以根據具體情況來選擇合適的處理方式，以保證網站安全。