The essential step to approach XSS “protection”<\/h4>\n\n\n\n
Like with all, it\u00b4s comprehension. “Cross-site” refers to the fact, that the web server sends data to the client, “Scripting” details that such data could be executed by the client (but not by the server itself). But in order for a web server to send executable code to the client, this data first has to get to the server. Either by being programmed as part of the web application the server provides or … sent to the server by a client!
This understanding brings two basic concepts to the mind<\/p>\n\n\n\n
- \n
- What kind of data a (web) client executes that a (web) server does not? It must be the currently most widely-spread programming language: JavaScript<\/a> (JS). The potential harm running untrustworthy JS code is infinite as JS is virtually omnipotent.<\/li>\n\n\n\n
- If data has to be stored on the (web) server before it can unleash its potential harm to clients, it needs to be considered which data is worth being trusted and which is not<\/li>\n<\/ul>\n\n\n\n
Untrustworthy data sanitization<\/h4>\n\n\n\n
Which data can be deemed to be trustworthy? Only the one that is fully under control of your party. Typically this is your program code (provided you\u00b4ve conducted adequate quality checks). Nothing else!
Second, there might be code of other parties used by your own code. You may check the quality of such code as well and – if it proofs to be secure – trust it (on a per-release basis).
Third, there is (arbitrary) data generated by the clients (users) that your party has no control about. As a consequence, such data is always(!) untrustworthy and logically in scope of XSS protection.<\/p>\n\n\n\nUsages of untrustworthy data<\/h4>\n\n\n\n
Having deduced the data in scope, currently there are three ways to use such data in web UIs presented by a browser and thus potentially prone to XSS<\/p>\n\n\n\n
- \n
- Display the data as text, in text inputs (incl. text areas) or select boxes<\/li>\n\n\n\n
- Use the data as part of generated JS<\/a> code<\/li>\n\n\n\n
- Use the data as part of generated Cascaded Style Sheets (CSS<\/a>)<\/li>\n<\/ul>\n\n\n\n
In order to consider the attack surface of your application, will you need untrustworthy data to be part of generated CSS? Probably not. Will you need untrustworthy data to be part of generated JS? Probably yes. Will you need to display untrustworthy data within your web UI? Definitely!
So we have made our priorities clear. Why is that important? Because each of these cases requires a different approach to XSS protection.
Consequently, this article will focus on the top priority, which is displaying untrustworthy data as HTML.<\/p>\n\n\n\nDisplay untrustworthy data as HTML text<\/h4>\n\n\n\n
Depending on the main use case of your application, there are two basic strategies to approach XSS protection<\/p>\n\n\n\n
- \n
- If your application is to be used just to process basic text (no potentially malicious special characters (‘, “, <, >), no line feeds, tabs etc., then the easiest and most effective approach is to delete all unsupported characters from untrustworthy data before<\/strong> persisting the same (XSS input sanitization). The result could even be referred to as an XSS “prevention” as there is nothing left that could be exploited<\/li>\n\n\n\n
- If your application is to be used to process untrustworthy data exactly the way it has been entered by users (blogs, descriptions including code snippets, emojicons etc.), then things get far more complicated<\/li>\n<\/ul>\n\n\n\n
Consequently, this article will focus on the latter (thus more interesting) case. By the way: the software powering this web site is such an application.<\/p>\n\n\n\n
No XSS input sanitization<\/h4>\n\n\n\n
If you must display untrustworthy data exactly the way it has been entered by users, the logical consequence is that you wouldn\u00b4t want to touch them when persisting the same. This implies that your persistence layer may contain potentially (XSS) malicious data (not to be confused with SQL injection, whose input sanitization is always mandatory (but that\u00b4s another story out of scope of this article). So the persisted data remains perfectly untrustworthy<\/strong>.
Subsequently, whenever data is extracted, it needs to be properly XSS sanitized before<\/strong> being output to a web UI.<\/p>\n\n\n\nXSS output sanitization<\/h4>\n\n\n\n
“Web” UI means that data is output to (X)HTML, so regarding XSS some aspects of HTML are good to be known. Not all HTML elements use the same syntax pattern with regards to the position of data to be displayed<\/p>\n\n\n\n
- \n
- Text inputs define the output value in a value<\/em> attribute<\/li>\n\n\n\n
- Text areas and select options enclose the output value between their start and end tags<\/li>\n<\/ul>\n\n\n\n
Good news might be that modern web browsers automatically sanitize the values of the value<\/em> attributes. But attackers are smart enough to break that mitigation. As every string requires delimiters, the same may be used to intentionally end a string previously input followed by malicious (JavaScript) code.<\/p>\n\n\n\n
Break the implicit XSS mitigation on output values<\/h4>\n\n\n\n
Following a classic HTML example<\/p>\n\n\n\n
<input type=”text” value=”some output data”><\/p>\n\n\n\n
That code displays a text input field holding the value some output value<\/em>. Typically it is part of a web form that sends the data entered to the server on submit. According to the approach described above the web server will not XSS sanitize that value before persisting it. If the application grants users to edit their data, the form is loaded and the inputs are pre-populated with the existing values requested from the persistence layer. And we rely on the browser to sanitize them…
Now imagine an attacker entering the following value into the text field<\/p>\n\n\n\n” <script>alert(“XSS!”)<\/script><\/p>\n\n\n\n
and sending it to the server which stores it unchanged. When opening the edit form, this value will be loaded which causes the browser to parse the following code<\/p>\n\n\n\n
<input type=”text” value=”” <script>alert(“XSS!”)<\/script>”><\/p>\n\n\n\n
Wow! The leading double quotes terminate the value of the value<\/em> attribute and the following code is proper JS which will run like a charm popping up the message XSS!<\/em>. XSS in action…
<\/p>\n\n\n\nHow to XSS output sanitize<\/h4>\n\n\n\n
Fortunately, HTML offers means to overcome such “misinterpretations”. Any potentially ambiguous or special character has a unique literal referred to as an HTML entity<\/a>. By replacing each ambiguous character by its corresponding HTML entity, things get very clear to the browser (backslashes inserted in order to prevent the browser from displaying the corresponding HTML characters)<\/p>\n\n\n\n
<input type=”text” value=”&\\quot; &\\lt;script&\\gt;alert(&\\quot;XSS!&\\quot;)&\\lt;\/script&\\gt;”><\/font><\/p>\n\n\n\n
Nothing left to execute. More obvious is the case of HTML elements enclosing the output value between tags<\/p>\n\n\n\n
<textarea rows=”3″ cols=”25″><script>alert(“XSS!”)<\/script><\/textarea><\/font>\n\n\n\n
will cause the script to be executed. Once sanitized, the code changes to (backslashes inserted in order to prevent the browser from replacing them by their corresponding HTML character)<\/p>\n\n\n\n
<textarea>&\\lt;script&\\gt;alert(&\\quot;XSS!&\\quot;)&\\lt;\/script&\\gt;>\/textarea><\/font><\/p>\n\n\n\n
Encapsulation<\/h4>\n\n\n\n
It is advisable to encapsulate sanitizers into dedicated classes or functions in order for them to serve as references thus avoiding instances (Don\u00b4t Repeat Yourself<\/em>). For the same reason, it is also advisable to encapsulate the code generating HTML elements into a dedicated class, so the generator methods inherently make use of the sanitizer methods or functions. In a best case, there will be no other option than using the dedicated generators in order to produce output, because if just a single output is not considered for sanitization, it will be vulnerable.<\/p>\n\n\n\n
Verification<\/h4>\n\n\n\n
Having realized the ideas described above, it\u00b4s not too challenging to verify the basic effectiveness of your XSS protection (best by using an offensive security testing tool in order to automate it). The following examples are taken from the Housekeeping application<\/a> in order to make them easily reproducible.<\/p>\n\n\n\n
Having realized the ideas described above, it\u00b4s not too challenging to verify the basic effectiveness of your XSS protection (best by using an offensive security testing tool in order to automate it). The following examples are taken from the Housekeeping application<\/a> in order to make them easily reproducible.<\/p>\n\n\n\n
Elements with a “value” attribute<\/h4>\n\n\n\n
In all of the following examples no popup should appear.<\/p>\n\n\n\n
Text input field. As it is a search field, the search should just run normally and re-display the search value entered.<\/p>\n\n\n\n
XSS value terminator attack<\/p>\n\n\n\n
![\"XSS](\"http:\/\/reichartonline.de\/content\/wp-content\/uploads\/2019\/04\/20190405_xss_onfocus-4.png\")
<\/a>Classic XSS attack on value terminator string<\/figcaption><\/figure>\n\n\n\n And it should find malicious code if a user (attacker) has entered such.<\/p>\n\n\n\n
XSS script tag attack<\/p>\n\n\n\n
![\"XSS](\"http:\/\/reichartonline.de\/content\/wp-content\/uploads\/2019\/04\/20190405_xss_script_tag.png\")
<\/a>Classic XSS attack on script tag<\/figcaption><\/figure>\n\n\n\n Elements enclosing output between tags<\/h4>\n\n\n\n
Text area<\/strong>. if loading an existing comment for edit, nothing unusual should happen<\/p>\n\n\n\n
![\"Javascript](\"http:\/\/reichartonline.de\/content\/wp-content\/uploads\/2019\/04\/20190406_Housekeeping_comment_edit.png\")
<\/a>Text area containing JavaScript<\/figcaption><\/figure>\n\n\n\n Select<\/strong> option using untrustworthy data<\/p>\n\n\n\n
Variable select entries might be vulnerable to XSS attacks<\/p>\n\n\n\n
![\"Variable](\"http:\/\/reichartonline.de\/content\/wp-content\/uploads\/2019\/04\/20190405_xss_select.png\")
<\/a>XSS attack on variable select entry<\/figcaption><\/figure>\n\n\n\n Simple text output<\/h4>\n\n\n\n
A comment<\/strong> containing JavaScript<\/p>\n\n\n\n
![\"Display](\"http:\/\/reichartonline.de\/content\/wp-content\/uploads\/2019\/04\/20190406_Houskeeping_comment.png\")
<\/a>Javascript code in comment<\/figcaption><\/figure>\n\n\n\n A note<\/strong> containing JavaScript (as well as SQL injection strings and multi-byte characters).<\/p>\n\n\n\n
Finding any character, including potentially executable ones.<\/p>\n\n\n\n
![\"A](\"http:\/\/reichartonline.de\/content\/wp-content\/uploads\/2019\/04\/20190407_Housekeeping_xss_combined_search.png\")
<\/a>A note containing potentially executable characters<\/figcaption><\/figure>\n\n\n\n - Text areas and select options enclose the output value between their start and end tags<\/li>\n<\/ul>\n\n\n\n
- If your application is to be used to process untrustworthy data exactly the way it has been entered by users (blogs, descriptions including code snippets, emojicons etc.), then things get far more complicated<\/li>\n<\/ul>\n\n\n\n
- Use the data as part of generated Cascaded Style Sheets (CSS<\/a>)<\/li>\n<\/ul>\n\n\n\n
- If data has to be stored on the (web) server before it can unleash its potential harm to clients, it needs to be considered which data is worth being trusted and which is not<\/li>\n<\/ul>\n\n\n\n