1
votes

I have an API written in Java where I am doing POST call but the malicious content is being sent to the API. Ideally, to prevent XSS attack, the API should not accept such data or at least sanitize it before storing/responding to it.

{"first_name":"<script>alert(document.cookie);</script>","last_name":"
<script>alert(document.cookie);</script>"}

I want to add XSS validations/ sanitize script tags in Java to prevent the content from XSS attack. Can anyone suggest the best way to prevent XSS attack in Java? Is there a way to encode and decode the HTML tags shown above?

After going through the different documentation, I found that owasp-java-encoder can be used to encode HTML content and this function can be used to encode HTML Content Context.

<%= Encode.forHtmlContent(UNTRUSTED) %>

I am looking for something which allows me to encode the HTML content while storing data and decode it while displaying it.

1
"at least sanitize it *before* storing/responding to it" -- I personally never do this. I don't block content, I don't sanitize content before storing it in the database (because I have always run into the requirement that I have to store *exactly* what the user typed) -- instead, you can sanitize on output ... when you read from the DB and are sending it to some client, then sanitize it. That also makes more sense, because how you sanitize something depends on what the data is used for. Safety in a PDF is different than safety on a web page, or in JSON. - Stephen P
@StephenP Sanitizing before storing is important to prevent persisted XSS vulnerability (which is more dangerous than reflected version). - java-addict301
@java-addict301 - flatly, no it isn't. Did you read my entire previous comment? You need to sanitize before you use what is stored for its intended purpose. If you receive <script>...</script> it is perfectly safe to store that. If you're then going to send that to a web page then you need to sanitize it. But what if you're also going to output that to a PDF? I don't want it to appear as &lt;script&gt; ... so it should not be sanitized -- but too late! you've already stored the sanitized version, which can't be safely reversed. - Stephen P
We are being required to do exactly what @java-addict301 is saying by our security people. We would NEVER want to deliberately persist an attack vector into the database. We have no requirement to allow garbage in exactly as typed. That seems like that would be more of an exception case than the rule. - nfdavenport
@StephenP Storing potentially malicious HTML to be both displayed in a browser and used for something else seems like a bad design practice to me. Defense-in-depth approach would suggest sanitizing anything stored (as well as when it's retrieved) if its purpose is to be displayed in a browser. It would be far too easy for malicious HTML to show up in a web browser if it's just sitting in your database for that purpose. - java-addict301

1 Answers

1
votes

As Stephen P mentions, you should generally be encoding data on output. You want to do this on output to ensure you're using the correct encoding for the output, and to prevent double encoding. The OWASP encoders are a good choice for this. See the OWASP XSS Prevention Cheat Sheet for details on when to use various encoders.

You want to validate/sanitize on input as much as possible, using white list validation if possible. But for free form text you won't, and shouldn't, do XSS encoding at this point.