0

I developed a Java Web app using JSP and Servlet. Client did run a Security audit using a security team and they came back complaining the app is vulnerable to XSS attacks (Cross Scripting).

They have suggested to do output validation as well as server side input validation for all fields, and suggested using centralised input validation Lin's from OWASP and Apache.

I searched this, they seems to be true, but a highly decorated SO user suggested output validation is sufficient - https://stackoverflow.com/a/3445373/1379286

According to him, the attack has no meaning to database or server code, so we should only worry about displaying matter. Answer is old, but edited in 2020 May

The web app is used by the GM and the IT admin of the company, available in public URL

So, JSTL only is the way to go?

Olaf Kock
  • 46,930
  • 8
  • 59
  • 90
PeakGen
  • 21,894
  • 86
  • 261
  • 463
  • Simply escape(or even strip) any incoming data that later would be used by a client. It's easy to bold your name by `SpongeBob` rather `SpongeBob`. That `` has no meaning for your server/db, but the target user that takes the data, yes. another way is providing data as `CDATA` to user, but I prefer escaped submitted data. –  Sep 19 '20 at 15:53
  • @911992 Thank you for the reply, but I'm not sure what you meant. You mean use JSTL as suggested by the answer pointed in my question? – PeakGen Sep 19 '20 at 16:03
  • Using JSTL will perform escaping over-and-over for each response have to proceed. So basically, data is stored non-escaped in db. If client should not provide any scripted data, so any incoming data must be escaped. or maybe no? this is your policy. Use the JSTL solution when you need to keep the client info as user has inserted, otherwise escape it before it's persisted. –  Sep 19 '20 at 16:14
  • I disagree, it should not be encoded before inserting to a database (apart from the encoding needed for the actual protocol, ie. sql, but underlying layers should manage that if you do it correctly via say parameters or an ORM). Proper output encoding is sufficient to prevent XSS, so you should not html encode input. If you encode before inserting to the database, you need to select an encoding method before you know where the data will be used, and that's not good, because different output contexts need different encodings (html, javascript, xml, json - who knows where it will go later). – Gabor Lengyel Sep 19 '20 at 19:05
  • @GaborLengyel Thanks. So basically you say that it's sufficient to check XSS issues in display and not needed to validate every single input field.. That means using JSTL to validate the "output" is enough, isn't it? – PeakGen Sep 19 '20 at 19:11
  • @LemonJuice I'm not very familiar with JSTL tbh, but I'm pretty sure just *having* it will not prevent XSS. You need to be using it correctly, which means applying the appropriate output encoding to every single output of any user input. For example c:out is ok for an html context, but I'm not so sure about an html attribute, and it's definitely not good for variables written in a javascript context. I'd be cautios just leaving it all to JSTL, you need to understand what, why and how you want to encode. – Gabor Lengyel Sep 19 '20 at 21:04
  • @GaborLengyel Thanks. We checked, it can successfully escape JavaScript alert, so I guess JS is fine – PeakGen Sep 20 '20 at 02:05

0 Answers0