afongen

When last I wrote, I was busy working on a few talks. They went reasonably well.

MinneWebCon was a lot of fun, an engaging, upbeat conference. There were almost 250 attendees, about two-thirds of which were from the University of Minnesota, which put on the conference. Eric Meyer delivered a keynote in which he discussed craftsmanship in the web professional. How very relevant. Amy Kristin Sanders’s midday keynote offered useful insights about internet law that I cannot do justice to. In Mark Heiman’s enchantingly engaging talk about the search for a social networking tool for Carleton College alumni, I learned about Elgg, an open source social networking platform that looks pretty damn good. I’ll have to take a closer look.

The smartest bit of scheduling was to put unconference sessions immediately after lunch. Rather than nodding off on a full stomach, we got engaged in animated discussion, keeping energy high for the afternoon. Brilliant. The social networking session largely highlighted Twitter, which fit in well with the active back-channel Twitter chatter going on. Tony Thomas wrote a little about that.

My own presentation on JavaScript went almost as well as I hoped, although I ended up not being able to touch on Ajax except immediately afterward in a quick response to a question as I was unplugging from the projector. My emphasis was on taking functional pages and layering helpful behaviors onto them with unobtrusive JavaScript. Video will be available at some point, and I’ll be making my presentation notes available here (and there) soon.

And by the way: in case you didn’t know, jQuery is fantastic.

Many thanks to the MinnWebCon organizers for putting on a great conference and for allowing me to participate. I’m looking forward to next year.

Unfortunately, I was having so much fun preparing for my MinneWebCon talk that I gave short shrift to prepping for the two presentations I had scheduled at the MnSCU IT conference this past week. Thankfully I deliberately chose topics on which I could speak extemporaneously if need be. They turned out okay, but (as always) not as good as I had hoped. My first session explored the limits we’re bumping into with Ajax, especially user interface challenges, nontrivial client-server data communication problems, and the fallacies of distributed computing — setting the stage for the emergence of rich internet application technologies like Flex, AIR, and Silverlight. None of these technologies actually solve the problems, except making it easier to create better-looking UIs, but they should be watched closely. Hell, I’d use Flex in a heartbeat for certain things like, oh, an ERP.

I also spent a few minutes pointing toward all the activity going on around programming languages, concurrency, and flexible approaches to databases (non-relational, sharding, etc.), all related to rising expectations of what software should be able to do and how quickly we should be able to create said software. I talk about this stuff all the time, but hardly anyone seems to believe me. I hope that I at least planted a seed or two that will bear fruit in future discussion, and was heartened upon my return from the conference to see Tim Bray take it up:

Near as I can tell, we’re simultaneously at inflection points in programming languages and databases and network programming and processor architectures and Web development and IT business models and desktop environments. Did I miss anything? What’s bigger news is that we might be inflection-point mode pretty steadily for the next few years.

I don’t know whether I’ll put together notes. I suppose I ought to.

I was a little worried about the session on software security principles, since I had completely changed course on what I wanted to do the night before, but it turned out to go quite well. I wanted to start a discussion, examining common software development scenarios where I often find vulnerabilities, letting the group identify security principles that should guide development. WIth the help of a few security-minded individuals and a lot of people not afraid to put themselves out there even when they weren’t sure of themselves, we did just that. It was a good, active conversation. I was a concerned that one guy who brought up a quite valid point — that by moving our ERP from Win32 client-server to a web application, we’ve increased exposure and risk — was discouraged by the response. I talked with him today, though, and found that he wasn’t at all discouraged and that he had learned what I wanted people to learn:

• the threat is no longer amateur;
• software is rarely designed with security in mind, and that’s where the attacks are taking place;
• there are core principles that should help guide software design and development, such as not trusting input, using least privilege, and so on.

For people like him for whom this is all new, next time I will prepare handouts. If you’re looking for a preview or something to use now, I suggest you start with the excellent resources from the Microsoft patterns and practices group, including Guidance Share. It is not all Microsoft-specific, and there are some real treasures. For a quick run-down of security principles, see this blog entry by J.D. Meier, which lays them out nicely against Microsoft’s security frame.

To my mind, the highlight of the conference was Mike Janke‘s whirlwind tour of the MnSCU network and data centers. We really need to see more of that. Watching his presentation leaves no question of the scale and complexity of the problems of doing IT for an organization the size of ours, and the tremendous job that Mike and his team have done.

The real conference is of course not the sessions but the connections made with people there. Many good conversations were had, but I still didn’t connect with everyone I had hoped to. Folks, you know who you are. Let’s not wait until next year, okay?

Whew! My conference season is pretty much over, so excuse me while I go tackle that growing stack of books.

I’m busy preparing for three talks that I’ll be giving in April.

The first will be at MinneWebCon, a web conference at the University of Minnesota.This is their first time putting on this conference, and even were I not speaking at it I would probably attend. The sessions on user experience, social networking, and online video look interesting, and I read today that there will be unconference sessions, too. My talk will be an introduction to JavaScript. The MinneWebCon organizers don’t expect the audience to be hardcore developers — a glance at the sessions makes that clear — so I’m keeping it basic but still trying to make it useful and get across important ideas. I always try to stress a few concepts whenever I talk about JavaScript:

• The importance of unobtrusive JavaScript — playing nicely with web standards and writing JavaScript that injects itself into a page to layer on behavior.
• JavaScript is not a toy language. It’s frequently dismissed as a cute little trinket, but its importance in web apps nowadays argues that although it has its warts, it has a certain quiet strength. I deal with a lot of Java developers who eschew JavaScript as “nothing like Java” but who then make the mistake of writing JavaScript code as if it were Java Lite. JavaScript is not a less powerful Java: it is best used on its own terms.
• Security. JavaScript is so ubiquitous and it is so easy to make security mistakes, I would be remiss not to discuss security. Especially since I’ll be bringing in a little Ajax.

We’ll be looking at JavaScript from the perspective of introducing basic enhancements to page behavior, illustrating those three concepts along the way. In an hour can’t get too deeply into JavaScript syntax, especially for non-programmers, but I will be showing how to leverage libraries, especially jQuery.

The next two sessions will be at the annual IT conference for Minnesota State Colleges and Universities. (There’s not a good link right now, sigh.) This is a gathering of IT staff from our colleges across the state, staff development, networking, and so on.

The first session is on software security principles. In the years that I’ve been working with developers on software security — coaching, training, giving talks at conferences like this — I’ve focused a lot on common flaws and vulnerabilities: how to test for them, how to prevent them through early design analysis and development techniques. It’s become clear, though, that there’s something fundamental missing. Understanding of vulnerabilities and their exploits is incomplete unless a developer also understands basic principles of software security. Until a developer — or architect, or project manager — has a foundation in the core principles that guide secure software development, they are likely to make the same sorts of mistakes that lead to security problems, even if specific vulnerabilities are planned for.

Basically, I don’t want to keep finding myself in arguments about whether or not it’s worth doing input validation. So I’ll cover principles like “input is evil,” least privilege, defense in depth, secure failure, that sort of thing. Since an hour of theoretical mumbo-jumbo isn’t likely to do anything except put people to sleep, I’ll be sure to explore how these principles play out in the software development process, and how common vulnerabilities such as the OWASP Top Ten can be addressed by keeping the principles in mind.

Yeah, I get a little ambitious.

My second session at the MnSCU IT conference is called “Beyond Ajax.” When I first conceived of the talk, it was more along the lines of “Why Your Software Sucks.” (I had an angry few months, what can I say?) It then morphed into an exploration of rich internet application technologies starting to rise to the fore: Flex, AIR, Silverlight, even JavaFX. Then, thinking about the two sessions that I’ve outlined above, I realized that I didn’t have enough time to learn Flex and Silverlight well enough to do a kick-ass presentation. Besides, for an audience that for the most part is maybe just now getting into Ajax development, I need to develop more background of what’s driving the adoption of non-Ajax RIAs.

So instead, the talk will be about why creating a well-designed Ajax app has proven difficult or unsatisfying:

• We’re still stuck with the limitations of browser user interfaces.
• Writing cross-browser code is still hard.
• Creating compelling cross-browser UIs is even harder.
• Many developers don’t understand JavaScript like they should.
• Security has grown more complex.
• Ajax accessibility is still largely unknown and misunderstood.
• Although the client-side part of an app can now do more (and be more complex!), without a lot of work application workflows have not changed much and are still hampered by HTTP.
• Architecture of data flow between client and server is a significant challenge, often falling victim to the fallacies of distributed computing and resulting in a degraded user experience.
• There is a strong inclination to use Ajax to create non-browserlike experiences, often to the detriment of the user.

I don’t know yet whether I’ll bring mobile devices into the picture.

Into this setting come Flex, AIR, Silverlight, and so on. I can’t get too deeply into them, much as I’d like to. Still, the focus of the talk is on rich internet apps — mostly why, not so much how. Look for that next year. :)

I also hope to spend a few minutes (lightning talk style?) discussing parallel industry trends that will have impact on in RIA development in the near future: cloud computing, approaches to concurrency, non-relational data stores, and a panoply of new languages and platforms to address these concerns. This is all stuff that’s been rolling around in my head for the last year or two, and I’m tempted by a bit of self-indulgent examination of how it’s all connected.

Like I said: I get a little ambitious. That last bit is likely to get cut as not contributing to the core message.

So if you don’t hear from me for the next month or so, know that I am busy. But I am having fun.

For a while, we used Prototype at work. My choice. I was familiar with it from Ruby on Rails, script.aculo.us had effects I wanted to work with, and Dojo wasn’t quite ready yet (and was overkill for our needs). When Yahoo! released YUI, it did not take long for me to switch. Yahoo!’s attitude toward accessibility and toward graded browser support is much more in line with my philosophy. And by “in line with” I mean “identical.” Throw in thorough documentation and I’m sold. We still have discussions about framework choices, as the space changes a lot and different projects have different needs, but let’s save topic that for another day.

What I do miss from Prototype is the little bits of syntactic sugar sprinkled throughout. I could write this:

Event.observe('myLink', 'click', doSomething)

but it feels a whole lot more natural to write this:

$('myLink').observe('click', doSomething)

Instead of registering an event handler with some great EventHandlerManager in the sky, which is what the first bit of code feels like, I’m instead asking an object to observe itself and do something if an event happens. Technically that’s not necessarily what happens, but that’s what syntactic sugar is all about. I shouldn’t always have to care what really happens.

(I should confess here that I diverge from the mainstream in my funny ideas about object-oriented programming. I have been heavily influenced by David West’s Object Thinking, which hearkens back to OOP as it originally emerged, not as it was co-opted by procedural programmers who didn’t quite get it. I also readily accept that there are different ways of doing OOP “right.” Again, that’s a topic for another day.)

YUI doesn’t have any such nifty syntax.

YAHOO.Event.addListener('myLink', 'click', doSomething)

That’s what you’ve got. Okay, there are aliases:

YAHOO.Event.on('myLink', 'click', doSomething)

There are optional parameters let you easily pass an object as parameters to the callback, and redefine the scope of this inside that handler:

YAHOO.Event.addListener('myLink', 'click', doSomething, obj, override)

These are small touches that make a difference and that reinforce my pleasure in using YUI. But still, after a while the syntax feels stilted. Unnatural. Reading the code that I’m seeing turn up in some of our projects, including my own, I can see the code growing out of control. It’s easy to build up convoluted and verbose code that just does not make sense. It’s not YUI’s fault, but in the hands of someone who doesn’t understand the language, it’s not pretty.

Today, inspired by Adam McCrea’s JavaScript metaprogramming presentation, I took some code that was quickly becoming ugly and hard to follow, and turned it into a little domain specific language.

toggle(checkboxes).when('myLink').is('clicked')

I work with a bunch of people who hate JavaScript, mostly because they misunderstand it and dismiss it as a toy. Every time I write JavaScript, I’m delivering my coworkers code that not only will be used as a model, but that reflects on the language itself. If my code is inelegant, JavaScript looks bad. Worse than it deserves, anyway. :)

Today’s work feels good. Not only should it be really, really clear how to use the above code, all the code behind it is much more cleanly designed, and uses YUI to good advantage. It’s been a good day.

Java SE 6 was released last week. How many of us are now running 2 major versions behind? :)

There are a few goodies in this release, including performance gains and better debugging and monitoring, but the one I’ve been waiting for is JSR 223, explicit support for “scripting” languages. I first got excited about this JSR when it seemed that the reference implementation would be PHP. At the time I did most of my work in PHP, and I was excited about bridging the languages. Instead Java 6 ships with Rhino, a JavaScript interpreter written in Java, but that’s just fine if not better. There’s a longer list at scripting.dev.java.net anyway, including PHP on the JVM.

Why does this matter? I believe that the future of Java is not so much Java-the-language as Java-the-platform. I have felt this from the day I first encountered Jython (four years ago already?). Encounters since then with JRuby, Rhino, and Scala have only made my convictions firmer. Recent actions from Sun (and the JCP) lead me to believe that more than a few people there there recognize that if the JVM is one of Java’s core strengths, then the Java platform has a future somewhat distinct from the language. Sun hired two lead JRuby developers (locals Charles Nutter and Thomas Enebo). With JSR 223 and now JSR 292 (“Supporting Dynamically Typed Languages on the Java Platform”), which I believe we can expect in Java 7, it will be taken a significant step further. As Danny Coward points out in a recent interview, JSR 292 introduces the first bytecode in the JVM that is not used by Java. To me, this is a fairly clear endorsement of non-Java languages as part of a broader Java platform.

Microsoft is doing the same thing, by the way. Sure, much was made of multiple languages running on the .NET Common Language Runtime when it was first announced, but I have the distinct impression that C# is very much the canonical language for .NET development. But a few things have happened in the past year that tell me this is changing: Microsoft hired Jim Hugunin, lead developer of IronPython, a Python implementation for .NET (Hugunin is also the creator of Jython), then released IronPython for ASP.NET They’ve also been working with Zend to make the PHP experience better on IIS, including writing FastCGI for IIS 7.

I’m kind of surprised that I haven’t written about this more here. I think I’ve avoided it because it seems so damn obvious. But it isn’t, not really. It may be obvious within the areas of the blogosphere where I spend time and in the local Ruby community. But in the real world of day-to-day Java development to which I subject myself, in which most are unaware even that Sun has open sourced Java (it’s a culture thing), much less that Java 6 has been released and what it includes, talk of languages other than Java is very strange and uncomfortable news. I still get polite nods and bemused or uncomprehending looks. Daily.

It also occurs to me that there are readers of this blog who do not live immersed in the world of Java and who have valid reasons for being unaware of recent events. :-)

A quick note. I put “scripting” in quotes above because labelling languages like Ruby and Python as “scripting languages” is unfair and indicative of the historically dismissive attitude that some programmers have held toward them. To sound au courant, you should know that the currently favored term is “dynamic” or “dynamically typed” to distinguish them from statically typed, early binding languages like Java. The wrinkle is that in JSR 223, those languages are used for scripting, playing second fiddle to Java. JSR 292 shifts this balance.

So there. Nothing earth-shattering, but now at least maybe you understand why I talk about JRuby a lot.

In all my excitement about the return of the Perl Advent Calendar, and the LugRadio Advent Calendar (!), I completely forgot to check to see whether there would be a new 24 Ways this year. There is, chock full of all your web design goodness this advent season. Entries from the likes of Drew McLellan, Andy Budd, Rachel Andrew, Christian Heilmann… go check it out. (via)

Not enough good things can be said about this. Joe Hewitt has released a public beta of Firebug 1.0 and announced that it will continue to be open source. Any donations he gets are well deserved. Firebug is amazing, and 1.0 just blows me away. It is an invaluable part of a web developer’s toolkit.

The network monitoring is a nice enough addition, because who doesn’t want to know more about how long files/pages take to download? But it goes one step further.

Hover over one of the lines to get not just the fully qualified URL for the request, but if the request is for an image, Firebug also displays any images requested, scaling them to thumbnails if necessary. A small touch that really makes a difference.

JavaScript debugging is better than ever. Conditional breakpoints (“break only if the variable has this value”), profiling… very nice indeed. HTML and CSS inspection and manipulation, Firebug Lite for using a Firebug console in browsers other thank Firefox… heaven.

I’m still putting it through its paces, but already the new version saved me a lot of time today during a big bug stomping session. Go get Firebug now.

Google Maps is cool, sure, but last night I saw Google Maps Mobile. That is impressive.

I had lunch with Gary and Matt the other day. After politely reminding me that I hadn’t blogged at all lately (it seems del.icio.us doesn’t count), they listened to me blather on about what’s been occupying my thoughts and time lately, especially 1) JavaScript malware, and 2) dynamic languages in thhe JVM and CLR. Thanks, guys. Once I get started on a topic I can be hard to shut up, so I appreciate your patience. Here’s that blog post you asked for.

So. JavaScript malware? Three presentations at Black Hat caught my attention.

1. Jeremiah Grossman and T.C Niedzialkowski on Intranet hacking wiith JavaScript malware.
2. Billy Hoffman’s “Analysis of Web Application Worms and Viruses” (PDF slides). Shortly before Black Hat, SPI Dynamics (where Hoffman works) released a paper and proof of concept code on “Detecting, Analyzing, and Exploiting Intranet Applications using JavaScript Malware.”
3. Tom Ptacek and Dave Goldsmith, “Do Enterprise Management Applications Dream of Electric Sheep?” If enterprise agents don’t make you nervous yet, they will.

The first two talks explore different aspects of what Grossman is calling JavaScript malware. The upshot is that cross-site scripting is much, much worse than we had ever thought — “the new buffer overflow” — and opens the door to internal network scanning, JavaScript worms and viruses, and all sorts of other excitement.

This is bad enough, but taken as a backdrop to the Matasano presentation on attacks behind the firewall — ridiculously insecure enterprise management agents — it’s terrifying enough to send me whimpering into a corner.

Subsequent work has made it even worse. JavaScript is everywhere, and its environmental restrictions vary. PDF, QuickTime, MP3 (!), Flash, RSS feeds… dang. The outlook is not good. From a recent email exchange in which I responded to an assertion that PDFs don’t yet have the ability to transmit worms/viruses:

Because PDFs can run JavaScript, whether they can themselves transmit worms/viruses isn’t terribly important. PDFs can make web services calls over HTTP & HTTPS, they can connect to databases, they can retrieve and play backdoored media files like Quicktime and Flash (QT can run JavaScript, btw), they can cause a web browser to launch and make arbitrary HTTP requests. With JavaScript (in the browser, at least), I can scan an internal network, probing and fingerprinting network devices (or intranet sites) use them as a launching pad for a more devious attack. Is that printer vulnerable? Quite possibly. Does that router have a web interface? Ooh, that’s interesting. Does that intranet portal have XSS vulnerabilities that can help me transmit a JavaScript worm? Quite probably.

The usual network admin concern with perimeter security is insufficient. The likelihood of running across cross-site scripting over the course of a day of surfing is pretty high; cross-site request forgeries are likely everywhere. They can blast undetected right through your network perimeter and tackle all the fun stuff on the inside. Even trusted web sites are not safe, and the consequences are getting worse every day. Remember: script kiddies are not the danger anymore. The real threat is well-trained and funded crime syndicates motivated by scads of cash.

I’m barely scratching the surface but wanted to give you at least some idea of what’s been banging around in my head. Read Jeremiah Grossman, RSnake, pdp (architect) to start if you’re interested in studying up.

Today I pick up from part 1 and discuss one of the challenges in Ajax security: attack surface.

Attack surface describes the points of entry that an attacker can abuse to compromise our application. When writing software with security in mind, we try to minimize attack surface to reduce the likelihood and the impact of successful attacks.

One straightforward way to reduce attack surface is to remove features that are not used or that pose too great a risk. If the code isn’t there, it can’t run so cannot be exploited. Another technique is to reduce the number and complexity of exposed entry points. In web applications, the most obvious entry point is the HTTP interface. This is where Ajax comes in.

Ajax & Attack Surface

Almost by definition, Ajax applications have an larger attack surface than their non-Ajax counterparts. The reason is simple: there are more server-side services exposed — i.e. more URLs. URLs are web applications’ exposed APIs, and Ajax apps make more of them available to end users.

Why? Ajax code needs to talk to something on the server, and usually that means exposing an additional functional URL. Take Google Suggest for an example. As you type in the search box, your browser is making HTTP requests behind the scenes to http://www.google.com/complete/search (I’ve left off query parameters). When you submit the form, it goes to http://www.google.com/search as usual. So to introduce an Ajax feature, Google has exposed an additional entry point to their application(s).

Let’s use a more detailed example from an app that I’m working on, a course search. It’s simple enough, really, there are three basic pages: a form where students enter search criteria, a search results page, and a course detail page for each of the results. The URLs (minus query parameters) might look something like this:

/search/
/search/results
/search/detail

To be clear, I should add some reasonable query parameters:

/search/
/search/results?subj=english
/search/detail?courseid=34512

There are lots of ways we can introduce Ajax to these three pages that make it a little bit easier for the student to use. One is to remove the extra step of looking at course details on a new page. When a student clicks on a course title to get detail, instead of following the link to /search/detail, fire off an Ajax request to get the details and display them in situ, right on the results page. That way the student doesn’t have to keep going back and forth between search results and course detail, and can more quickly find course that interests her.

Here’s the question we face: what is the URL the Ajax code’s HTTP request? A few possibilities:

1. /search/detail?courseid=34512. The problem here is that normally the response to this request will be an entire HTML page, complete with page headers, footers, navigation, etc. We don’t want all that stuff, we just want the course detail. This will not work.
2. Same URL as the first option, but with an additional HTTP header that indicates that this is an Ajax request. The server-side code looks for this header and responds accordingly. Prototype adds a custom header X-Requested-With: XMLHttpRequest, which is great but if you ever move away from Prototype you’ll either need to adjust your JavaScript to add the same header or change your server-side code to look for something new. Not necessarily an onerous task, but it’s worth considering.
3. /search/detail?courseid=34512&output=json. Here we’ve added a query parameter to tell the app to respond with JSON instead of a complete HTML page. Yahoo! does this for their REST web services. We could just as well have added output=xml our output=html to get XML or just the HTML to add directly to the DOM. This isn’t too bad a way to go, but we’ll want to find a way to avoid repeating the code that looks for the output parameter.
4. /search/detail-ajax?courseid=34512. Use a different page name entirely. This way it’s easy to spot what’s going on, but it seems a little clumsy, especially as you add more Ajax-responding URLs. If you’re using a framework like Struts & Tiles, this is probably the easiest way to go, because you can point to the same Action but use a different set of Tiles for the output. On the other hand, your config file can quickly get pretty large.

If you choose option 3 or 4 (especially 4), you’re introducing new URLs to your app, thereby creating new points of entry and increasing your attack surface. Heck, even for option 2 you’re now relying on a new HTTP header. Never forget that HTTP headers are inputs to your application that need to be examined and carefully validated.

That’s just one example on a single page: I didn’t even mention all the possibilities for Ajax on the search form itself, dynamically creating or updating form fields based on selections made in the form. With the addition of each new Ajax feature, I’ve expanded the possible ways (permissible ways, really) of interacting with my application, increasing the amount of work my server-side code needs to do and the vigilance I need to bring to developing and reviewing the design and code.

Toolkits & Frameworks

I’ll write more about toolkits in a future entry, but I do want to mention now that server-side integration toolkits like DWR are good examples of increasing attack surface. With DWR, you can configure specific classes and methods that you want to expose via JavaScript, and DWR generates the JavaScript as a remote interface to your Java classes. I believe that CFAjax works in much the same way (heck, if memory servers it’s unapologetically a DWR port), as do many PHP Ajax frameworks. Every one of these interfaces is an extra API to your application that you are exposing, making your attack surface that much larger.

I haven’t researched this carefully, but some PHP Ajax frameworks have historically had bugs that permitted arbitrary code execution. Needless to say, this expands the attack surface a bit. :)

Client-Side Business Logic

The Ajax example that I gave earlier is a simple enhancement, but many Ajax apps, as opposed to Ajax-enhanced web apps, are moving more and more business logic to the web browser. This has subtle and not-so-subtle effects on state management, as I’ll explore in an upcoming entry. It also means that there’s a lot more code available for an attacker to play with.

I have encountered a strange, unstated expectation among some developers that once JavaScript code is sent out to a client, it’s untouchable. This seems to be especially the case with code generated by a framework. I’m not sure where this idea comes from, and I hope it crumbles with even the slightest examination, but it’s out there. And it’s flat-out wrong.

You don’t, for example, want to do things like send SQL queries in your Ajax requests. I swear, I actually saw this in a web app a couple weeks ago. I happened to have LiveHTTPHeaders open while I was surfing and saw a SQL statement scroll past. I investigated and sure enough, the server was executing whatever arbitrary SQL was sent to it from the browser.

The developer didn’t need Ajax, of course; it could just as easily have been a submitted HTML form. Still. Do not do this.

Another effect of moving more Ajax code onto the client is that there are new trust boundary concerns. As you know, input validation is essential to web application security. Software security in general, really. Any time data passes across a trust boundary, where you don’t entirely trust its origin or integrity — data submitted from a browser to a web server, for instance, or from a remote web service or a database to your application code — it is important to perform rigorous input validation. We are (hopefully) used to this. It ought to be second nature.

Let’s make this clear: we’re used to this on the server side, working in a trusted environment accepting untrusted input.

In Ajax apps, though, lots of data is being passed back and forth between client-side and server-side code. If there’s significant business logic running in the browser, it stands to reason that the browser should validate data that crosses a trust boundary on its way from the server. Here’s the thing, though: while on the server side our code runs in a trusted environment (or what we hope can be trusted), in a browser our code (or what we hope is our code) runs in an untrustworthy environment accepting untrusted input. In the past, we’ve more or less assumed that we could trust what came from the server. We learn from Amit Klein that we should not: the communication channel between the client and server is vulnerable and suspect.

The conundrum is of course that the code that does the validation is completely exposed on the client.

One thing to watch out for is blindly eval()ing JavaScript. As I wrote in part 1, the server response to an Ajax HTTP request is typically either XML, JavaScript, or HTML. Nowadays the JavaScript is usually JSON, which looks like this:

{
"birthdays":
[ {"name":'Abe Lincoln',    "bday": "12 February 1809" },
{"name":"James Buchanan", "bday": "23 April 1791"}]
}

Here’s a common way of using that response.

var obj = eval( '(' + res.responseText + ')' )

The risk here is that the server response may contain malicious code. If you blindly eval() the response, you’ll immediately execute that code. You can mitigate the risk by using a JSON parser to at least ensure that it is indeed JSON.

var obj = resp.responseText.parseJSON();

This is of course far from a perfect solution. I confess that I am not sure how best to handle this. I need to do more thinking and more research. Pointers are welcome.

Web 2.0 Meets SOA

As more and more business logic pushes out to the browser, it is tempting to have that client code connect directly to web services in a service-oriented architecture (not that you need web services for SOA, but bear with me). JavaScript can do SOAP, so why not? The problem is that often those services are thin wrappers around 20-year old COBOL code. You don’t want to be exposing this to the world. Andrew van der Stock discusses this in interview for SearchAppSecurity.com.

I don’t have a problem with JavaScript making web services calls using SOAP, REST, XML-RPC, whatever. Keep in mind, though, that the browser environment cannot be trusted, so any validation or access control you’ve put in place there doesn’t do any good. If the value of the transaction is high — e.g. if it needs authentication at all — or if the code behind the service was written with the expectation of running in a completely trusted environment, then you’re far better off minimizing exposure by providing carefully controlled and monitored access to that code. Meaning, don’t allow anyone in the world to connect to it: limit access to code running on your server. If you want to use JavaScript to access the service, have it contact another service that’s tied into your access control mechanisms.

Resources & Further Reading

I’m not pulling all this out of thin air. Much has been written on the topic of Ajax security. A lot of it FUD, but there is some very worthwhile reading out there that I’ve used to inform my own research and writing. Here’s some of it:

Mitigate Security Risks by Minimizing the Code You Expose to Untrusted Users

An article about attack surface reduction by Michael Howard

Ajax Security

A presentation at AppSec by Andrew van der Stock.

OWASP Guide 3.0

The new version of the Guide to Building Secure Web Applications has a draft chapter on Ajax security.

Ajax security resources

At cgisecurity.com.

del.cio.us/afongen/ajax+security

Rather than just duplicate more links, I’ll send you to my del.icio.us links.

Coming Up…

Next time, we’ll look at another challenge in Ajax security: state management and access control.

“Did you see 1 Raindrop today?” a coworker asked, referring to something Gunnar Peterson had written about Ajax security. I went off on a little rant about how yes XMLHttpRequest exploits are interesting and Amit Klein’s work is marvellous, but XHR can be used in an exploit regardless of whether a web app actually uses Ajax, that from a development perspective the approach is the same: we’re accepting requests from an untrustworthy client, so we need careful consideration of security throughout the development lifecycle, solid input validation & output escaping, session management, access control, and so on.

He waited patiently and smiled knowingly. “Yes, Sam, but you are already thinking about these things.”

Ah. As I also frequently complain, thinking like this is still unusual. That’s why software security is such a problem.

So I started looking around to see what was happening in the Ajax security space. It isn’t pretty, but the Ajax angle to the security problems is as overhyped as Ajax itself. There’s been a fair amount of discussion/coverage worth reading, including a new chapter in the OWASP Guide 3.0 draft. Gunnar’s post points to work by Amit Klein that I highly recommend.

On Tuesday I gave a short and overcaffeinated talk about Ajax security to my local OWASP chapter. To follow up on that, I’m starting a series of posts here addressing the topic in greater detail.

Executive summary: in the rush to add Ajax functionality to web applications, security is being disregarded or included as an afterthought (which often amounts to the same thing). Ajax itself isn’t insecure, but it sure can be unthinkingly misused and made insecure. Ajax can make other attack vectors like cross-site scripting and cross-site request forgeries worse, whether or not you actually use it in your application. As it has recently been made clear, XSS is far worse than we’ve thought, so it is important to be careful.

My position is actually a little more nuanced than that, and may well change as I write here. We shall see.

Quick Intro to Ajax.

You may already be familiar with Ajax, especially if you’ve read this far without being bored out of your mind. But just so we’re all on the same page, let me take this opportunity to show off a little Flash demo that my colleague Dave Kruse whipped up over breakfast just before an Ajax presentation that we were about to give.

You know how web applications have traditionally worked. Your browser makes a request to a web server, and the server responds by returning a whole new web page.

(For now, until I add some JavaScript to dynamically show/hide the animation, here’s a link to the first demo Flash movie. Thanks to Dave for his permission to use this here.)

With Ajax, your browser makes a request and the server responds, but this time with a small snippet of data that is used to update just a section of the page. No need for a full page reload.

(Link to the second Flash movie.)

Two key elements to this are that we are using JavaScript to make HTTP requests and to update the HTML page. We’ve actually been able to do this for some time, but in Ajax we can more easily manage the HTTP request and response using an object called XMLHttpRequest. The response from the server is usually one of the following:

• XML, which is parsed by JavaScript to generate the (X)HTML to add to the web page;
• more commonly we’re seeing JavaScript, which is eval‘d and run. JSON is a popular way to do this.
• the actual HTML that will be added to the page.

Ajax use in web applications falls along a spectrum ranging from small usability enhancements such as auto-populating a drop-down without reloading the page (dubbed by Harry Fuecks as HTML++), to mopre full-blown client-side apps, where lots of business logic is in JavaScript on the browser. How you choose to use Ajax will affect your security posture, as we will explore in future posts.

Ajax Security

Fundamentally, Ajax is no different when it comes to web application security. We have the same concerns:

• We’re dealing with completely untrustworthy clients.
• Input validation is essential. From the perspective of server-side code, requests are coming in from anywhere — untrusted clients, remember? — and we need to be sure that the data in the requests is what we expect.
• Escaping output, nothing new there.
• We have to pay careful attention to session management and access control.
• Code injection is a problem. JavaScript, XML, LDAP, DOM…
• The list goes on. See resources at OWASP. There’s even a new Ajax chapter in version 3 of the OWASP Guide.

That said, developers (and architects, too, don’t let them off the hook!) are making security mistakes when they introduce Ajax to their applications. I don’t blame Ajax for this: the real danger is JavaScript that operates in a browser environment, allowed to make HTTP requests and modify the DOM, and web apps that allow this to be abused easily. Actually, the real danger is that software security is too often an afterthought. For some reason, the rush to use Ajax has led to developers placing too much trust in client-side code. What worries me most about this is that at separate presentations at last week’s Black Hat, Jeremiah Grossman and Billy Hoffman described a new spate of JavaScript malware that takes advantage of XSS and CSRF vulnerabilities to do some seriously scary stuff. Grossman describes XSS as the new buffer overflow. Ajax isn’t necessary for some of the techniques described, but it can make an XSS attack worse — whether or not you use it in your web apps.

So what’s different about Ajax from a security perspective? I’ll take that up in the next entry.