Protect Express from XSS: Is it enough to HTML encode the entire incoming request?
I have an Express application that I want to protect against XSS.
I am crawling several pages about XSS, including OWASP , and given my application characteristics, I decided to write middleware that encodes HTML objects - more specifically XML objects, including <>"'
- my query parameters before using them in routes.
I also update the session cookies on connect to protect the bit from cookie theft.
How do I create an application
- All AJAX requests are POST (all parameters are rewritten by middleware)
- I am not using GET parameters
- The param parameters I am using must be int and I am making a mistake when they are not.
- The only data that doesn't come from user logins comes from OAuth personal data, which I also sanitize when it logs into my app.
- Client-side JS executed on page load only includes data coming from the database, presumably sanitized by middleware when entering the DB.
- window.location is used safely
- I am not using any external client JS library yet (like JQuery or FileUpload) - maybe I will add them later in the code
- When the user enters something, it is always sent to the server (via AJAX POST) and I take the opportunity to send back the sanitized input to use it in JS and / or DOM instead of the initial input
- I am not using eval
My feeling
I have come to the conclusion that with this behavior (sanitize external data as it comes in) I am avoiding all stored and reflected XSS, and using windows.location correctly prevents DOM based XSS from being used.
Is this conclusion correct or am I forgetting something? Should I use some helmet functionnality?
Edit
My question is not what is the best server side HTML sanitizer (even if it is part of it), I am rather asking you to know if the global protection I put in my code really protects my application from all known types of XSS. Specifically, I would know if my middleware isn't bad practice.
Indeed , PHP's XSS filtering feature does not cover at least DOM-based XSS attack (since it only deals with server-side HTML sanitization).
I list some features of my application to have feedback at any point I forget, or bad architecture pattern that can lead to XSS vulnerability.
Edit 2
I pick Erlend's answer as the best, however msoliman one is also excellent, and complements Erlend's answer.
source to share
While you're doing a good job here, I think you should think about it: avoid data, to avoid XSS, you need to be context sensitive. The extensive OWASP XSS protection sheet explains this in detail.
IMHO, when receiving data from a client, you must ensure that the data is valid according to the domain. This is what you do with route parameters. You expect it to be an int, and reject if it isn't. For other data types, you must do the same. Is this a valid name? (the first names usually do not contain <or>). Is this a valid postcode? This will stop many attacks, because attacks often contain characters that are not valid in the given context.
When it comes to stopping attacks, XSS, SQL injection, etc. - all subclasses of the same problem. You have to avoid data when adding it to HTML (or XML or SQL query, etc.), and you need to escape for the given context. How to avoid the data differs depending on whether it is between tags, like attribute value, inside CSS, etc.
While trying to misinform a situation on your way, you may find yourself in a situation where you find that the sanitization function is not good enough and you have partially / improperly deactivated the data and it will be a mess to fix.
Generalized:
a) Check and reject according to the domain along the path to
b) Performing context-based escaping during output
source to share
You can sanitize the html on the client side. Sanitize / Rewrite HTML client side
Alternatively, you can follow the following thread to check how to do it server side to improve security
source to share