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

JavaScript Sortable Table

Well since my last code snip about scrolling a div to the bottom was really popular, I thought that I would dust off an old script of mine and bring it out for people to play with.

People always ask how to make a table sortable with JavaScript and this code on the following link to my site allows you do it it. I will warn you that the code is not the greatest implementation to add it to the table, but it sure does a good job at sorting.

So if you are using the server to sort a simple table, you are wasting time and bandwidth when it can be done on the client.

The example and code:http://www.pascarello.com/sortTable/

Hope that helps!

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

Ajax: Where should my business logic sit?

In my recent Ajax In Action talk I gave at the Central PA code camp, I had some interesting side discussions with people about Ajax. One of the topics that seemed to come up is: "Where should my business logic sit?"

I always tell people that it needs to sit on the server and not on the client. The two points that it is based upon is speed and security. Since security is an easier topic to cover I will start there.

Now for years that I have been moderating on JavaRanch.com, one of the questions I see pop up is how can I secure my code, images, HTML markup, CSS, and so on. The real answer is anything that is rendered in a browser is basically "Open Source" since there is no way to really protect it. All of this information is "downloaded" into the cache so everyone has a copy of it. You can destroy all the formatting by eliminating returns and changing variable names, but it still can be deciphered by anyone that has time. So basically if security is very important for you, than your business logic has to be on the server. (If I see anyone saying right click scripts and no tool bars are the way to avoid this in my comments I am going to laugh. Give me 5 seconds to send you the source code.)

Now speed of execution is also a point that was brought up. Your server running server side code should be a lot faster than most people's computers running JavaScript. Get a person with 10 browser windows open, word and excel, acrobat reader, outlook, media player, and those spyware apps running and say bye to the memory and speed. Ever run a for loop with 3000 interactions? Some people's browsers choke and freeze up. This is one main reason to stick with the server for business logic is more reliability in processing information. Plus most servers are built to crunch data. Why use a browser running JavaScript that has poor memory management (unless you built your server side app. with poor memory management, but that is a different story!)

A counter argument was putting business logic before making the request limits the amount of data being sent to the server. This is true for certain applications. Look at the type ahead suggest that I wrote in Ajax In Action. We use logic to determine if we need to make the request. Do you have the correct data or should we send the XHR to the server to get more data. BUT you do not see me building my query string directly from the JavaScript opening up a big hole for any SQL injections. I have seen that with some implementations people have showed me on forums and email. Major No No! Please delete my database table!

In general you should put your business logic on the server. The clientside should be handling the displaying of the data (aka the user interface portion.) It is just like our classic postback web application. You never built querys or logic with JavaScript code and saved it in a hidden text field for the server side code to read. All of that is done behind the scenes out of the view of the people. That same idea should apply to your Ajax applications. If you are accessing databases, algorithms, etc. you need to keep this information secure on the server. Ajax or even a classic postback form can open this up to attack, so you need to always secure your data and check for the injection attacks.

Hopefully I answered some people's questions on this topic with my quick rambling. I know I did not go into any great detail or have sample code, but I am sure I got some points across.

Eric Pascarello

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

AIA News Update: Dave's interview w/ indicthreads.com

Take a look at Dave Crane's interview here: http://www.indicthreads.com/content/view/359/0/1/0/. It is a really good article that you should enjoy reading.

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

JavaScript: Scroll to Bottom of a Div

UPDATE: check out the new version here: Allow user to scroll and maintain position with "Scroll To Bottom of the Div" example

I have seen the question asked on how do I scroll a div to the bottom for my Ajax based chat/ log/ news grabber/ etc. It is rather easy to do and involves a little bit of code utilizing scrollTop and scrollHeight.

var objDiv = document.getElementById("divExample");
objDiv.scrollTop = objDiv.scrollHeight;

Been rather busy

Well I have been getting emails from people asking why I am not blogging. The reason is I am busy as can be. I just started a new job. I am trying to learn a new system, coding style, and dealing with the 495 traffic in DC. I been also preparing for my Ajax talk tomorrow in Harisburg at the Central PA .NET code camp. Plus the holidays got in the way. I should start up again real soon with comments from my talk.

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