Win a copy of Rust Web Development this week in the Other Languages forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • Ron McLeod
  • Liutauras Vilda
  • Jeanne Boyarsky
Sheriffs:
  • Junilu Lacar
  • Rob Spoor
  • Paul Clapham
Saloon Keepers:
  • Tim Holloway
  • Tim Moores
  • Jesse Silverman
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Piet Souris
  • Frits Walraven

JSTL C:OUT handles HTML encoding and ensure the entered user input is save?

 
Ranch Hand
Posts: 255
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,


I have 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 we replace the code with the following :

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

, the <script>alert('XSS');</script> is still be displayed on the page ? in that case it is still executed and there fore making it again unsafe and susceptible to XSS attacks?

Could you please highlight how the JSTL c:out tag will make sense in handling the XSS issues if the Javascript alert passed in the username input is still getting displayed.

Thanks in advance.
 
Rancher
Posts: 4801
50
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I said on the previous threads you created around this that a username should be validated beforehand (and I'm fairly sure a <script> element would not form a valid username), therefore you shouldn't even reach this point.

Having said that, as it should be escaping the xml, have you looked at the response returned from the server using the browser's developer tools (usually F12)?
 
Rithanya Laxmi
Ranch Hand
Posts: 255
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Dave. if the c:out tag escapes XML still the script value passed will be displayed? i see in the below link they mentioned the script will be displayed but wont be executed so the user input is safe ?

https://security.stackexchange.com/questions/115395/how-to-prevent-reflected-xss-with-the-java-struts-framework

Not sure what is the meaning of it wont be executed and safe as still the alert is displayed? please explain. In that case how we cam consider C:OUT tag to prevent XSS attacks?
 
Dave Tolls
Rancher
Posts: 4801
50
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, have you tried?

That should take no time at all to set up on a local Tomcat to show whether or not it works.

Also, when you copy/paste whole chunks from another website you ought to say so and provide a link.

But (again), you should be validating user input as it comes in, and not relying on something like this "fixing" it for you.

XSS is best prevented by not allowing it in the first place.
 
Sheriff
Posts: 67618
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The script text is displayed. But it is not script -- it is the escaped characters that make up the script. Look at the source HTML being sent to the browser.
 
reply
    Bookmark Topic Watch Topic
  • New Topic