A new set of vulnerabilities came to light this week at Black Hat DC, and its appearance provides a good look at our bleak "next-gen" security future.

Not that it's actually likely to cause much of a stir. These vulnerabilities, which were discovered by Trustwave's SpiderLabs, are the sort of thing I think could well be overlooked because the realm in which they occur is terra incognita for most security professionals. Unless you have a pretty solid programming background, this stuff is pretty hazy: The flaws are found in a development framework you've never heard of using tools that do things you didn't realize needed doing.

That's not to say that a nonprogrammer, particularly one who has seen a lot of software hacks come and go, can't get a pretty good handle on what's up with these glitches. They involve Web applications that store data reflecting the current state of a user's session from page to page, and makeg this data available to code running on the client side as variables within the code.

The problem is that an adversary who places himself midstream -- redirecting communications between client code and server back end -- can see this data. Since the data can be sensitive, including things like account numbers and passwords, this is, of course, a problem and not the world's most obvious sort of problem, either.

As the article I pointed to above has it: "This is a fairly complicated vulnerability," says David Byrne, senior security consultant with Trustwave's SpiderLabs. "View state is something most people have heard of, but they aren't familiar with its inner workings."

Byrne and I will have to agree to disagree on whether most people have heard of view state. In any case, the generic nature of the flaw is readily understood. But that's only part of the problem. What's really going on here is that we're working with implementations of a standard called Java Server Faces. It's a framework that aims to separate the user interface on the front end from the client logic underneath the user interface, as well as the server back end. It's a three-way split of sorts that's very popular among software architects.

If you're developing code, then this is the way to go because splitting things up this way means different teams can use different tools, work for different companies, and so on. It means you can replace one piece of the triad without breaking the other two (at least in theory).

Indeed, this is how you get the next generation of cloud computing because the more independent the client side piece gets, the more readily you can hook it to an API connecting it to services that are "out there," provisioned on-the-fly to match demand, and so on. This, of course, provides you with a ready-made attack face. This is precisely the sort of attack that Trustwave is bringing to our attention.

I'd hasten to say that the clear delineation this three-way model provides is also a terrific opportunity to get a good handle on security. For one thing, you can encrypt the transactions between client and cloud (and that's all you have to do, as a developer, to make the Trustwave vulnerability go away -- it's a default configuration issue). And you can demand proper authentication among entities. Potentially this sort of application can be built more securely than the standard Web application we see today.

It's just that right now few in the mainstream security community is addressing these issues. Time to bulk up on the Web 2.0 development know-how.

Robert Richardson is director of the Computer Security Institute. Special to Dark Reading.