Tuesday, November 7th, 2006

Ajax and Security – Discuss

Category: Books, Editorial, Remoting, Security, Testing, The Ajax Experience

Often when you hear discussions regarding Ajax and security, its said that the issues remain the same as they were ten years ago: don’t trust user input, don’t expose sensitive data without encryption, code for security from day one, never display system errors messages, etc. While that is all true and good, one thing I heard from the Ajax Experience that stuck with me is that “ajax increases the typical amount of attack vectors“. We are hitting the server more often, with different transports, and often talking to remote servers as well for services. This will only become a bigger issue as cross domain ajax becomes more prevalent and libraries and tools make it easier to mash things up without having to know each individual services’ API. Do the developers you work with keep up to date on writing secure code? Have you seen your ajax app exploited by cross-site scripting attacks or sql injection, or are do you consider things “safe” because you are only doing intranet work?

With that in mind, Michel Sutton’s entry on ten common security mistakes might be a good refresher. His earlier entry on SQL injection is also worth a read, particularly if you are hand-coding sql and aren’t using a database library that handles parameterized SQL statements for you (though if thats the case you might have bigger issues…)

Recently I went looking for an authoritative book on web app security for some fun-filled weekend reading, and came up with very few hits. The closest I found was How to Break Web Software and Hacking Exposed Web Applications, Second Edition. How to Break Web Software has a bunch of good reviews and looks to be a good high level coverage of many of the common attacks. Hacking Exposed is a bit newer and has less reviews, though the first edition looked to be pretty well received. That title and cover are pretty painful, though. Is there an equivalent to the K&R C Book for web app security?

There are a ton of books on server security and locking down your OS, but not much that targets web applications specifically. Any other good suggestions? Any web security blogs worth subscribing to?

Posted by Rob Sanheim at 8:00 am

3.4 rating from 41 votes


Comments feed TrackBack URI

[…] Ajax and Security – Discuss […]

Pingback by محمد الرحيلي :: Dies For Success » Blog Archive » Ajax Ùˆ الحماية - مناقشة — November 7, 2006

There is the OWASP stuff… OWASP Guide 2.0

Comment by Dominic Mitchell — November 7, 2006

Although it always boils down to the same vulnerabilities across all webdev langauges (hence you can get a single book on attacking webapps), you’d get a pretty heavy book covering mitigating solutions for all languages. Here are some php oriented: php|architect’s “Guide to PHP Security” or O’Reilly’s “Essential PHP Security”. (my 2c…)

Comment by Halans — November 7, 2006

Here’s something interesting. In meboo.com, they return the raw JS objects from the ajax call and you will be able to see it through the FireBug plugin in Firefox.
With XHR, i guess we can escape from letting user see what we are sending and what we are receiving, but one thing that we could do, just like the old fashion web services, encrypt the god damn content. Create public key and private key even if you are using SSL.
The other thing is, if the call to the server is made through JSON (the dynamic tag), it can sort of achieve invisibleness. After the call is made, the script tag is removed. But still, encrypt the content, check user inputs, block unwanted sh** before it even gets sent out.

Comment by Simon Jia — November 7, 2006

Ajax and Security

Here’s something interesting. In meebo.com, they return the raw JS objects from the Ajax call and you will be able to see it through the FireBug plugin in Firefox.
With XHR, i guess we can escape from letting user see what we are sending and what we …

Trackback by Programming in the State of 70% Drunkeness — November 8, 2006

OWASP has an active Ajax project. We’re also working on an Ajax chapter for the Guide 3.0, and I’ve got my presentation on Ajax security for those who are interested.

Lots of security guidance:

OWASP Ajax project

OWASP Sprajax

OWASP Guide 3.0 Ajax chapter (work in progress)

My Ajax Security presentation

Ajax security issues are mostly old issues updated. There are remarkably few new ones, primarily new forms of injection (JSON, DOM, and so on), and plus XSS takes on a particularly sinister overtone – so don’t have XSS on your Ajax app.

In general,

* any toolkit stating that it is 100% client side is 100% insecure
* Toolkits which do not offer methods to encode data to prevent XSS are insecure
* Toolkits which go out of their way to violate cross-domain XHR restrictions are most likely going to be used in insecure ways

There is nothing particularly difficult about writing secure Ajax code, it’s just that there’s so little easily found guidance out there.

Sam Buchanan and I are writing an Ajax Security book, with No Starch Press. It should be out in early 2007.

Hope this helps,

Comment by Andrew van der Stock — November 8, 2006


I would like to introduce you to a new concept http://www.visualwebgui.com which eliminates most of AJAX soft spots by simply returning back to server based computing but still having a dynamic AJAX based UI.


Comment by Guy — April 9, 2007

AJAX security

System administrators had long been using a security mechanism that I believe should be used in AJAX applications as well. If we could not utilized business logic, data or services consumption from out AJAX clients you would have nothing to protect from hijacking. If you are asking you self how it can be done in AJAX applications? You can find here http://www.visualwebgui.com one way of achieving it. The last is an AJAX framework that provides server based computing concept for implementing enterprise AJAX applications

Comment by navot — April 16, 2007

I’ve got a comment… ;)



Comment by Thomas Hansen — September 18, 2007

Leave a comment

You must be logged in to post a comment.