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]