Tuesday, March 20, 2007

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.

No comments: