2

I have a web site where users can enter some text into a textbox and that text is immediately rendered in a div using javascript (strictly front end). If a user enders something like this:

This is my text<script>alert('test');</script>

It will render that content in the div and show the alert. When the user saves the record everything is HTML encoded when it gets to the server and then saved to the database, so there is no stored XSS vulnerability.

My question is if the act of rendering the contents of the textbox on the client side could pose any kind of threat? If so, what could a malicious user do?

Improve this question
6
  • This isn't a XSS that you posted. It's how people test for XSS (oftentimes). A malicious XSS will attempt to download malicious js files, exfiltrate data, download malicious jar files, or do some kind of other malicious activity where some other evil domain is accessed
    – user11869
    Commented Apr 10, 2014 at 23:19
  • I'm on unclear what your point is. Are you saying this is not a form of reflected XSS?
    – Abe Miessler
    Commented Apr 10, 2014 at 23:27
  • I'm saying that there is nothing "cross site" about the code you posted (you said this meaning alert(1) to me). that input field could be used for reflected xss.
    – user11869
    Commented Apr 10, 2014 at 23:32
  • Take a look at DOM based XSS. It might be relevant to you, but it's hard to tell without seeing the full context of how the field, div, scripts, etc are used. Also, is this pure javascript, or some kind of js-framework (e.g. Angular)?
    – AviD ♦
    Commented Apr 10, 2014 at 23:39
  • "everything is HTML encoded when it gets to the server and then saved to the database" You're storing html encoded data? WTF
    – CodesInChaos
    Commented Apr 11, 2014 at 11:14

3 Answers 3

Reset to default
2

It will render that content in the div and show the alert. My question is if the act of rendering the contents of the textbox on the client side could pose any kind of threat? If so, what could a malicious user do?

If this is the case I would fix it (defence in depth), but as AviD pointed out without seeing the full site and its context, it is difficult to comment further.

When the user saves the record everything is HTML encoded when it gets to the server and then saved to the database, so there is no stored XSS vulnerability.

As an aside, you should only encode the data when output - unless you are storing rich text that the user has control of (in which case other steps should be taken), you should store the text in raw format and then encode when output. This is because the encoding required differs between HTML, JavaScript, XML, etc - the context in which it is output is all important.

Improve this answer
2
  • Thanks for the explanation on when to encode. How does the encoding differ between the various technologies? Wouldn't encoding < as &lt; work for all three of your examples?
    – Abe Miessler
    Commented Apr 14, 2014 at 4:47
  • < would be hex entity encoded in JavaScript, so it would become \x3c. HTML and XML are similar, but XML doesn't have sequences such as &pound; defined as default (although &#163; would work in both cases).
    – SilverlightFox
    Commented Apr 14, 2014 at 6:59
1

An attacker could use social engineering to trick the user into entering heavily-obfuscated javascript into that box. The attacker could claim that by entering that code something really funny or awesome will happen, but what actually happens is that it compromises their login credentials.

Improve this answer
1
  • True, but they could also do this by getting the user to enter it in their address bar on any site.
    – SilverlightFox
    Commented Apr 11, 2014 at 13:10
0

It is DOM-based XSS, so it is a security threat. Even it is self-XSS, it can be used in social engineering attacks, so you must fix it.

Also you can use http-only cookies and some additional http headers for protection

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .