1

This question already has an answer here:

What is the best way to prevent stored XSS?

The problem with the first solution is that data may be modified (character encoding, partial or total deletion...), which can alter the behavior of the application, especially for display concerns.

marked as duplicate by SilverlightFox, Xander, S.L. Barth, Bryan Field, techraf Aug 23 '16 at 21:39

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 1
    I'm voting to close this question as off-topic because it is a cross post of stackoverflow.com/q/39084020/413180 – SilverlightFox Aug 23 '16 at 15:42
  • 1
    Cross posting is a bad habit, but the question is clearly on-topic here, too. – jknappen Aug 23 '16 at 15:46
  • @SilverlightFox IMO, this question is much better suited for this site than Stack Overflow. – Alexander O'Mara Aug 23 '16 at 15:54
  • @AlexanderO'Mara: Agreed, however the accepted way for the OP to do that is to flag their question to the moderator and then ask them to migrate it. See here: you can flag the question for moderator attention and request that they migrate it for you. – SilverlightFox Aug 23 '16 at 15:58
  • 1
    And here: meta.stackexchange.com/a/64069/241749 – SilverlightFox Aug 23 '16 at 16:00
1

Normally for XSS prevention we use html escape character in order the validate the input character or input. According to OWASP here are some of the things that you must follow:

For client side and server side:

  • Escape character before processing the given input.
  • Better use security encoding library.
  • Do not enter untrusted data except in allowed location.
  • HTML Escape Before Inserting Untrusted Data into HTML Element Content
  • Attribute Escape Before Inserting Untrusted Data into HTML Common Attributes
  • JavaScript Escape Before Inserting Untrusted Data into JavaScript Data Values
  • HTML escape JSON values in an HTML context and read the data with JSON.parse
  • CSS Escape And Strictly Validate Before Inserting Untrusted Data into HTML Style Property Values
  • URL Escape Before Inserting Untrusted Data into HTML URL Parameter Values
  • Sanitize HTML Markup with a Library Designed for the Job
  • Prevent DOM-based XSS

For server side:

  • Use HTTPOnly cookie flag

  • Implement Content Security Policy

  • Implement and configure WAF like Mod security.

  • Use the X-XSS-Protection Response Header

There are other prevention measures. You can check this link to get more detailed information.

https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

1

The most effective solution is probably a mix of input validation and output encoding.

I don't know that you can depend on the client to implement effective XSS mitigations. Hopefully they do, but it's not something you can depend on.

The first question you want to ask is what you do with input that fails validation. Do you remove bad characters and let the rest of input continue? That will make your application unpredictable for the user, which never seems like a good idea.

Another thing to keep in mind is that your data may not always be displayed within HTML. What if your data is included in a PDF document or sent to a printer? Those systems will have their own formats and HTML encoding won't make sense.

Here is the approach I would recommend:

  • Define the acceptable input in terms of size and character set.
  • Define your behavior for invalid input.
  • Validate input and either reject (recommended) or scrub
  • Use safe methods to store the input in your datastore
  • When presenting the data back to users encode it properly for the format (HTML, javascript, etc)

There's a risk here that someone on your team may make the assumption because the data is in an internal datastore that it is safe and start using the data without doing proper encoding.

  • That's what I think to. – Pleymor Sep 19 '16 at 8:49
0

Ideally; server side. Make sure your code does not place unsanitized user input into the page. But it wouldn't be a disaster to run it client-side. Because the victim is the client where it's checked. This opens up the possibility of the user circumventing the security measure but if done well, that would be quite a hassle.

  • Could you expand your answer to explain what client side protection is viable, and what isn't? It would also be good if you explain "the victim is the client", which is the whole point of XSS. – Alexander O'Mara Aug 23 '16 at 16:00
  • XSS needs three nodes, hence the cross. Here i was talking about stored and reflected XSSs, in both cases the server is also the victim of being an involuntary trusted source of malicious code. Both sides can stop the attack. Reflected attack scenarios have the attacker supply the victim with a malicious URL. The client then has the server reflect the malicious content into the page. With stored XSS, the malicious code is stored in the servers database and presented as a comment or username for example. Serverside is ideal because it is aware of untrusted input. See answers above for the rest. – J.A.K. Aug 23 '16 at 16:31
0

The client should not be responsible for preventing any type of XSS apart from DOM based XSS, although security headers can help it to not execute anything it is not meant to. XSS prevention is still the responsibility for the server, apart from DOM based XSS.

The browser client is also useless at validation because an attacker will bypass it to achieve XSS.

I've updated this question here though for how to prevent all types of XSS. https://security.stackexchange.com/a/134722/8340 (also more information on security headers).

Not the answer you're looking for? Browse other questions tagged or ask your own question.