AjaxWorld 2007 Day Two (Morning)

Day Two at AjaxWorld is off to a great start with a keynote presentation at 7:45am from Bret Taylor of Google: Scaling Ajax: The Promise and the Challenge of Modern Web Development. Bret Taylor was introduced as being the original developer of showcase Ajax web application Google Maps.

He covered a wide range of Ajax topics including....

• How Ajax has changed the way we design User Interfaces
• How Ajax has changed the way we view APIs
• APIs are simple and lightweight
• Less SOAP
• More JavaScript

• Ajax is about using and abusing standards
• DOM was designed for text docs
• XMLHttpRequest - not a standard - but supported by all browsers
• Cross-host communication using and script and iframe tag

Brent then went on to describe how Google Maps takes care of the Back Button...making the Back Button work is a common problem with Ajax application. The solution centers around the use of iFrames for soft vs. hard states. A hard-state is a display state that should be restored if the user hits the back button. For these, GoogleMaps creates a new URL for the iFrame which causes the URL to become part of the history. Soft-states are stored as textbox values within the iFrame. Browser exhibit a behavior where they like to recover the value contained in the textbox when reverting to the previous URL in history. The end-result is that the back button appears to function correctly to the user.

Drawing vector graphics in the browser was also discussed

• solution in 2005: VML in IE, line-drawing server for others
• solution in 2007: vml in IE, SVG in firefox, canvas in safari

He the went on to discuss many of the well-known problems with Ajax.

And to wrap-up, he summed up the future state of Ajax...

• Better tools and libraries
• Google web toolkit
• java to javascript compiler
• hides browser compatibliity issues
• maps ui programming concepts ( ex: constraint-based layout) to the DOM and css

• growing community and open source toolkit
• dojo toolkit -- google contributes
• prototype
• mochikit
• yahoo UI library
• Bret's predictions
• technology will be open (no one will "own" the platform)
• technology will be evolutionary (browser works pretty well already)
• technology will address an end user need (ex: rich graphics), not just a developer needs (ex: programming language features)

The 8:15am timeslot had a cool title, but the hype from the title did not live up to expectations: The User is the Killer App. Luis Derechin and his VP of Platform Engineering , Danny Malks delivered a presentation which could have sent the same message with less slides ... we are in a user-centric world. And things like Ajax make the user happy.

For 9:10am - I chose to listen to Billy Hoffman, Hacking and Exploiting Ajax Applications. Even though I was already aware of XSS and SQL Injection security issues, Billy's enthusiam to seek and destroy websites that are prone to attack was a great source of solid entertainment.

While demonstrating, Billy used this site to show various types of attacks.

• Ajax increases the attack surface. In addition to traditional threats...

• web services
• page methods
• Be aware of SQL injection risks
• especially since most dbs have functions that allow shell script stored procedures and/or direct API access
  
  

A key theme he repeated several times...Stop trusting the client

• Could call functions out of order
• could bypass form logic / validation
• information leakage - gives away information about your app
  
• function/variable names
• function parameters and return types
• program flow
• trust
• datatypes and valid ranges
• JavaScript itself
• comments with useful information
• He told a Macworld story - their registration site had md5 hash codes listed in a JavaScript array - so it was easy to figure out the codes for discounts.
  
• JavaScript obfuscation does not fully protect
  
• Be alert to XSS holes (Cross-Site Scripting). Potential malicious things that could be done...
  
• cookie theft
• session hijacking
• key logging
• screen scraping
• malicious scripts
• mousemoves

And something new for Ajax -- Ajax mashups can open new security issues when acting as bridges to other sites...

• another layer for attacker to hide beind
• theft of resources...
• dos of affiliate websites
• bypass of traditional security
• 
  

He then went on to describe a backdoor security hole in the popular Prototype library. Apparently, when Prototype sees data with a JSON header - it automatically runs it through eval...so malicious JavaScript has a way into a Prototype site. I haven't had time to experiment with this - but its worth nothing.

How can we tighten up security in our apps. Here are some of his tips:

• input validation
• client side validation is no validation
• don't use blacklisting (I will not allow these chars)
• use whitelisting (only list acceptable/known chars/formats)
• validate both data type and range/length
• validate data format
• escaping input is as good as validation
• prevent info leadkage
• no monolithic .js or .css filesin master pages
• separate ajax page method/web services from other web serivces
• turn off WSDLs for web services
• comments in JS files cannot be masked
• minimize logic pushed to the client
• minimize what is exposed by a web service
• obfuscation? not really

Useful tools

• firebug
• ie watch
• fiddler
• web developer toolbar

The final presentation of the morning I attended was a Q&A by Google which started at 11:40am. Unfortunately - I only caught a few minutes of this because I had to take a conference call at noon. But this looked like a very promising block of time -- 3 Google engineers (including Bret Taylor) up on stage in the big ballroom ready to answer any questions.

Here's a couple notes I scribbled down before I had to run off...

• Google Maps uses iFrame functionality because they wanted to harness the back-button behavior. (see my notes from the first speaker of the day)
• Google Gadgets uses XMLHttpRequest to do its Ajax transfers. And they use an Ajax proxy to get around cross-domain issues.
• A question was asked about security and gadgets. Google prefers not to be in the "security business" - and want to provide free services and not make security a barrier. If you need logins - you lose users.
  
• Google has its own internal service called dogfood where Google employees use their own products (corporate version of calendar, gmail, etc...) - "eat our own dogfood"
• Why would they choose Flex or Ajax? They design for a user experience, and then choose technology depending on what meets the requirements. Ex: Google Maps is Ajax, but their stock ticker chart is Flash.
• Why use Java in GoogleWebToolkit rather than a declarative markup like Flex/Laszlo in XML? A design philosophy of the GWT was to make it easier for Java coders (because there are a lot of them) to build Ajax apps as easily as they build AWT/Swing apps.