« Threat Protection for a Service Oriented World | Main | Threat Protection for Web Services - Transactional Issues »

The problem with securing web services isn't all about XML...it's also about the unique challenges brought about by distributed service based architectures. Here's just a couple of issues arising from distributed web services architecture -

1. Multiplication of open interface points - in a "simple" monolithic web app, the primary interface point into the application is through the user interface. Hence, many common attacks against those older simple web architectures would be driven through the web based interface such as SQL injection where a SQL command is appended into a web form field entry with the hope that it would be inadvertantly executed and valuable info from the database would be retrieved. In a distributed service based architecture, the problem is increased because of the multiple interfaces that can be potentially attacked. The very strength of a SOA based application becomes a challenge with regard to security. Each service component would have mutiple interfaces or published methods that may be exploited by a malicious attacker.

Proposed Countermeasures:
Comprehensive testing and code reviews from a security perspective isn't just helpful, it's essential. With an SOA, the scope of that tasks can be much larger than expected but web services application developers and security managers need to collaborate on this. Also, creating internal trust zones where critical services are grouped and locked down is a deployment best practice. Creating these zones by grouping similarly typed services and then locking down and applying appropriate defense measures from a intrusion prevention, firewalling perspective is helpful.

2. Protecting internal resources while exposing enabling cross enterprise transactions. The issue here is challenge of enabling services to legitimate external partners/users but still maintaining a measure of protection for internal service components. What often happens in many SOA deployments is that over a period of time, the number of services that are exposed to be externally facing increases and the overall security for a number of internal resources become vulnerable to attack.

Proposed Countermeasure: Create a broker/proxy service that will act as a "traffic cop" for legitimate external requests...the requests will be brokered by this service to the appropriate internal service component. This enables legitimate outside requests to be fulfilled but creates an abstract layer of protection for potential malicious outsiders. Vital resources are protected and it stops the creep of exposing more internal service components directly to the outside world.

The bottom line here is this - XML isn't the only security issue for web services architectures...you need to consider the architecture issues as well.

Posted by andreyee in web services security |Digg This|Add to del.icio.us

Trackback Pings

TrackBack URL for this entry:
http://www.ebizq.net/mt/mt-tb.cgi/373