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.<p>You can also assume that the bad guys start with a list similar to this <i>and</i> 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.<p>(n.b. I'm talking about more interesting attacker goals than forcing a reload, obviously.)
I was hoping for a bit more cleverness... that's (at least very nearly) just a combination of:<p><pre><code> location= | combined with
location.href= |
location.assign() | location
location.replace() | location.href
-----------------------------------------
location.reload()
</code></pre>
and things that mean exactly the same thing. As others here have pointed out, why no meta tags? Form submissions? Surely there's another way or two as well. The lack of creativity in this list is rather astonishing - if it were sorted, it'd be merely annoying because of the blatant repetition.
I really see only two ways here:<p>1) one of hundreds of equivalent syntaxes for the AST that assigns to location, and<p>2) location.reload()<p>So if we're going to play this game and these count as different, why not encode the identifiers in hex notation? Or replace the identifiers with lambda calls to compute them? Or eval()?<p>Seems like if these 535 ways count, so should the other infinity of them.
Interesting to see so many ways to do it, but what's missing is explanations of pros and cons of the different approaches (though I'm sure there probably aren't many differences). Why not just stick with one then?
Is there any way which doesn't break the back navigation button (since upon pressing back the JavaScript statement will execute again, causing an immediate change of location and jumping forward again in the history)?<p>I thought about checking whether history.forward is empty as a condition for changing the location, but I don't think you're allowed to do that check...<p>Alternatives such as meta refreshes and non-JavaScript solutions are cool ways to solve this, but for POST calls it remains an issue...
Several years back I was on a job where the boss wanted to allow virtually any user-provided HTML/CSS/JS in a content area, while preventing redirects.<p>No implementation ever happened of course, but my first thought was, what would happen if we did a "<script>delete(window.location);</script>" near the top of the template?<p>Answer: nothing. But what would the implications be if browsers allowed it?
Given that "window" is the top level object in JavaScript:<p>location === window.location === self.location<p>and that objects are also associative arrays:<p>oneObject.aMethod === oneObject['aMethod'] === oneObject['aMet' + 'hod']<p>you can write infinite variant of the same function call.
There's a whole lot more of these actually. Here are a couple off the top of my head:<p><pre><code> - Meta refresh tags could be one.
- Creating a form on-the-fly and submitting it via Javascript.</code></pre>
From <a href="http://ycombinator.com/newsguidelines.html" rel="nofollow">http://ycombinator.com/newsguidelines.html</a>:<p>If the original title begins with a number or number + gratuitous adjective, we'd appreciate it if you'd crop it. E.g. translate "10 Ways To Do X" to "How To Do X," and "14 Amazing Ys" to "Ys." Exception: when the number is meaningful, e.g. "The 5 Platonic Solids."