Andi Egloff's Weblog

Ajax and Web 2.0 vulnerabilities

As the new world order is forming around AJAX and the (terribly overloaded term) Web 2.0 a lot of new pain points are surfacing or are being amplified. As adoption becomes more wide spread and the applications move out of research labs into serious applications the motivation increases to address these new challenges.

One of these is security of AJAX and Web 2.0; and there is a lot of basic information out there; but is it enough to just give that a glance? Ignorance is only bliss until it bites you.

I personally found that looking at what you're doing purely from a vulnerabilities perspective is an incredible eye opener. And I invite you to take that journey as well, this is the link to a very well written and detailed view into this world of security:

Attacking AJAX Web Applications

It doesn't stop at just covering the basics of attacks at different levels (such as JSON, XML, JavaScript, XMLHttpRequest, XSS etc), it then applies these to an analysis of some popular frameworks includig DWR, GWT and Atlas.

Tags: ajax web2.0 security vulnerabilities XMLHttpRequest JSON JavaScript XSS attack application

Posted at 01:32AM Jan 12, 2007 by Andreas Egloff in Software Architecture  |  Comments[0]

Five things most people don’t know about me

Mark White just got me in a game of blog tag. Ehmm… thanks? Actually unlike a traditional chain letter I must admit I enjoyed the ability to explore my tag ancestor’s replies to “five things most people don’t know about me”, so I feel compelled to participate in this one.

So here are five things most people may not know about me

1. At age 17 a friend and I took trains from Switzerland down to Northern Africa - Morocco. We rented a dirt bike in Marrakesh to travel over the Atlas Mountains and into the Sahara desert. The way we chose Morocco as the destination? It was the furthest south you could go with an InterRail pass - a pass to travel Europe by train.

2. It may not be a big secret that I'm a car nut, but few may know that I can blame my dad for part of it. For example as a learner driver he let me practice on a 1948 Allard L Type, and I enjoy the hands-on experience of driving a 1929 Packard roadster with its unsynchronized gearbox. So you can’t just get me going about what the best driver's car is at the moment - or what parts would get your Evo moving – but I also have a soft spot for vintage cars.

3. As a kid I thought using computers purely for business tasks constituted computer abuse. Not surprisingly I was a big supporter of the Commodore 64/128 and Amiga - which I still own.

4. I was trained as a machine gunner and driver in the Swiss army. At age 16 the government gave me the first fully automatic rifle to take home - and I didn't think it was strange at the time. To take a job in the US (and other countries) I had to apply for leave.

5. In Nepal I learned how to bathe an Elephant in the river without falling off when he lies down

Now on to tag 5 others – you’re “it”: Jean-Francois, Binod, Arun, Harold, Todd

Posted at 09:37AM Jan 05, 2007 by Andreas Egloff in Personal  |  Comments[1]

Inside JBI part I: Clarifying Lifecycles

In this series I would like to give some insights into gotchas and topics that are not immediately obvious when reading the JBI 1.0 (JSR 208) specification. I'm very lucky that I can bug the spec leads Peter and Ron - and architects and leads like Keith Babo and Mark White who work on the RI and project OpenESB when I want to get some background information on JBI. I'd like to pass on some of this information that I have acquired in the last couple of years.

When stop isn't equals stop

In JBI the components and the service unit (SU) deployments both have their own lifecycle - and in just skimming the spec one might easily presume that stop in both has the same implications. It turns out, the service unit stop might be better described as "stop consuming" - that is right, after a SU stop it can still be provisioning services, it just isn't initiating new requests.

This is different than the component "stop", which means that the whole component should stop provisioning AND consuming services.

Here is another item to be aware of: the specification does not perscribe the interaction between the component and the SU lifecycles. The RI (and project OpenESB) does call the equivalently named lifecyle operation on all SUs when the component lifecycle operations are called (e.g. stop on all SUs when the component stop is called), but that is not explicit in the specification.

When implementing the component stop, you may come accross another interesting feature of the delivery channel: there is no way to re-start message delivery once it is closed, and we only get a new delivery channel in the component initialization.

This means you can not use the delivery channel close to implement the component stop: if the user does a stop and subsequent start you could not re-start delivery on this delivery channel, the user would have to completely shutdown the component first. This makes for an interresting time in implementing the component stop; none of these options are optimal and includes approches such as interrupting the deliverychannel or using the accept on the delivery channel with a regular time-out.

With this in mind, here is my wish-list for enhancements I would like to see in future specs:

• SU stop may benefit from a different name that makes it clear that only service consumption is stopped


• That the specification would explicitly declare the relationship between the component and SU lifecycle


• That the delivery channel would have a way to stop and re-start message delivery - separate from the ultimate shutdown

Tags: jbi esb openesb soa

Posted at 11:18PM Jan 04, 2007 by Andreas Egloff in SOA  |  Comments[2]

Usability awareness - and should we share the user's pain?

Ah, my first entry in the usability category.

Being married to a Usability Engineer I'm aware of a lot of exciting items going on in the field, but I'll certainly not pretend to be an expert. I guess I'm in phase 2 of usability awareness: at least I know that I don't know.

I would like to post items I come accross that catch my eye and ideally are thought provoking.

I'll start off with one of my favorite videos, the "we share your pain (WSYP) project". Yes, it's a spoof, but it is a good one.

Watch WSYP on YouTube
Get the WSYP original

Posted at 12:17PM Nov 30, 2006 by Andreas Egloff in Usability  |  Comments[0]

Coding with attitude

Just received this funny link to The Commentator, an automatic comment generator for your code.
Well, funny in the same way Dilbert is funny if you've been there :)

Posted at 11:43AM Nov 30, 2006 by Andreas Egloff in Personal  |  Comments[2]

Non-blocking NIO sockets in the JBI HTTP Binding Component (BC)

I received some questions about the HTTP BC (part of the Java EE SDK Tools Bundle and the project OpenESB) - and what the advantages are of it supporting the processing of request-response and one-way web service invocations without blocking threads.

So I will try to give a little background on the JBI architecture, illustrate what would happen if we did block threads - and last but not least show the advantages of supporting asychronous processing.

The JBI architecture is based on an asynchronous message bus that can be thought of as similar to in-memory JMS queues. The messages are XML based – and the processing of the request and sub-sequent response are completely asynchronous – they will be handled by different threads and there is no need to block a thread anywhere in between.

This allows for an extremely scalable system that is capable of handling a huge number of concurrent requests with a minimum of resources – in an extreme case where it might be tuned for throughput rather than response times for example it could be handling 10’000s of concurrent requests with under 10 threads - environment permitting of course.

Given this architecture, it would not fit well to use an HTTP connector that blocks threads - and doesn’t have an asynchronous API. Some of the implications this would have in the HTTP BC are:

Implications of blocking

Threading

* Threat of resource starvation and dead-lock (if there are recursive calls within services they can easily exhaust the thread pool – and stop the response from getting processed which might let others progress)

Scalability

* The large number of threads needed to scale at all will consume a lot of related memory which will limit the number of threads feasible
* Because the number of requests we can handle is limited by the number of threads we can efficiently use, we are limiting scalability a lot
* Even without taking efficiency and memory into account, the JVM will ultimately limit the number of threads possible at all - and hence concurrent requests

Performance

* More threads means more context switching, hurting performance
* Limiting the number of concurrent requests we can handle means we can’t always fully utilize available CPU or network bandwidth, i.e. we might be “waiting” for a response so we can free a thread and proceed with the next request

Fortunately this does not have to be. The HTTP BC uses the Grizzly NIO framework including the asynchronous request processing (ARP) extensions that is part of the Glassfish application server.

Not blocking threads makes for an excellent match with the JBI architecture and has these implications (Note that the HTTP BC in the appserver 9.0 currently only uses Grizzly on the server side):

Benefits of not blocking

Threading

* Because nothing blocks there is no threat of resource starvation or dead-lock
* As an example 3 threads in the BC could handle any number of concurrent requests (for higher response times we can choose to add more), e.g.
  thread 1 – Handle the incoming traffic (asynchronous Provider), normalize the message, send it to the JBI “queue” (normalized message router)
  thread 2 – Handle messages off the JBI “queue” (normalized message router), send requests via the asynchronous client API
  thread 3 – Handle responses (asynchronous client API listener), send them to the JBI “queue” (normalized message router)

Scalability

* Very limited number of threads, minimizes the memory footprint
* Because the number of concurrent requests we can process is not limited by the number of threads we can realistically use, we can scale to much larger number of concurrent requests

Performance

* Less context switching which might hurt performance
* Never “waiting” for responses to proceed means we can fully utilize available CPU and/or network bandwidth

Scalability and performance are some of the primary selling points for an integration platform - it makes sense for us to make use of the full potential of JBI.

Posted at 06:40PM Nov 28, 2006 by Andreas Egloff in SOA  |  Comments[0]

Comet Basics

There are some very good detailed technical explanations of Comet already, but it seems there is some room for a basic discussion of what it is about, what it is good for – and how it jives with AJAX.

Comet is a "made up" term - so unlike AJAX (Asynchronous JavaScript and XML) this did not originate as an acronym.

If we view AJAX as the ability to do "invisible HTTP requests" behind the scenes via javascript, coupled with some dynamic HTML - then Comet it primarily an extension or variation on how the communication over HTTP is done.

Essentially it allows to "push" or "stream" data to the web client via standard HTTP GETs instead of for example polling for updates at regular intervals.

How can it do this, considering the browser always has to initiate requests?

Well, first imagine that you do an HTTP GET request as with any old AJAX framework. The server gets the request, but instead of responding immediately with nothing if it doesn't have data, it then waits for data to arrive - for example from an event mechanism, JMS or any other asynchronous source. Only once it gets data will it actually write data into the response for the HTTP GET. It also typically does not finish the HTTP GET request at that point, but will continue to wait for further data - and write more to the response when it arrives ("stream").

So that is what is meant when people say Comet will "always keep a connection open" - it may re-establish a connection by sending another HTTP GET request when a previous one is closed for various reasons. This way there is always a "channel" already open for the server to send data to the web client.

At this point your gut may tell you - open connections and waiting sound terribly expensive - does any of this scale? Is it bad for the network or server?

Done right and used right this can be a very efficient way to send events to web clients; in fact, it can save a lot of unnecessary “polling” requests. Not only can it be more efficient, updates will get to the clients quicker (lower latency) than when polling.

The open connection itself primarily costs the server a socket it needs to allocate per client – with associated (“kernel”) memory. What you do *not* want to happen is for the server to block for example a thread per request when it waits for data to arrive – that would be Comet done in a fashion that will not scale well. Instead, use a non-blocking server – for example one that uses Java NIO non-blocking sockets and can deal with the request and the response separately, in an asynchronous fashion.

There are several products on the market already that do this efficiently; and it is moving from more specialized event driven solutions to the main stream web servers too.

For example, my Québécois pal Jeanfrancois just recently added a Comet extension and example to the NIO based http connector “Grizzly” used in the GlassFish application server. This is actually based on the same asynchronous extensions he had added during our work to support non-blocking NIO sockets for Java Business Integration (JBI) (which we presented at a BOF at this year’s JavaOne).

Unlike JBI, some technologies such as Servlets currently have a little catching up to do until such asynchronous, event driven responses are dealt with in a standardized way and fit well.

There is plenty of controversy about the term Comet too; some like to call it “hanging get” – I don’t like that term too much as the “hanging” sounds too much like blocking to me. Others call it the "slow load technique" ("slow" might be a bit misleading) or "long lived HTTP". And if have this feeling that something is odd about the term Comet - yes, Ajax and Comet are both names of cleaning products. Whatever it is called, a Comet style interaction for AJAX is a worthy concept to name. I probably picture more of a meteor shower in considering when and how the data will flow - but hey that’s just me :)

As with AJAX, Comet can be over-done and abused. Care has to be taken to only transfer relevant data at rates that can be digested by the target platform.

For more details also have a look at Alex Russell's original Comet term proposal or Greg Wilkin's white paper on Ajax, Comet and Jetty which does a very nice job of explaining why you want a server that fits this style of interaction well.

Posted at 11:08PM Oct 02, 2006 by Andreas Egloff in Software Architecture  |  Comments[1]

What's in a Buzzword?

Ahhh, a virgin blog. Let's get to it.

I just had an interesting exchange that might have me re-consider my allergies to buzzwords.

It all started innocent enough as I called another architecture meeting where I was discussing the use of Comet and AJAX. After a few explanations and examples the leads seemed happy and excited about the match to their needs.

What is so thought provoking about this? Well, I had a very similar discussion nearly 3 years ago. There I was in a room with very accomplished developers, architects, book authors on all kinds of web and java topics - and I mostly got blank stares at the explanation of how we could essentially achieve "push" for events to our web GUI. I can't read minds, but I would bet if they didn't know me beforehand some of them would have thought this guy is nuts; everyone knows you don't push to web apps.

Now I might be giving a bit too much credit to the terms themselves, but it does seem that some of them help to understand, categorize, communicate - and propagate ideas. The other part probably is that there is more infrastructure support - and more applications of the idea, but ultimately I think the "hype" about a little acronym AJAX and (what I consider an extension of that idea) Comet pushed these long-standing ideas into the limelight.

A lot of buzzwords will over-sell and under-deliver, but in time the true colors typically start to show – and apparently there is an upside to that hype too.

Posted at 03:48PM Oct 02, 2006 by Andreas Egloff in Software Architecture  |  Comments[0]