25 ms·
That such hacks are used as security measures makes me think that we've heard far from the last JavaScript exploit. Now I find that workaround sweet: but it's
by martinced 14y ago
That such hacks are used as security measures makes me think that we've heard far from the last JavaScript exploit.
Now I find that workaround sweet: but it's still a total kludge and that such kludges are used just shows how poorly security has been conceived from the ground up in browsers / JavaScript.
- tptacek 14y agoAlong the same lines, see how you feel about browser security in general after reading: http://lcamtuf.coredump.cx/postxss/ http://lcamtuf.coredump.cx/postxss/
- a3_nm 14y agoThere's a great book about browser security by the same author: _The Tangled Web_ <http://lcamtuf.coredump.cx/tangled/> http://lcamtuf.coredump.cx/tangled/>
- saturdayplace 14y agoThank you for this link. As someone just getting started in web app security this was eye-opening.
- olalonde 14y agoNote that this bug doesn't affect modern browsers AFAIK (just tested on Chrome). Firefox fixed this bug back in 2007 for instance.
- blablabla123 14y agoI agree... I mean look at JSONP, that's basically the inverse hack. After all: what's the point of enforcing same-origin-policy in AJAX but ignoring it for <script>?
- mmahemoff 14y agoThe actual reason for this is web advertising took off like wildfire, using 3rd party scripts. It was too late to reverse by the time people got concerned about the security model. Content Security Policy makes all this much more robust in modern browsers.
- dspeyer 14y agoJSONP lets the server turn off the same-origin policy. If XRFing your data is dangerous, don't use JSONP. But often we don't care about XRF, and the person writing the server is well-placed to know.