# Providing Email Privacy by Preventing Webmail from Loading Malicious XSS Payloads
## 4 Email XSS Detection Framework
### Data Processing  
#### 4.2.1 Type  
The data extracted directly from the EML file is the original text. As described in Section 3, attackers often bypass XSS detection by mutating it when constructing the XSS attack vectors. Therefore, it will be necessary to process the original text.  
(1) Decoding. Encoding is the most commonly used form of XSS variation. The browser's automatic decoding capability allows many encoded XSS statements to bypass WAF (Web Application Firewall), but still, be automatically parsed. One needs to restore the attack vector to get the original XSS payload. We examined the collected email attack vectors and performed the following common decodings--URL decoding, HTML entity decoding, Unicode decoding, Base64 decoding and JSFuck decoding. The HTML Entity, URL and Unicode can be decode easily by decoding tools, since their decoding principle is mapping. Base64 is an encoding method that can encrypt information, and the encrypted data is completely unreadable. Since this encryption is reversible, we can use the Base64 decryption tool to decode. Jsfuck encoding converts the string into a long text of only 6 symbols([]0!+), which can still be directly executed by the browser. The text after Jsfuck encoding is like garbled code, so we must use open source tools Jsunfuckit to decode. The decoding example of the real samples are shown in Table 3.  
\begin{table}
\begin{tabular}{|c|c|c|} \hline  & **Source Code** & **After Decode** \\ \hline Html Entity & “\(>\)\(<\)script src=“http\&#55;\&\#47;\&\#47; \\  & xss.tw\&\#47;\(4091\)”\(>\) & \(<\)script src=“[[http://xss.tw/4091](http://xss.tw/4091)]([http://xss.tw/4091](http://xss.tw/4091))”\(>\) \\ \hline URL & \begin{tabular}{c} \%253 Cimg\%250 src\%253D1\%2520 onerror \\ \%253 Dprompt\%25281\%2529\%253E \\ \end{tabular} & \(<\)img src=1 onerror=prompt(1)\(>\) \\ \hline Unicode & \
\begin{tabular}{c} \(<\)DIV STYLE=“background-image:\(\backslash\)0075\(\backslash\)0072\(\backslash\) \\ 006c\(\backslash\)0028\(\backslash\)006a\(\backslash\)0061\(\backslash\)0076\(\backslash\)0061\(\backslash\)0073\(\backslash\)0063 \\ \(\backslash\)0072\(\backslash\)0069\(\backslash\)0070\(\backslash\)0074\(\backslash\)003a\(\backslash\)0061\(\backslash\)006c\(\backslash\)0065 \\ \(\backslash\)0072\(\backslash\)0074\(\backslash\)0028\(\backslash\)0027\(\backslash\)0058\(\backslash\)0053\(\backslash\)0053\(\backslash\)005f \\ \(\backslash\)0030\(\backslash\)0030\(\backslash\)0027\(\backslash\)0029\(\backslash\)0029\(>\)029\(>\) \\ \end{tabular} &
\begin{tabular}{c} \(<\)dirrame src=“dat\&NewLine;\(2) Equivalent replacement. Direct replacement of keywords actually has less impact on model training, such as label and attribute replacement. When checking the email attack sample, we found some replacements that were more disturbing to the model, which required some equivalent replacement. We mainly performed equivalent replacement for the following situations: alphabet upper/lowercase, Full-angle Character and fromCharCode functions. The examples of equivalent replacement for the real sample as shown in Table 4.  
(3) Remove disturbing characters. Attackers often add some disturbing characters to the basic attack vector to confuse the detector's judgment. For example, if the detector reads the text in rows to detect the XSS attack, the attacker can bypass the detection by using a newline character which can block the attack vector. We checked the real email attack samples and deleted several types of disturbing characters. Some of disturbing characters is shown in Table 5.