• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Ajax and Security

 
Ranch Hand
Posts: 820
IntelliJ IDE VI Editor Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have been hearing that while Ajax itself isn't insecure, you can open up some security holes if you do it wrong. Could the authors elaborate and list some Ajax security pitfalls?

Thanks.
 
author
Posts: 15385
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Since none of the authors answered this yet, I thought that I would say something since this is a rather big topic.

People think Ajax is this new big security threat. When you stand back and look at an Ajax application, you have a form submission to the server. The server has no clue what in the world it is interacting with. There is no special "Hey I am Ajax boolean" (unless you coded one in the header!)

So everything still applies with normal traditional postback model. Check for injections (SQL, JavaScript, VBScript, HTML, etc.) People say but I can see the XMLHtpRequest Object and I say I can see your form with he method, fields, and action! What is the difference. I can spoof an XMLHtttpRequest Object and I can spoof a form submission.

The last is my business logic is ou in the open. WHY did YOU put it there than? Do you put your business logic for the post back model on the client too. So what in the world changed? If security is a BIG deal, than use the client as the "visual rendering" part of the application.

I am working on a large article that covers these topics in detail. We will see if it ever reaches the light of day since I am busy as can be lately.

Eric
 
author
Posts: 25
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
As Eric stated in the previous post, there are no new security threats introduced by Ajax. As the XMLHttpRequest object (the core of AJAX) exists since 1999, we can say that the security has been around since 7 years now. And nobody has really complained about it. Some of us have used OWA (Outlook Web Access) and didn't complained about security threats. Well, OWA is using the XMLHttpRequest object and thus AJAX since the beginning.

As AJAX moves around the XMLHttpRequest, this is the only point which can introduce security threats. By default, web browsers have a very strict way to control what resources can be accessed using JavaScript. As XMLHttpRequest is a part of JavaScript it complies to these rules.

Chapter 3 of our book has a section called "Connecting to Remote Servers and JavaScript Security" that covers what I am about to say below. The threats Eric mentioned (SQL injection etc.) are handled in each example of the book.

By default, when you load a file on the client side, the JavaScript within this file obeys the rules imposed to the parent file. By default the page loaded from the server is allowed to make requests using the XMLHttpRequest object only to the original server. There are some problems related to cross-domain requests using the XMLHttpRequest. Unfortunatelly browsers handle this type of requests differently.

Here is an exercpt from the book about this topic:

"Internet Explorer is a friendly kind of web browser; which means that is arguably less secure, but more functional. It has a security model based on zones. The four zones are Internet, Local intranet, Trusted sites, and Restricted sites. Each zone has different security settings, which you can change going to Tools | Internet Options | Security. When accessing a web resource, it will be automatically assigned to one of the security zones, and the specific security options will be applied.
The default security options may vary depending on your system. By default, Internet Explorer will give full privileges to scripts loaded from a local file resource (not through a web server, not even the local web server). So if you try to load c:\ajax\... the script will run smoothly (before execution, you may be warned that the script you are loading has full privileges). If the JavaScript code was loaded through HTTP (say, http://localhost/ajax/..../ping.html), and that JavaScript code tries to make an HTTP request to another server, Internet Explorer will automatically display a confirmation box, where the user is asked to give permission for that action.
Firefox and Mozilla-based browsers have a more restrictive and more complicated security model, based on privileges. These browsers don't display a confirmation window automatically; instead, your JavaScript code must use a Mozilla specific API to ask about performing the required actions. If you are lucky the browser will display a confirmation box to the user, and depending on user's input, it will give the permission (or not) to your JavaScript code. If you aren't lucky, the Mozilla-based browser will ignore your code request completely. By default, Mozilla-based browsers will listen to privilege requests asked from local (file:///) resources, and will ignore completely requests from scripts loaded through HTTP, unless these scripts are signed (these are the default settings that can be changed manually, though). Learn more about signing scripts for Mozilla browsers at http://www.mozilla.org/projects/security/components/
signed-scripts.html."

I hope that this answer along with Eric's answer give you an idea on how AJAX is handled in security scenarios.

Best regards,
Bogdan
 
Tim McGuire
Ranch Hand
Posts: 820
IntelliJ IDE VI Editor Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the responses! The mozilla script information was very interesting.

It makes sense that the familiar web security issues apply to AJAX since all it is doing is sending more HTTP requests. Since there are more, there could be more targets that are potentially vulnerable to the same old issues, but not more issues.

My final question is:
The mozilla information you linked to about script security made me wonder if Ajax apps will ask the end user to be more and more trusting... from that page, it looks like there could be more steps of asking the end user to allow scripts to do this and that. Do you guys see a slide here into asking the end user to agree to ease up too much? Perhaps the answer is yes, but not from Ajax apps.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic