1

I was creating an XSS filter for my node plugin. Is there any way to bypass it? If yes How can i prevent it?

function xSSFilter(str) {
        return str
            .replace(/&/g, '&')
            .replace(/"/g, '"')
            .replace(/'/g, ''')
            .replace(/</g, '&lt;')
            .replace(/>/g, '&gt;');
    }
Improve this question
1
  • Non-quoted HTML: <img src=[USERINPUT] alt=[USERINPUT]/>: <img src=heh.jpg onclick=javascript:alert(document.cookie); alt=[USERINPUT]/>. Your XSS filter relies on people writing HTML code a certain way.
    – Mark Buffalo
    Apr 4, 2019 at 5:19

2 Answers 2

Reset to default
4

Output encoding is context-specific. If you're only putting the output of this function into HTML text elements - not into attributes, not into strings (or anywhere else) in a script, not into CSS, etc. - you might be OK. For now. If you're aiming for any other context, you're definitely not OK. Here are just a few (this isn't a comprehensive list, don't try to make a comprehensive list, you'll most likely fail and even if you don't the next ECMAScript or HTML update will break your magical unicorn of a viable blacklist for you).

  • You're not filtering \, which can be used to escape the legitimate string-ending ' or ". If the attacker controls another string on the same line, that string will be interpreted as code.
  • You're not filtering `, which is used to delimit template strings in JS; an attacker would be able to break out of one of those trivially.
  • You're not filtering ${ or }, which are used to create expressions for expansion within a template string; the text between them is treated as code.

Just use output encoding of everything non-alphanumeric if you want to be really safe, or at least use a whitelist of non-alphanumeric characters to not encode (and be conservative with it). If you're using the filter only for a specific context or two (say, HTML text and non-event HTML attributes), you can maybe get by with a specific "blacklist" of characters to filter, but it's riskier than going the other way.

Improve this answer
1

Yes, what you have created is called a blacklist (i.e. characters that can not be used). What you should be creating is a whitelist (i.e. characters that are allowed to be used).

Filter evasion is very common please see the OWASP Filter Evaluation Cheatsheet to see the enormous amount of ways this filter could be bypassed.

Also, as this is javascript, I assume this is just on the clients side. Client side validation should only be used to improve user experience. It should not be used for validation. Your server side script should be used for validation.

Improve this answer
5
  • OP specifically mentions Node, which is a server-side JS framework. The rest of your point stands, though.
    – CBHacking
    Apr 4, 2019 at 3:54
  • This doesn't really answer the question. While a whitelist is generally preferable to a blacklist, it doesn't necessarily mean that the system can be bypassed when a blacklist is used.
    – Sjoerd
    Apr 4, 2019 at 8:04
  • The question is not,is blacklist method sufficient or not.The question was if there is any way to bypass the blacklist op wrote.You should have provided that
    – yeah_well
    Apr 4, 2019 at 8:16
  • @Sjoerd Please see the first word of the first paragraph of my answer. This is all that is sufficient to answer the OP's question of "it possible to bypass this?". The rest of the answer is elaboration, and I did provide ways to bypass the blacklist, in the link provided.
    – meowcat
    Apr 4, 2019 at 20:46
  • I am sorry, @meowcat, I think your answer contains good advice and I wasn't out to attack you.
    – Sjoerd
    Apr 5, 2019 at 9:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.