Same Origin Policy

In reponse to my last post; Cross-Site Dom Form Element Modification here is some background via Wikipedia called the Same Origin Policy. Again, this simply doesn’t prevent attacks and the dom is still not safe. Some well informed individuals linked me to The FAQ_SOP for Google’s Web Toolkit where it states “While very necessary, this policy also has the side effect of making web developers’ lives difficult”. I agree with the latter piece of that statement, the preceding “While very necessary” is what I disagree with. So, for instance, lets say I have a form that takes one line of input, being a name. In that form input; I expect a name that can consists of numbers, letters, extended chars and symbols.

No matter what happens; that input box is hijackable. No matter where you try to prevent input into that box from a remote party; so long as it’s on the web. That specific input box is prone to attack. I don’t care what you do; deny dom access remotely; fine! Just wait for a local attack. Write stuff to a temporary cookie that is read and deleted? Attacker just has to know the cookies name and continuous poll’n. No matter what you do to try and protect the dom you can’t because of the very nature of the web. Access control mechanisms work to an extent but it just changes the vector only slightly. What would be better is a way to deny/allow access to the dom based on the HTML itself so one could deny dom access for specific elements!

After the last two days my options are fragment id’s, setting up some dns/virtual host workaround or dropping data into a temp cookie to be read on javascript event. Programming for the web sucks ass, this is horse shit! All of this to transfer one 1 line of text between forms because cwarner.dev.nymag.biz:80 and cwarner.dev.nymag.biz:8025 throw up the SOP flag.. It’s fucking stupid retarded.

Leave a Reply

You must be logged in to post a comment.