I have a text field that allows the user to type whatever he/she wants. After saving, the results are later displayed on the screen to potentially many people.
XSS seems a bit like black magic to me, so I am wondering what the current best practices are for handling this situation (from specific ways to sanitize input to specific ways to encode html to display)?
Since you want current best practices and the latest answer here is August 2012, I thought I might as well weigh in and update this.
Best practises to prevent any type of XSS attack (persistent, reflected, DOM, whatever).
X-XSS-Protection: 1; mode=block to activate reflective XSS browser protection into blocking mode instead of filtering mode. Blocking mode stops attacks like thisX-Content-Type-Options: nosniff to prevent JavaScript being inserted into images and other content types.Content-Security-Policy: with strict script-src and style-src's at least. Do not allow unsafe-inline or unsafe-eval. This is the daddy of headers for killing off XSS.<body data-foo="@foo" />@foo will output an HTML encoded version of the variable. e.g. " /> would give <body data-foo="" />" />var foo = $("body").data("foo");document.write, otherwise you could introduce a vulnerability. Ideally though use textContent or JQuery's text() and attr() functions.Tackle these in reverse order. Concentrate on #3 as this is the primary mitigation for XSS, #2 tells the browser not to execute anything that slips through and #1 is a good defence-in-depth measure (if special characters can't get in, they can't get out). However, #1 is weaker because not all fields can be strictly validated and it can impair functionality (imagine Stack Exchange without the ability to allow "<script>" as an input).
function escapeHtml(str) {
return String(str)
.replace(/&/g, "&")
.replace(/</g, "<")
.replace(/>/g, ">")
.replace(/"/g, """)
.replace(/'/g, "'")
.replace(/\//g, "/")
}
Escape quotes, filter out the word javascript, restrict the allowed letters, etc.
You might want to just read through the OWASP guidelines on XSS.
This additional page at OWASP should be useful to, it deals with the encoding issues in our discussions below.
Compose your HTML using an auto-escaping template language that, by default, escapes untrusted inputs for you.
For example, Django templates escape HTML special characters:
Clearly, user-submitted data shouldn't be trusted blindly and inserted directly into your Web pages, because a malicious user could use this kind of hole to do potentially bad things. This type of security exploit is called a Cross Site Scripting (XSS) attack.
To avoid this problem, you have two options:
- You can make sure to run each untrusted variable through the escape filter, which converts potentially harmful HTML characters to unharmful ones. This was the default solution in Django for its first few years, but the problem is that it puts the onus on you, the developer / template author, to ensure you're escaping everything. It's easy to forget to escape data.
- You can take advantage of Django's automatic HTML escaping. The remainder of this section describes how auto-escaping works. By default in Django, every template automatically escapes the output of every variable tag.
There are also a variety of contextual auto-escaped templates which are a bit smarter, and can prevent XSS even when your templates contain embedded JavaScript, CSS, and URLs.
Closure templates says:
Contextual autoescaping works by augmenting Closure Templates to properly encode each dynamic value based on the context in which it appears, thus defending against XSS vulnerabilities in values that are controlled by an attacker.
Go's template language uses contextual autoescaping:
HTML templates treat data values as plain text which should be encoded so they can be safely embedded in an HTML document. The escaping is contextual, so actions can appear within JavaScript, CSS, and URI contexts.
The single best practice: strictly control type and sanitize your data.
Always use proper method to output data according to type: never render what was entered as text in HTML (i.e. assign user-entered text data to text node's .data property in DOM, not to magical .innerHTML). Never use input in eval-like construction or as substring of database query - proper tools would be expression parser and placeholders respectively.
Reject or clean-up everything coming to your program from external sources (including your very own internal databases, that could be compromised too!) to strict set of allowed patterns.
Use established and proven protocols and serializers to transport data, preferably one that have native implementation on both sending and receiving end (JSON serializer, protobuf, Storable in Perl, etc.) instead of homemade quoting.
If the server only serves entities and values (so doesn't serve DOM parts), and doesn't build html, encoding values creates encoding issues because the part which integrates these values into the DOM is already supposed not to trust its inputs, which results in double encoding problems.
I think the role of such a server (which doesn't build DOM but only stores and serve data) is not to sanitize inputs. However, it can still validate inputs early and return a 400 Bad Request if an attack pattern is detected. This way, the server contributes to protection against XSS without all problems of data modification due to sanitizing.
I think sanitizing server-side must be reserved to the servers which build DOM server-side: which serve HTML pages or HTML page parts.
But if DOM is modified client-side, the JS code must not trust its input and prevent from XSS injections.
Problem is: in Java, OWASP security libraries offer APIs to sanitize HTML but not to only valisate it. To do so, I've found the hibernate annotation @SafeHtml which uses JSoup and can be used easily on DTO fields with @Valid annotation to enable validation on a class/method/parameter.
Excuse me if i'm not very clear. English is not my mother tongue. The best way to ensure a great level of security in your product is to follow the golden rule: "Never trust user inputs"
So you must always assume that a user will try to send unexpected data to your app, that he will not follow protocols (ie: he will spoof some fields, he will replay request, etc.) And you need to predict his behavior.
For the XSS point you should
-> Validate the user input (ie: if you expect to get a name, you should block all values that contain special char such % or ", if you expect a phone number you should block values that contains letters, an so on)
-> Sanitize the user input (ie: escape all character that have a specifical semantic for the interpreter in the backend. For the XSS it's ussually html/javascript so you should care about ", <, > in priority)
Like have said our fellows there is a great guide made by the OWASP concerning the XSS prevention: https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
I have a text field that allows the user to type whatever he/she wants. After saving, the results are later displayed on the screen to potentially many people.
That's the problem. Do NOT trust user's input... To avoid XSS you must sanitize the user's input before storing it in the DB.
Some things you should check:
Do not allow HTML tags. Once you have all the tags forbidden, then you could allow some of them (like this site) like <hr> <b> etc. Or creating your own tag system, [img] [b]...
Do not allow " or ', replace them by their HTML code " and '
If you are planning to allow hyperlinks, be sure that the url are valid. In other words, they must start with http:// or https://
Probably, the language on which you are developping the application has functions to check most of the previous points (at least, checking quotes and HTML tags).
