1
votes

I'm trying to understand why do I need to use XSS library when I can merely do HtlEncode when sending data from server to client ...?

For example , here in Stackoverflow.com - the editor - all the SO tem neads to do is save the user input and display it with html encode.

This way - there will never going to be a HTML tag - which is going to be executed.

I'm probably wrong here -but can you please contradict my statement , or exaplain?

For example :

I know that IMG tag for example , can has onmouseover , onload which a user can do malicious scripts , but the IMG won't event run in the browser as IMG since it's &lt;img&gt; and not <img>

So - where is the problem ?

2
if you are encoding output that is protecting against XSS .. who says you need a XSS lib? - Marty
Need any extra info adding to my answer to help you? - SilverlightFox

2 Answers

1
votes

HTML-encoding is itself one feature an “XSS library” might provide. This can be useful when the platform doesn't have a native HTML encoder (eg scriptlet-based JSP) or the native HTML encoder is inadequate (eg not escaping quotes for use in attributes, or ]]> if you're using XHTML, or @{} if you're worried about cross-origin-stylesheet-inclusion attacks).

There might also be other encoders for other situations, for example injecting into JavaScript strings in a <script> block or URL parameters in an href attribute, which are not provided directly by the platform/templating language.

Another useful feature an XSS library could provide might be HTML sanitisation, for when you want to allow the user to input data in HTML format, but restrict which tags and attributes they use to a safe whitelist.

Another less-useful feature an XSS library could provide might be automated scanning and filtering of input for HTML-special characters. Maybe this is the kind of feature you are objecting to? Certainly trying to handle HTML-injection (an output stage issue) at the input stage is a misguided approach that security tools should not be encouraging.

1
votes

HTML encoding is only one aspect of making your output safe against XSS.

For example, if you output a string to JavaScript using this code:

<script>
  var enteredName = '<%=EnteredNameVariableFromServer %>';
</script>

You will be wanting to hex entity encode the variable for proper insertion in JavaScript, not HTML encode. Suppose the value of EnteredNameVariableFromServer is O'leary, then the rendered code when properly encoded will become:

<script>
  var enteredName = 'O\x27leary';
</script>

In this case this prevents the ' character from breaking out of the string and into the JavaScript code context, and also ensures proper treatment of the variable (HTML encoding it would result in the literal value of O&#39;leary being used in JavaScript, affecting processing and display of the value).

Side note:

Also, that's not quite true of Stack Overflow. Certain characters still have special meanings like in the <!-- language: lang-none --> tag. See this post on syntax highlighting if you're interested.