As part of a webapp I’m building, there is an iframe that allows the currently logged in user to edit some content that will only be displayed in their own logged-in profile, or on a public page with no logged in users.
As that means the content will only be viewable to the user who entered it, or to a user on a public site, does this mean the risk of XSS is redundant? If they can only inject javascript into their own page then they can only access their own cookies yeah? And if we then display that content on a public page that has no concept of a logged in user (on a different subdomain) then there are no cookies to access, correct?
Or is my simplistic view of the dangers of XSS incorrect?
Anthony
Stealing authorization cookie information is actually not the only harm JavaScript injection can bring to other users. Redirects, form submits, annoying alerts and uncountable other bad things can happen. You should not ever trust html content provided by user, and neither display it to others.
To avoid html injection and at the same time allow users to provide html, the general idea is to have the predefined set of html tags, that can bring no harm to other users, for example some text or division paragraphs, but not unchecked images and javascript. You parse provided html and delete all but those tags.
You can use HtmlAgilityPack or any other library that can help you parse html provided by user. Than you can filter out and delete any unwanted source, and leave only safe markup.