0

I am working on a project that allows a user to customize a web page. Currently, it is possible for this user to add HTML to the page. From my research, it appears that XSS attacks are generally used to hijack sessions / steal cookies. My question is, if visitors are not allowed to add any content to this page, and if the user who customizes the page is the only person able to log in, is it necessary to prevent XSS attacks? My thought is no, because the only cookies available to steal are his or her own.

Improve this question
6
  • Just use htmlentities($VulnerableString, ENT_QUOTES, 'UTF-8') Commented Jan 13, 2013 at 20:22
  • For cookies, you should implement something like salted token and check that one on each request Commented Jan 13, 2013 at 20:23
  • Uhhhm. For cookies you have to set them to HTTP only. Commented Jan 13, 2013 at 20:23
  • If you have only one user you might be correct, but if you have more than one then any user can steal other users identity with this sort of attack. Commented Jan 13, 2013 at 20:23
  • Escape your strings when displaying user generated content, and do what metal_fan commented. Mainly, you need to prevent users from being able to write Javascript on the page, which is one of the biggest vulnerabilities for XSS. Commented Jan 13, 2013 at 20:24

1 Answer 1

Reset to default
1

Maaaybe, since it sounds like you're saying that only User A can see HTML submitted by User A, but you'd still have to be careful, since we're assuming that User A is aware of all data being submitting on his or her behalf. Consider the following attack.

  1. Trick User A into visiting my malicious site.
  2. Auto-submit a form to your website containing malicious HTML.
  3. Redirect User A to your website, where they will see my malicious HTML that steals their cookies and sends them to me.

Maybe you'd be okay if you implemented CSRF protection that prevents me from submitting on the user's behalf, but it's still kinda scary. If users need to be able to use HTML (but they usually don't), consider a tool like HTML Purifier that allows HTML known to be safe but blocks potentially malicious HTML: that way, most legitimate use cases would probably be satisfied, but XSS will be darn near impossible, even if the other security systems fall apart. It's easy to implement, and a small price to pay for that additional level of security.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

Thank you for your answer. In my case, User A can make a page that is visible to Visitor A, Visitor B, Visitor C, etc. However, only User A is a user with log in information (the visitors are simply visitors). To prevent the attack you described, I will be implementing HttpOnly cookies and automatic log outs after a period of inactivity. In theory, this should make CSRF attacks very difficult. Lastly, thanks for the link to HTML Purifier.
Gotcha: so there's only one privileged user? I guess that's reasonably safe… but, well, be very careful :/

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.