I have an application that executes under Jboss server. I have an Apache server in front. My application contains a security vulnerability (XSS Cross-site scripting).

I wanted to know that I had to make changes in the code (HTML, JavaScript, Java, ..) ..?

How can I secure my application? do I set up js frameworks to secure it?

What kind of XSS vulnerability is it ?

  • Reflected

How is it introduced and what is the context ?

  • Introduced by modify my url

What Java frameworks are you using ?

Struts 1

XSS is performed by the HTML code, which was introduced by a third party and is performed by the application. In the following example to call added a postscript alert (1) . It was made on the application side.

  • Dear gentlemen, if you downvote please give at least a small comment how my answer can be improved.
    – Mercer
    Feb 22 '16 at 14:28
  • What's your question? Feb 22 '16 at 14:35
  • @SilverlightFox How can I secure my application? do I set up js frameworks to secure it?
    – Mercer
    Feb 22 '16 at 14:36
  • Too broad to answer - would depend on your code.
    – Matthew
    Feb 22 '16 at 14:43
  • I'm voting to close, as in its current form, the question is too broad. What kind of XSS vulnerability is it? Reflected/Persistent or DOM based? (in the first case, you would likely need to change the Java code, in the second code likely your JavaScript code) How is it introduced and what is the context? (Do you echo user input inside HTML code, inside javascript tags, somewhere else?) What Java frameworks are you using? There are just too many open questions right now to answer your question.
    – tim
    Feb 22 '16 at 14:56

As far as I understand, you have a reflected XSS on a JSP page (the question does not fully specify which technology but JSP is a pretty good bet if you use Struts 1)

Your solution is therefore most probably to surround the potentially dangerous data with the standard

<c:out value="${dangerousData}" /> 

tag, which escapes XML content (and therefore eliminates your nasty XSS)

Also, the standard


function provides equivalent security.

You have to use the right one depending on how you actually use the data. If you simply display the data, use c:out.

====== Update after OP's comment =====

This solution works. Let's take an example : you have a JSP with the following line, which is XSS-prone :

<p>Hello, dear ${username}</p>

the ${username} variable is replaced by the content of the username parameter in a request (typical reflected XSS).

So the request www.yoursite.com/somepage?username=<script>alert('XSS');</script>

would indeed prove the effectiveness of the XSS, with an alert box popping as a proof of concept.

If you replace your code with the following (as described in the solution) :

<p>Hello, dear <c:out value="${username}" /></p>

, the <script>alert('XSS');</script> would be displayed on the page and would not be executed, therefore making your users safe.

This is the best-practice when dealing with XSS given your technology choices.

  • ok, but this method don't work when i modify my url and add a <script>...</script> tag
    – Mercer
    Feb 22 '16 at 15:30
  • it absolutely does !! I'll add more info to my answer in a few minutes
    – niilzon
    Feb 22 '16 at 15:33
  • hope this clarifies :)
    – niilzon
    Feb 22 '16 at 15:40

You could look into: https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet to get a general idea on which things cause the XSS. Perhaps Rule#5 may be what you want to consider. Also the OWASP Secure code project has a couple of examples on Struts : https://www.owasp.org/index.php/OWASP_Code_Review_Project (version 1 is free to download).

  • It would be better if you could include key parts of the referenced page in your answer. Feb 22 '16 at 16:29

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