Truth in SOA

Hello All -

I just wanted to send out a little note that I'll be at Oracle Open World next week at Moscone Center in San Francisco on October 12th, 13th and 14th.

We've got a demonstration setup that uses Oracle(R) SOA Suite 11G and Intel(R) SOA Expressway. The demo shows how you can deploy SOA Expressway as an edge security gateway to offload security processing and provide threat protection for application level attacks. We'll have SOA Expressway and Oracle SOA Suite running side-by-side on some monster laptops running on 64-bit Linux. We also plan to have a demo of Oracle Entitlements Server (OES) to demonstrate how authorization decisions can be pushed to the network edge.

You can visit the Intel software website for more information on Intel(R) SOA Expressway and Oracle's website for more information Oracle(R) SOA Suite.

It looks like everything old is new again with XML Attacks...

I came across this article in the Washington Post. They use the term "XML fuzzing" to describe really just 50% of the XML threat equation - something I have always called coercive parsing, which is the manipulation of the XML document structure.

This, however, is only half of the battle. XML threats can also be semantic meaning the attack is modifying the structure of the XML document to force a down-stream system to execute a particular function. This is the other element of XML threats that is left out of the discussion. Semantic threats cover areas where the XML document is executed in some way, such as SQL injection, embedded JavaScript, or other embedded languages like XPath.

All in all, it is a cat and mouse game where the most important feature is extensibility and the ability to deploy new yet unnamed threats in real-time using a generalized mechanism such as regular expressions. All of these features, protection from structural threats, semantics threats, and threat extensibility can be found in Intel's SOA Expressway.

I've been digging into OAuth lately, which is a protocol for delegated authentication and authorization. It seems to be useful for cases where the end user is authorizing an intermediary (called a consumer) to access a specific resource for one-time access. This means that the end user is the policy decision point, rather than a centralized PDP.

The protocol certainly looks interesting, but I've got a problem with it. My problem is that for browser interactions, the user is not given the equivalent of an SSL "lock" or other indicator that this is truly an OAuth protected interaction. This means that OAuth alone is not enough to reduce phishing attempts as described here. A rogue website can just tell the user to sign in and then claim its only accessing data one time - there is no way for the user to verify this fact. Further, we know from the days of X.509 certificates that users can't possibly understand a basic trust relation, so having them understand a three-legged protocol with a shared secret is a stretch. Worse, the presentation argues that OAuth helps reduce the password anti-pattern, but a username and password is obviously required by the user - most users won't know the difference. Once more people move to OAuth, phishing sites will just make it appear as if they are doing OAuth - it will be a zero-sum game. We need the equivalent of an "OAuth lock" in the browser for this protocol to be used for high-value transactions.

Given that users must trust the website they are interacting with in the end, the simpler approach is to have websites publish a privacy and security policy that clearly says that access to service provider websites will be done with user credentials, but that the credentials will only be used once and not saved. Doesn't this achieve the same result with less code to write and less complexity? Is it more prudent for me to trust the website I am at or trust that the website has successfully implemented a complex, multi-hop security protocol?

JavaOne is this week at Moscone center in San Francisco and I've been putting together a live demo of Intel(R) SOA Expressway. The plan is to show some perimeter defense, delegated authentication and message throttling functions. The scenario has three threads running, good requests, bad requests (auth faults) and bad requests (XML attacks). This set up is perfect for getting all of the pretty colors to show on the Intel(R) SOA Expressway dashboard!

I've got SOA Expressway running on an old IBM t43p (single core) laptop on 32-bit Red Hat AS4. This is really for convenience since the laptop is small and easy to lug around. What's interesting is that even on this ancient machine Intel(R) SOA Expressway is extremely reliable - I had it going all weekend and it converged to about 8000 messages per hour, which actually limited by the client I'm using, which is SOAP UI.

If anyone is around this week, please come by come check out the demo.

Blake

My mantra for the day is simply this: Paradigms are seldom total.

Instead, the real world makes things complex, and this is a boon to the service oriented view of the world, whether it is under the moniker of "SOA" or "services."

The cloud craze, aside from infecting every blog out there is really a new requirement for service mediation between on-premise Enterprise applications and off-premise services. Will the cloud paradigm become total? Maybe for the consumer, but I think we have a long way to go for the Enterprise.

With its combination of security functions, virtualization support and mediation capabilities, Intel(R) SOA Expressway is in the right place a the right time to take advantage of hybrid cloud architectures.

A colleague forwarded me this link which highlights what appears to be a severe memory limitation with the IBM DataPower XI50. It appears that the device is having trouble applying an XML digital signature to a 100MB XML file.

This brings back the issue of using knowledge of the complexities involved in XML digital signatures to execute a Denial of Service (DoS) attack. Using this information an attacker could search for a DataPower device currently performing XML signatures on much smaller documents and take down the box with a single large document. I guess you might say this post highlights not one, but two problems with IBM DataPower: (a) The fact that it can't handle digital signatures on large XML, and (b) The fact that this fact results in a potential DoS vulernability.

I was recently on a business trip last week and somehow I picked up a copy of "USA Today." This newspaper tends to find me rather than the other way around. Normally I try to avoid it, but am always drawn to it even if its just to see what the average American is supposed to care about.

I was looking through the business section and I was shocked to see a story on the front page on SQL Injection attacks!

I was surprised for a number of reasons. First off, SQL injection, or the attempt to insert SQL queries to return database information or spoof a login, is a very specific type of attack, but the USA Today story makes it seem like the average user should be "worried" about this type of attack, which is a little funny. It also claims that SQL injection turns your computer into a bot I think that attacks like cross-site request forgery or cross-site scripting have a much higher impact on the average Joe. XSS and CSRF can affect casual browsing if a user simply browses the wrong section of a website (such as the 'forums') where someone has managed to inject a <script&rt; tag.

Upon careful dissection, this article seems instead to be a sort of advertising placement for IBM:

"For the first five months of 2008 IBM ISS helped large corporations block about 5,000 SQL attacks a day. By mid-June, daily attacks spiked to 25,000;"

This is a bit ironic compared to the news that came out earlier in the year regarding the DoS attack against IBM DataPower or the problems the device has with persistent connections. I sure hope IBM ISS isn't recommending the DataPower device as an application firewall to protect against SQL injection!

As for content threats themselves, this is a very interesting area that I am sure will experience more growth in both the types of threats devised as well as the protection mechanisms. What is needed is a high-performance content processor that can at a minimum scan for different types of attacks within the application payload but also must be extensible as attacks are always changing and evolving.

What worries me the most here are cases of an attack that rely on an application firewall to keep state between HTTP requests. That is, rather than the attack being defined as a single SQL injection, or script injection it may be defined across a set of messages. In other words, the attack can't be detected by looking at a single message, but by a pattern of messages.