81–90 of 120 posts
FB prepends a "for(;;);" which is 1 char shorter than "while(1);", has been the case since 2012/13. Firebug v2 and ChromeTools know how to parse such JSON and ignore that first part. (IE11 and Firefox newer DevTools can't "handle" it aka show just a plain text string)
Earlier quoted context omitted.
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/
> 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.
Earlier quoted context omitted.
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/
> 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.
Earlier quoted context omitted.
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/
> 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.
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.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
8 chars is already pretty short. If you're concerned about the length, don't be. A TCP packet is at least 512 bytes.
This is definitely the sort of thing you'd want to gather data on. It's plausible that it could save Terabytes of bandwidth per day at Facebook/Google scale.
Earlier quoted context omitted.
Only if that is supported by the site being attacked. If the site only accepts httpsb connections, then the attacker would not have a way in.
If the site accepts httpsb it can as well support the Origin header [0] and the problem is solved. [0]: https://wiki.mozilla.org/Security/Origin
If the site wants to access google.com with its own cookies, fine, why not?
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.
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! ;-)
Earlier quoted context omitted.
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 :)
Earlier quoted context omitted.
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? :)