Hacker News Reader

Comment by patio11 | Hacker News Reader

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.)

View on HN

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.

Some sites let you insert some Javascript, but try and block certain techniques (and it all goes horribly wrong for them).

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 believe patio11 did some consulting for tptacek's firm, so I imagine the answer is yes...

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:

http://news.ycombinator.com/item?id=792900

If you delete/change '<script' and '</script>' you pretty much have that covered.

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.

"Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems."

Show me your trivial regex solution to this problem and I'll show you how to break it.

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.

How about "location++"?

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.

Sorry, what does this do? In Chrome it just redirects to /NaN when you put it in the console, am I missing something?

Yeah, it causes the browser to go to a new page. += with a string probably works too, but I don't have Chrome here to test with.

eval(unescape("%64%6F%63%75%6D%65%6E%74%2E%6C%6F%63%61%74%69%6F%6E%2E%68%72%65%66%3D%27%68%74%74%70%73%3A%2F%2F%67%72%65%70%75%6C%61%72%2E%63%6F%6D%2F%27"))

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.

And thanks for the hscroll :P

hscroll? Here on Firefox 5, it wraps nicely...

Huh— I'm on Chrome 13. Just one of those things, I guess.

/me inspect element -> delete node

/me happy

Odd, that FF wraps... maybe I'll look into it later today, I kinda wonder why.

Maybe, rather use something like this: s/</</g ?

Regex this: window['loc' + 'ation']

Not to unduly humor the idea that I mean anything but the strings in that list, but my 'trivial' regex above turns that into a syntax error.

I have no idea how this has become the most controversial thing I've ever posted... It's pretty straightforward.

Ah well. TIL not to poke FizzBuzz.

Reply on news.ycombinator.com