1

Say I have a site that allows me to save my name to the database, and that name is then displayed to other users.

I have determined that if I save the following as my name:

Abe <script>alert(1);</script> Miessler

Another page in the site will take the following steps all on the client side:

  1. Make an AJAX request to get a list of user names
  2. Return those unencoded values (so <scrip.... is returned not &gt;scrip.....)
  3. The page then HTML encodes any values that were returned and renders them on the page

I know that one should not count on anything on the client side for security, but I cannot think of a scenario where an attack would be able to get through here. Can it be done?

2
  • Happy to update my question if it is lacking in some way. Can I ask the @downvoter for an explanation? Commented Oct 23, 2014 at 6:23
  • I didn't downvote, but I think you are not being clear on the kind of client side protection (javascript? code?) being done. XXS affects client side, logically speaking, client side protection, if done correctly, should work in most cases. Scenario where it would fail would be when an attacker's script is loaded instead. Commented Oct 23, 2014 at 7:05

1 Answer 1

6

I know that one should not count on anything on the client side for security

This message has become slightly garbled. Really, it should be that the security measure needs to be done on the same side of a security boundary as the system it is protecting. For the common case of a forms-based web app that makes the server side the place where the attack might happen, and the server side the place where the defence has to be done.

But in your case the possible vulnerability, DOM-XSS, occurs in the client browser, so putting the defence against it (proper HTML escaping and/or using DOM methods instead of markup to write the content) on the client too is correct.

You must log in to answer this question.

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