Is possible to bypass my regex and execute any JavaScript?

  function json(a){

  if (/^\s*$/.test(a) ? 0 : /^[\],:{}\s\u2028\u2029]*$/.test(a.replace(/\\["\\\/bfnrtu]/g, "@").replace(/"[^"\\\n\r\u2028\u2029\x00-\x08\x0a-\x1f]*"|true|false|null|-?\d+(?:\.\d*)?(?:[eE][+\-]?\d+)?/g, "]").replace(/(?:^|:|,)(?:[\s\u2028\u2029]*\[)+/g, ""))) 
         return eval("(" + a + ")")
    } catch (b) {}

    g(Error("Invalid JSON string: " + a))

  • I believe is impossible.
    – LucasNN
    Commented Feb 6, 2013 at 6:43
  • 8
    I hope this code isn't going into production.
    – jli
    Commented Feb 6, 2013 at 6:49
  • Good to make sure you don't fall afoul of Schneier's law in other venues. Always remember that self-reference as to impossibilities of compromise are a bad indicator for elephant detection. Commented Apr 5, 2016 at 1:03

2 Answers 2


My immediate reaction to this was not positive, for a few reasons.

  1. Trying to use regex to parse complex language constructs is a bad idea. Regular expressions just aren't suitable for such constructs.
  2. Security through blacklisting is a bad idea because you will always be, by definition, one step behind the attackers. You should use a positive security model.
  3. There are a huge number of XSS filter evasion techniques that can be used on top of standard vectors. You cannot possibly detect and block them all.
  4. Javascript parsing of JSON via eval() is considered a security vulnerability.
  5. Modern browsers have support for proper native JSON parsing, via JSON.parse() and JSON.stringify().
  6. If you have to support old browsers, there is a safe JSON library you can use that does not use eval() for decoding.

All in all, your regex approach is over-engineered, insecure, misguided, and redundant. You're attempting to solve a problem that has already been solved. Don't be a Dave. Use the proper JSON parsing functions and libraries available to you.

  • Thank you for your response. This code is used on production in a very large company. I am a security researcher and I am trying to explain why this is insecure for them. But I still believe it's impossible to exploit, if not, how?
    – LucasNN
    Commented Feb 7, 2013 at 4:08
  • 2
    The lack of a practical exploit is a technicality - if someone discovers a heap spray bug in an application, they still call it a security vulnerability even if they don't have a practical exploit. Even if we can't find a way around the regex, it doesn't mean someone else won't. Notice that Brian's answer already got partway to some valid / useful JavaScript. A determined attacker will spend hours or even days trying to break this filter, whereas we're only giving it a cursory glance. If you're doing a test or review of the code, you need to count it as a vulnerability.
    – Polynomial
    Commented Feb 7, 2013 at 11:01

this (true");alert(9);//"

is very close to a valid javascript statement and will be accepted in your regex.

Be careful with your regex, someone can bypass it.

  • I tested this, and it seems it is rejected. Which browser did you test this with?
    – Brendon
    Commented Feb 11, 2013 at 21:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .