前端開發中的字元編碼詳解

royalrover發表於2016-05-07

前端開發過程中會接觸各種各樣的編碼,比較常見的主要是UTF-8和HTML實體編碼,但是web前端的世界卻不止這兩種編碼,而且編碼的選擇也會造成一定的問題,如前後端開發過程中不同編碼的相容、多位元組編碼可能會造成的XSS漏洞等。因此,本文旨在更好的全面瞭解涉及前端開發領域的字元編碼,避免可能出現的互動和開發中的忽視的漏洞。

URL編碼

我曾經在URL編碼解碼和base64一文中講述了URL編碼中的三組函式,並對比了這三組函式與base64編碼的關係,在此簡要說明一下。
escape/unescape函式針對寬字元做unicode編碼,並針對碼值做十六進位制編碼,所以使用escape針對漢字編碼會得到形如”\uxxxx”的結果;encodeURI/decodeURI,encodeURIComponent/decodeURIComponent函式針對寬位元組編碼卻不同於escape,首先針對寬位元組字元進行UTF-8編碼,然後針對編碼後的結果進行“%”替換,得到結果。以上所述都是針對寬位元組字元而言,對於編碼靠前的ASCII字元而言,上述三組函式的安全字元的範圍也有所不同,具體可在上文中瞭解。

base64編碼

base64編碼在前端通常用於圖片和icon的編碼,它將每3個8位位元組為一組,分成4組6位位元組,並且每個位元組的高位補零,形成4個8位的位元組,由此可看出base64編碼是可逆推的。在大多數瀏覽器中,提供了ASCII字元的base64編碼函式,即window.btoa()。該函式無法針對寬位元組進行base64編碼,若針對中文編碼,則需現轉換位UTF-8編碼,然後進行base64編碼。

function unicodeToBase64(s){ return window.btoa(unescape(encodeURIComponent(s))) }

通過encodeURIComponent對寬位元組字元編碼,是“%xx”形式的編碼,與UTF8編碼的區別僅在於字首(這是由規範RFC3986決定的,將非ASC字元進行某種形式編碼,並轉換為16進位制,並在位元組前加上“%”)。因此通過unescape(encodeURIComponent(s))可以轉化為UTF8位元組。當然,也可自己寫一個轉換函式,按照一定規則便行為UTF-8編碼的位元組,如下例:

```
unescape(encodeURIComponent("中國")) //結果:"中å½"
encodeURIComponent("中國") //結果:"%E4%B8%AD%E5%9B%BD"
console.log("\u00E4\u00B8\u00AD\u00E5\u009B\u00BD") // 結果: "中å½"
```

通過簡單的replace函式,就可以完成URL編碼到UTF8編碼的轉換,進而完成寬位元組字元到base64編碼的轉換。有了這個函式,我們手動生成一些data URI形式的內容,只需制定MIME型別和編碼方式,就可以實現文字的轉換,如以下程式碼:

```
<a href="data:text/html;charset=utf-8;base64,PHNjcmlwdD5hbGVydCgxMik8L3NjcmlwdD4=" >abc</a>
// 未編碼前:<a href="javascript: alert(1)">test</a>
```

前端UTF8編碼與後端GBK編碼的相容

目前前端大都採用UTF8進行編碼,不管是html、js抑或是css,而後端則由於歷史原因大都採用GBK或GB2312進行解碼,因此前端通過parameter傳遞的URL編碼的字串就不可能直接在後臺進行解碼,為了更好的相容性,前端可進行兩次URL編碼,即encodeURIComponent(encodeURIComponent(“中國”)),這樣後端接收到引數後,先使用GBK或GB2312解碼,得到了UTF8編碼後再使用UTF8解碼即可。兩次編碼主要是利用“ASC字元使用GBK或GB2312編碼不變”的特點完成,富有技巧。

HTML實體編碼與進位制編碼

實體編碼針對HTML的預留字元而言,如“<>”等。實體編碼有兩種形式&實體名;&entity_number;,由於瀏覽器對&實體名;的相容性有差別,因此最好採用實體號的形式編碼。

進位制編碼,顧名思義將ASC字元對應的碼值按照十六進位制或十進位制編碼,並轉化為&#x;(16進位制)&#D;(10進位制)形式。

單單針對實體編碼而言並沒有什麼特殊強調的點,之所以把它單獨列為一個章節,意在強調這兩種編碼與js程式碼的作用域的關係。

<div onclick="document.write('<img src=1 onerror=alert(23)>')">cccc</div> 
<div onclick="document.write('&lt;img src=1 onerror=alert(23)&gt;')">cccc</div>
<img src=1 onerror=alert(23)>
<img src=1 onerror=alert(23)>
<script>
   document.write('&lt;img src=1 onerror=alert(23)&gt;');
   document.write('<img src=1 onerror=alert(3)>');
   document.write('<img src=1 onerror=alert(23)>')
   document.write('\u003c\u0069\u006d\u0067\u0020\u0073\u0072\u0063\u003d
\u0031\u0020\u006f\u006e\u0065\u0072\u0072\u006f\u0072\u003d\u0061
\u006c\u0065\u0072\u0074\u0028\u0032\u0033\u0029\u003e')
</script>

程式碼中列舉了8個例子,第一個在事件處理函式onclick中輸出HTML片段;第二個則輸出經實體編碼後的HTML片段;第三個則是直接針對<img src=1 onerror=alert(23)>做16進位制編碼;第四個則是針對onerror事件處理函式做16進位制編碼;第五個則是在指令碼中輸出實體編碼的字元;第六個針對事件處理函式做16進位制編碼;第七個則針對所有的字元做16進位制編碼;第八個則是在script中直接輸出<img src=1 onerror=alert(23)>的unicode編碼。

對比結果,前兩個例子在點選後都會彈出alert;第三個例子則在頁面中顯示文字<img src=1 onerror=alert(23)>;第四個例子則會在頁面載入初期彈出alert;第五、七會輸出字串;第六、八則會在第四個例子中的alert之後也彈出alert。現在分析這些結果,通過第一二個例子可知道,HTML標籤中(除script標籤)的內聯js程式碼可以進行HTML實體編碼,這是非常重要的一點,我們可以更為明確的進行驗證:

<div onclick="alert('&lt;img src=1 onerror=alert(23)&gt;')">cccc</div>

輸出的結果自然是<img src=1 onerror=alert(23)>,這的確論證了我們上文提到的這一點;第三個例子說明了HTML解析器在進行詞法分析前,首先進行解碼,十六進位制和十進位制皆可,因此,結果自然輸出形如<img src=1 onerror=alert(23)>的字串;第四個例子則緊接著論證了內聯在HTML的並採用十六進位制編碼的js程式碼同樣會被正確解析並執行,這說明了進位制編碼同樣可被HTML解析器解析;第五、七個例子說明在js中同樣可以使用實體編碼和進位制編碼,解析的結果會渲染在頁面上;第六個例子則論證了上一觀點,只針對事件處理函式做進位制編碼,執行後頁面彈出alert;第八個例子則是在js中執行unicode編碼的字串,正常alert。

由此可見,js程式碼內聯在HTML的非script標籤內,則會遵守HTML編碼規範:進位制編碼和實體編碼;而在js程式碼(script標籤內以及js檔案內)中,則遵從js編碼:1,unicode形式編碼(\uxxxx)2,普通的16進位制編碼(\xH),這可通過第八個例子得到證明。之所以在本節提到這麼多編碼特點,主要提醒大家在預防XSS時需要注意的幾點:

  • 檢測使用者輸入時,不僅僅需要防範類似“<>”這樣的字元,通過unicode編碼或進位制編碼仍有可能注入程式碼
  • 需要針對特定的關鍵字做過濾,如“eval、write、prototype”
  • 儘可能禁止內聯事件處理函式的使用
  • js過濾“src/href/action”屬性,如“javascript:”,”data:”

JS編碼

其實在上節中已提到了js編碼,即js可執行unicode編碼和十六(八)進位制編碼後的字串,但是不支援十進位制編碼的字串。具體操作可通過常用的幾個函式來實現,如“eval,write,setTimeout,Function”執行編碼後的字串;同樣,對於十進位制編碼的字串,通過結合String.fromCharCode和eval同樣可以執行。

在此附上筆者實現的字元轉換,更為靈活的實現各種自定義形式的字串編碼:

var Code = {};
/**
 *
 * @param str 待編碼字串
 * @param jinzhi 進位制編碼
 * @param prefix 字首
 * @param postfix 字尾
 * @param count 總共編碼的位數,預設為4
 * @returns {string}
 */
Code.encode = function({str = '',jinzhi = '16',prefix = '\\u',postfix = ';',count = '4'} = {}){
    var ret = '';
    var addZero,tmp;
    for(let i=0;i<str.length;i++){
	tmp = str.charCodeAt(i).toString(jinzhi);
	addZero = count - tmp.length + 1;
	ret += prefix + new Array(addZero).join('0') + tmp + postfix;
    }
    return ret;
};
Code.decode = function({str = '',jinzhi = '16',prefix = '\\u',postfix = ';'} = {}){
    var ret = '';
    var splits = str.split(';');
    for(let i=0;i<splits.length;i++){
	let tmp = splits[i].replace(prefix,'');
	ret += String.fromCharCode(parseInt(tmp,jinzhi));
    }
    return ret;
};

console.log(Code.encode({str: '<img src=@ onerror=alert(123) />'}));
console.log(Code.decode({str: Code.encode({str: '<img src=@ onerror=alert(123) />'})}))

另外,對於js輸出點的過濾其實並不僅限於上文提到的如eval、setTimeout、Function等幾個,由於JS語法比較靈活相對“漏洞”較多,可使用的“線索”也越豐富,如前段時間在Stackoverflow上發現的一個問題,即

(0)['constructor']['constructor']('return "abc;"')()

同樣可以執行JS程式碼,確實挺有特點的,具體為什麼上述形式可以執行程式碼,請讀者自己仔細品味。

相關文章