Weird Thoughts From Eric's Head

Tags - Categories : All | AJAX | BUSINESS | PERSONAL | PROGRAMMING | BOOK REVIEW

Ajax, XHR, JavaScript and cross domain security story

In my previous article here on my blog, I talked about how cross domain scripting was bad. Now I got emails and comments asking can I be clearer on this topic. How is this bad, what can be done, why should I de concerned as a developer or even a surfer? I put it off for awhile and thought I would make a crappy story to make a point with some crappy 5 second artwork on paint. Well I think the first place I need to start off with is spoofing of web pages.

Spoofing of a web page to get your information is so common. I see in my inbox that your ---(insert bank, shopping site, etc) account is going to be removed if you do not verify your information. You look at the link and it says something like ebay.someunknowcompanyVerificationService.com/securityApproval. Anyone stupid enough will click on the link sees the look and feel of ebay and fills out the form. By to your account information. Now this same basic principal can be applied to site.

Now anyone can do this that has a server side language. You can rip the html from the page, change the form properties and bang, a copy of the page that you want to take over. You do not even need a server side language, you can copy all of the pictures and source code and remake the page. With the XMLHttpRequest object and cross domain scripting people can also rip page content just like we can do with the server.

I can see people ripping stock quotes and weather reports from other sites that normally charge for these services. I can see people stealing other people's content easier. I can see people spoofing other sites such as eBay to steal information.

I always see people saying it sucks that JavaScript is not able to act across domains. I have a pop up window and I want to use a form and send back information. My first taught is why would you have some portion of your site in two domains? Security light bulb shines into my eyes sees two domains open up and makes me wonder how secure my information is. I really would not trust this site and close it.

Let’s say we enable cross browser scripting, what harm can it do? Lets look at an example with my stick figure Bob.

Bob is wondering if the world is made of cheese.


Bob opens up google and does a search.


He opens up a random site and sees the moon is swiss like he expected.


As he is reading the page and his girlfriend Tina calls.


Bob talks to Tina for a few hours and comes back to see gmail opened up on his computer and logs in. And that is how Bob gmail account was taken over.

Now how did Bobs account get taken over by some other user? Bob never opened up gmail in his browser, but when he came back it was open, Bob was on the phone so long he forgot about the cheese since he is in love. How did they get his password? Well it ends up that the cheese page had some code sitting there that noticed if a user was not active for an extended period of time so it opened up a framed page with gmail in one of the frames. Since cross browser scripting was enabled. The cheese page changed the properties of the form to post to the cheese server logging the username and password. After the data was recorded, the user was redirected to gmail and the rest is history in this fake story.

I know that this story may be a little far fetched but back in the early versions of UBB, the username and password were stored in clear text. A little SQL injection into any page and a person can read this clear text in the cookie and send the data to any site without the user not knowing it. The information could be attached as query string parameters and the user would just have to check some logs and get the information and be able to take over your account. This is why it is important for blogs, forums, guestbooks, etc need to check for SQL injection. Your website can be overtaken with a few lines of code and really screw up your user's security.

Now hopefully I am not freaking anyone out, but there is always this threat that people ignore when talking about cross domain JavaScript. It is not just linked to XHR as people say, but any form of JavaScript in general. If cross domain is opened up, then there has to be some big security measures in place that has to watch out for the user's behinds. People that are using JSON have to be certain that the information that that site is giving you is 100% safe. They can easily add code to do things to your site since you are opening up a new hole. Where did that banner come from? I can see people asking that in the forums.

Hopefully people do not find this explanation as weak as the other blog I talked about.

Have a safe new year.

Eric Pascarello
Coauthor of Ajax In Action
Moderator of HTML/JavaScript at www.JavaRanch.com
Author of: JavaScript: Your Visual Blueprint for Dynamic Web Pages


This is a completely incorrect and misinformed article. The page has to already encode the httprequest object in the script for it to transfer information to another page. It cannot be "hijacked" like you describe. That's just asinine.
There are many real-world commercial sites that use multiple domains for good reasons. Remember that the domain javaserver.foo.com is different than mail.foo.com. Many companies have different types of servers in different domains, host static content in a different domain, or use outside vendors to provide services. For a real example - Flickr.com holds it's millions of photos in virtual farms with URLs like farm1.flickr.com. The main website is www.flickr.com, and their public APIs are hosted at api.flickr.com. Strictly speaking, you couldn't use javascript that 'spoke' across these domains. I know there's a 'document.domain' hack - but this has it's own problems. I like the way the Macromedia Flash Player handles this. You set up a cross-domain policy file at the root of the web-server, and can set specific rules for which domains can communicate with the domain the file is in. An example I am working on is for streaming data. Stremaing is so server intensive that the data must be held on a different server than the presentation tier. Instead of using AJAX, we necessarily will have to use Adobe Flex so that we can set up a cross-domain policy.
I tried to load some webpages via an iframe. I can load a arbitrary webpage into an iframe, but I can’t access any information from this iframe for security issues. Cross-domain information exchange seems to be impossible, if I don’t have s...

Read more...


Add a comment

Title
Body
HTML : b, i, blockquote, br, p, pre, a href="", ul, ol, li
Math Quiz 8 + 7 = (Helps stop blog spam)
Name
E-mail address
Website
Remember me Yes  No 

E-mail addresses are not publicly displayed, so please only leave your e-mail address if you would like to be notified when new comments are added to this blog entry (you can opt-out later).

TrackBack to http://radio.javaranch.com/pascarello/addTrackBack.action?entry=1135962460818