15

There is a Node.js project that sanitizes data and there is an OWASP library for JavaScript that handles sanitization to prevent XSS.

I have been benchmarking these libraries, and they are pretty intensive and maybe an overkill, my application does not need any dynamic HTML (submitted by users, bbtags or what ever, not required at all) so why not do it like this:

  1. Disable "<" and ">" characters, don't replace them or anything, just disable them, if the user submits these, give them a warning that these are disabled (client- and server-side validation)
  2. & => &amp;
  3. " => &quot;
  4. ' => &#x27;
  5. / => /
  6. Encode submitted URLs (GET parameters etc.)
  7. DOM based XSS is covered since my application uses HTML5 PushState and the backend is fully separated from the frontend.

Would this be enough to protect myself, as I said, my application does not require any HTML submitted by users, so I don't need the < and > tags at all.

Thanks for all the feedback, this is what I use right now:

var pattern = /<(.*)>/;

function hasHtmlTags(string) {
    return pattern.test(string);
};

if (hasHtmlTags(userData)) {
    // Do something?
} else {
    // Create entity.
}

So users can still use their emoticons :< and such, and the function only gets triggered if a combination of < and > is found. So no expensive regular expressions and such, just disable < and > in combination and we should be fine.

onlineracoon
  • 2,932
  • 5
  • 47
  • 66
  • I see, but users don't use it that offen, and if they do they are not essential. So I figured, why not spare the overkill and disable them. – onlineracoon Oct 09 '12 at 12:02
  • It should be sufficient, [as long as you specify your character encoding](https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet#UTF-7_encoding). – user2428118 Oct 09 '12 at 12:13

4 Answers4

12

Here is a general encode procedure:

var lt = /</g, 
    gt = />/g, 
    ap = /'/g, 
    ic = /"/g;
value = value.toString().replace(lt, "&lt;").replace(gt, "&gt;").replace(ap, "&#39;").replace(ic, "&#34;");

If your user doesn't submit anything to your server you don't even need the above. If the user submits and you are using the user input then the above should be safe. As long as the '<' and '>' are globally sanitized and the parenthesis also are you are good to go.

Konstantin Dinev
  • 34,219
  • 14
  • 75
  • 100
  • The user does submit stuff to the server, just no '<' and '>' characters. If sanitizing them would be the solution, why is there a whole OWASP cheatsheet? https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet – onlineracoon Oct 09 '12 at 12:13
  • 1
    @onlineracoon — See [this section](https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#Why_Can.27t_I_Just_HTML_Entity_Encode_Untrusted_Data.3F) of the cheatsheet – Quentin Oct 09 '12 at 12:15
  • 2
    The owasp cheatsheet covers all possible scenarios for XSS. If you are not outputting data within tags' definitions (not content) or within script tags, then you can omit a whole lot of it. – Konstantin Dinev Oct 09 '12 at 12:23
  • @KonstantinD-Infragistics I updated my answer, please review it. – onlineracoon Oct 09 '12 at 13:42
  • 1
    @onlineracoon You should be fine with what you have. – Konstantin Dinev Oct 09 '12 at 13:45
7

why not use encodeURIComponent before sending the data to the client?

var string="<script>...</script>";
string=encodeURIComponent(string); // %3Cscript%3E...%3C/script%3
user2428118
  • 7,935
  • 4
  • 45
  • 72
japrescott
  • 4,736
  • 3
  • 25
  • 37
  • 1
    [escape is deprecated](https://developer.mozilla.org/en-US/docs/JavaScript/Guide/Functions?redirectlocale=en-US&redirectslug=Core_JavaScript_1.5_Guide%2FFunctions#escape_and_unescape_functions) too – Quentin Oct 09 '12 at 12:12
  • `+1` to set things straight. if the answer is not **wrong**, there is no reason to downvote. if there are better answers, they will be upvoted. – RASG Oct 09 '12 at 12:27
  • 4
    The answer is wrong. If someone enters ``, they do not expect it to be rendered as `%3Cscript%3E...%3C/script%3`. It mangles special characters into line noise. You could prevent XSS by discarding absolutely all input, that doesn't make it a solution to the problem. – Quentin Oct 09 '12 at 12:31
  • 1
    Thanks @RASG! @Quentin; Yes, if you have an inline editor, that will be the case. But thats not onlineracoon's question. Its about XSS. Therefor he wants to prevent userA writing scripts that execute on userB. If he uses encodeURI when sending HTML to userB it will be "ugly" yes, but UserB will see it as . Same as if you'd replace them with html entities as the accepted answer proposes. And good joke about "discarding all input". He also could shutdown his website to prevent XSS ;) – japrescott Oct 09 '12 at 12:51
  • This method also encodes "space" " " which is harmless and not required. eg: `monday 10` becomes `monday%2010` – rahil471 Apr 09 '19 at 06:51
  • 1
    @rahil471 that is besides the point as the user will see it as `monday 10` even when the data itself looks weird. – japrescott Apr 10 '19 at 10:34
7

Considering https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html

Here is an implementation of their recommendations :

function escapeOutput(toOutput){
    return toOutput.replace(/\&/g, '&amp;')
        .replace(/\</g, '&lt;')
        .replace(/\>/g, '&gt;')
        .replace(/\"/g, '&quot;')
        .replace(/\'/g, '&#x27;')
        .replace(/\//g, '&#x2F;');
}

Also make sure you use this function only when necessary or you might break some stuff.

But I suggest you to take a look at already made libraries for sanitizing output :

https://github.com/ecto/bleach

Matthias
  • 13,607
  • 9
  • 44
  • 60
Hybris95
  • 2,286
  • 2
  • 16
  • 33
0

You can use a function like

 function htmlEncode(str){
  return String(str).replace(/[^\w. ]/gi, function(c){
     return '&#'+c.charCodeAt(0)+';';
  });
}

You would then use this function as follows:

<script>document.body.innerHTML = htmlEncode(untrustedValue)</script>

If your input is inside a JavaScript string, you need an encoder that performs Unicode escaping. Here is a sample Unicode-encoder:

function jsEscape(str){
  return String(str).replace(/[^\w. ]/gi, function(c){
     return '\\u'+('0000'+c.charCodeAt(0).toString(16)).slice(-4);
  });

}

You would then use this function as follows:

<script>document.write('<script>x="'+jsEscape(untrustedValue)+'";<\/script>')</script> 

More info: https://portswigger.net/web-security/cross-site-scripting/preventing

Ahmad
  • 507
  • 1
  • 11
  • 22