Yet another demonstration, if you needed it, on why blacklisting user input to avoid code injection is highly unlikely to succeed. There are many ways to skin a cat, and you only need to miss one.
You can also assume that the bad guys start with a list similar to this and tools to semi-randomly perturb their inputs until they find the right combo of hocus-locus to get past your filter and then "neutralized" by your regular expression magic into functioning exploit code.
(n.b. I'm talking about more interesting attacker goals than forcing a reload, obviously.)
What do you mean precisely? Normally you prevent code injection by not allowing user-supplied strings to be interpreted as JavaScript in the first place, not by trying to catch all the possible ways in which one can construct a script doing something harmful. There aren't so many ways to inject a <script> tag or something equivalent into the page.
Off-topic: Have you been hanging around tptacek a lot lately? You have suddenly started giving out security advice. A good thing, but quite noticeably different. ;-)
I've worked with Thomas (not primarily on the security side of his house), consider him a friend, and go out to dinner with him every time we're in the same time zone. That has probably increased my interest in web application security, since I nurse secret dreams of being a web pentester. (He would probably say much the same about running a primarily product business, depending on the level of seriousness we had in the conversation.)
That said, every professional engineer should understand enough about security to carry out their duties to their customers. Accordingly, I've been peripherally interested in it for years. See, among many others:
True as that may be, this doesn't really demonstrate that— it's just 535 different ways to access `location`. A regex would trivially disable every one. Of the things on that list.
I'm not saying there's a trivial regex solution to XSS, I'm saying there's a trivial regex solution to disable every one of these so-called "ways" of reloading the page: s/[\.\[=]//g will do the trick.
I mean, s/location//g will do the trick too, but I was aiming a little more generic.
In case the import of this epic retort is lost on anybody: in the real world, you have to pick and code your defense and then the attacker, who gets essentially infinite time to observe the behavior of your defenses, gets to pick their attack string(s).
Do not rely on regular expressions or blacklists to sanitize code for you. It will not end well.
...and if that were on this list of ways to reload a page in JavaScript that I'm talking about, it would be relevant here.
Look, just read what I'm saying. I swear I know what I'm talking about, and I swear I'm not saying you can reliably sanitize JavaScript with a regex. Really.
This must be like the FizzBuzz thing— programmers just can't resist a challenge, even if it is explicitly marked as not being a challenge.
See, there's another clever trick that actually does something interesting. Really, there's a whole class of toString solutions missing from this list... but I guess you have to stop at some point.
You can also assume that the bad guys start with a list similar to this and tools to semi-randomly perturb their inputs until they find the right combo of hocus-locus to get past your filter and then "neutralized" by your regular expression magic into functioning exploit code.
(n.b. I'm talking about more interesting attacker goals than forcing a reload, obviously.)