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.)
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:
Show me your trivial regex solution to this problem and I'll show you how to break it.
Ah well. TIL not to poke FizzBuzz.
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...
Alternatives such as meta refreshes and non-JavaScript solutions are cool ways to solve this, but for POST calls it remains an issue...
You can change URL in JS without creating history entry with location.replace().
https://developer.mozilla.org/en/DOM/Manipulating_the_browse...
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."
I would have guessed that this number would be high, but definitely not in the 500's.
1) one of hundreds of equivalent syntaxes for the AST that assigns to location, and
2) location.reload()
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()?
Seems like if these 535 ways count, so should the other infinity of them.
And not even very interesting ones. window.window is window, so you can just go nuts with the chaining. So is window.self, window.top, window.frames... window.self.top.frames.location = frames.top.self.window.location? Now we're talkin'.
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?
Answer: nothing. But what would the implications be if browsers allowed it?
1. Browser based Javascript provides a location object for managing and accessing the current browser location, and this location object is available as a global variable.
2. Browser based Javascript also provides a special case in the interpreter/processer/etc., where setting the location object equal to itself will reload the current page. This is also true for certain properties of the location object (href)
3a. There is also a more conventional reload method on the location object which accepts either a location object or string href. Also, many of the "go to this URL methods" exposed to Javascript will interpret "go to the url I'm at" as a request to reload the page. Many of these methods will accepts a location object, or a string representation of a URL as a paramater.
3b. location.href is a string representation of a URL
3. There are many ways to access global variables in Javascript. There are many ways to assign a value in javascript. There are many ways to call a method in javascript.
4. All of the above can be combined into lots (likely more than the 535) of ways to achieve the same thing.
location= | combined with
location.href= |
location.assign() | location
location.replace() | location.href
-----------------------------------------
location.reload()
location === window.location === self.location
and that objects are also associative arrays:
oneObject.aMethod === oneObject['aMethod'] === oneObject['aMet' + 'hod']
you can write infinite variant of the same function call.
- Meta refresh tags could be one.
- Creating a form on-the-fly and submitting it via Javascript.