Hacker News new | comments | show | ask | jobs | submit login

Everytime I read about such constructs, it makes me realize, as a regular developer, how complex web application security is and how difficult it is to think about and cover your application against each and every such potential problem.

Note that these protections are only needed because Google supports every imaginable browser version even outdated ones. You most certainly do not need to do the same.

Array and object globals cannot be overridden now (since 2007) for literals [0] and for ambient authority problem with CORS just check the Origin header.

[0]: https://johnresig.com/blog/re-securing-json/

That would a good note to add to that StackOverflow question.

> You most certainly do not need to do the same.

... except that those browsers are still out there, so it depends heavily on how much damage someone can do by abusing the data your server can emit whether you need to do the same.

If you are browsing the web with a 10 year old browser you are opening yourself up to a ton of security bugs. Whether json responses contain a while loop or not isn't going to make a difference.

The reason Google and Facebook keep this kind of stuff around is because it's there and doesn't hurt to keep it. There's a slight chance it will provide some protection if a similar attack vector is discovered.

But aren't you saying this is an already existing attack vector then?? Why try to find a similar one if you knew you could just get an older browser version and use this one? Is that not a good enough reason to be prepared for it?

As sagethesagesage said [1], you're protecting the user from having their browser pass the user's data from your site to a malicious site. The attacker shouldn't be able to make the user run an old, vulnerable browser.

[1] https://news.ycombinator.com/item?id=14282532

It's more that people who use those browsers are being protected. It's not that those browsers can poke security holes in the site, they're just vulnerable to losing their own data.

Yup! In my personal (and basically worthless) opinion, this is why the entire "web application" ecosystem is a giant, flawed mess. It's basically what happens when a system originally designed to represent and transfer rich textual documents (HTML/HTTP) is bastardized into a application architecture.

Yes, I'm being somewhat hyperbolic. Bring on the downvotes! ;-)

This kind of criticism misses the point. The web is not designed. It is evolved. Various bits of it were designed at their outset, but it was literally impossible to envision all the implications of those design decisions.

This is not a bad thing, for the simple reason that every long-lived complex system involving many humans must behave this way.

Any attempt to top-down design the perfect, universal, distributed application runtime hits fundamental social problems not unlike those in a centrally planned economy: too much information to integrate, too many stubbornly uncooperative humans with their own divergent goals and opinions.

Systems at this scale are much more like biology than like circuit design.

Also JavaScript itself was designed to evolve in a backwards-compatible way. The way developers use JavaScript today is quite different from how they used it 10 years ago.

The idea that systems are fixed entities that have to be designed correctly up-front is wrong and is one of the reasons why the Waterfall model of software development has been superseded by Agile.

Good systems have to be designed to handle change. Change is the only constant thing in this world.

Evolution at-least has mass extinction events. Lets hope that Web 2.0, which resembles a gigantic, evolved Kraken filled with various protuberances analogous to the large intestine appendix, suffers from one sometime in the future.

It's a moot point. Very few professional web application developers would disagree with you. The problem is this is the world we live in and if you don't develop web applications in the consumer space you'll get eaten alive by your competitors who will.

It's worse than that. Because better solutions were "hard" or long-term and competing organizations couldn't agree on shared standards, they took an application and protocol designed to traverse documents, and built on complex hacks until it essentially became a pseudo-operating system, which now not only drives part of the global economy, but also changed the type and quality of information that most people receive.

So you're basically saying that the current web is a reflection of human kind, with all its flaws and quirks? :)

I like to think web browsers take the worse is better approach to security.

Security takes a back seat to reproductive fitness of the web as a platform. JS made the web insecure, but it also made it the world's premier application platform.

I blogged about this: http://kylebebak.github.io/post/browser-security-worse-is-be...

This problem isn't limited to web applications. Think about how many security problems happen on the server.

All sufficiently complex ecosystems are a giant, flawed mess.

Modern web development is already hard by itself, specially when it comes to security. A saner runtime language is needed to replace the sub par standard that is javascript. One with a robust type-system and coherent semantics. It won't fix every problem, but a least it would prevent abuses such as the one in question.

WASM (WebAssembly) is about developing a very simple cross-browser bytecode that allows implementing any runtime on top of it. The first versions are already rolling out in latest major browser versions, but at this stage you don't yet get DOM access from WASM. After the initial phase when DOM access is implemented, it's the beginning of end for JavaScript. Future browsers might well implement JS as a pre-shipped runtime targeting the internal WASM core.

Web Assembly is specifically designed not to replace JavaScript [0].

[0]: http://webassembly.org/docs/faq/#is-webassembly-trying-to-re...

I was commenting to the GP about technologies to replace JavaScript. On the long term WASM is the best candidate, though it's indeed not one of the intended goals of the project. JS will be with us eternally, rest assured. But if DOM-enabled WASM would one day gain wide adoption, developers targeting contemporary browsers of the future would at least have a wider selection of runtimes to choose form in addition to JS.

On the other hand, if you thought modern browsers are bloated, just wait for everyone to compile their runtimes on top of WASM.

It's not very hard to imagine, especially in an enteprise environment, running a browser 15-20 years from now and that browser loading the equivalent of the JVM, .NET CLR, Ruby VM, etc., on top of WASM :)

15-20 years from now, it's likely that "browser" will just be the operating system.

This actually reminds me of "es-operating-system"; an experimental operating system copyrighted by Nintendo (yes, Nintendo!), where "every system API is defined in Web IDL".

AFAIK it never went anywhere, but maybe building an entirely new OS/Browser based around WebIDL seemed less insane 10 years ago.


We'll all have gigabit connections by then. So even though it'll be 100 mb of bloat, it will still load the same as today ;)

Yes but they'll be pwned by the FCC (and friends). Don't count on it.

I can also see it happen that browsers will one day shut down plain JavaScript, only allowing WASM. Certainly if the security burden becomes too big.

That's awfully optimistic of you.

First of all browsers are committed to backwards compatibility.

Secondly, there's huge amounts of Javascript written right now, nobody's going to throw away billions of dollars worth of investments. People complain about Cobol written in the 60's, when the programmers counted in the thousands. Javacript today is written by millions of programmers.

And thirdly, Javascript evolves, as do browsers.

I can certainly see a world where WASM and JS execution pipelines in browsers converge -- where the form used for executing WASM and JS is the same.

Once WASM becomes established, I would expect JS to become "yet another runtime" on it.

That's what they have to tell to placate JS apologists.

You're basically letting strangers run code on your computer. That's basically what a "website" is. It is truly impressive to me how we can have something so complex and still manage to somehow keep it (usually) secure.

That's what "software" is, dude.

That's true, but the scale is different by orders of magnitude, and people have grown far more trusting of random websites than random software.

Can I hire you to make quips like this during meetings when people say the most obvious shit?

Indeed, there are so many traps you can fall into when writing web apps. It feels like when web was designed, security was not given due attention and efforts.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact