I came across a post on Meta SO and I’m curious about what are the subtle differences between un-encoded and encoded HTML characters, in HTML attributes, in contexts of: security, best-practice and browser support.
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I came across a post on Meta SO and I’m curious about what are the subtle differences between un-encoded and encoded HTML characters, in HTML attributes, in contexts of: security, best-practice and browser support.
HTML encoding replaces certain characters that are semantically meaningful in HTML markup, with equivalent characters that can be displayed to the user without affecting parsing the markup.
The most significant and obvious characters are <, >, &, and ” which are are replaced with
<,>,&, and", respectively. Additionally, an encoder may replace high-order characters with the equivalent HTML entity encoding, so content can be preserved and properly rendered even in the event the page is sent to the browser as ASCII.HTML attribute encoding, on the other hand, only replaces a subset of those characters that are important to prevent a string of characters from breaking the attribute of an HTML element. Specifically, you’d typically just replace “, &, and < with
",&, and<. This is because the nature of attributes, the data they contain, and how they are parsed and interpreted by a browser or HTML parser is different than how an HTML document and its elements are read.In terms of how that relates to XSS, you want to properly sanitize strings from an outside source (such as the user) so they don’t break your page, or more importantly, inject markup and script that can alter or destroy your application or affect your users’ machines (by taking advantage of browser or platform vulnerabilities).
If you want to display user-generated content in your page, you’d HTML encode the string and then display it in your markup, and everything they entered will be displayed literally without worrying XSS or broken markup.
If you needed to attach user-generated content to an element in an attribute (for example, a
tooltipon a link), you’d attribute encode to make sure the content doesn’t break the element’s markup.Could you just use the same function for HTML encoding to handle attribute encoding? Technically, yes. In the case of the meta question you linked, it sounds like they were taking HTML that was encoded and decoding it, then using that result as an attribute value, which results in encoded markup being displayed literally, if you follow.