Saturday, January 12, 2008

Web Service Attack Vectors

I have noticed over the last several months that more companies are beginning the migration to web services. What's a bit disturbing about this move is not the fact that companies are adding web services to their infrastructure, but the sheer volume of folks who have not yet realized that web services require the same type[s] of web application assessments that standard web applications require.

Ready? Aim? Attack?

A few notes for your nightly reading material. Keep in mind that this list is not the end-all, be-all of lists, but yes...please write this down in your Big Chief Notepad...

  • Web Services are subject to the same types of attacks as traditional web applications
  • Policies are blurred by integration and decoupling
  • Firewalls and SSL (not able to handle multi-hop transmissions) still don’t help much
  • Lack of end-to-end visibility
  • Poor design, Design Assumptions

Web Service Attacks

Unfortunately, WS's are still required assessment material for your developers, auditors or Information Security Team. For those who are unfamiliar with the attack types, here are a few:

  • XML Poisoning
  • Parameter Tampering
  • SQL Injection with SOAP Manipulation
  • XPATH Injection
  • LDAP Injection with SOAP
  • Directory Traversal and File System Access through SOAP
  • OS Command Execution
  • SOAP Message Brute Forcing
  • SOAP Parameter Manipulation with Buffer Overflow Attacks
  • Session Hijacking

I'm fairly certain that i'm probably missing several techniques here, but as soon as you master the list above, you can scream at me.

Policies are blurred...along with my vision of world peace

One common issue with WS (and SOA) architectures is the idea that the coupling of architectures might present a problem with security assessments and this is absolutely correct. As you might imagine, WS and SOA architectures do offer up a few challenges when it comes to assessments. Typically with WS architectures, the assessments begin with an exposed file known as the WSDL ("wiz-dell" (yes....I would love to take a wiz on my dell)). The WSDL file is essentially an XML-based file which defines the methods which are exposed for client connections. A common assessment would be to parse the XML file, understand its contents and perform a number of manipulation techniques against the file.

Firewalls and SSL

As with any conversation around web applications.... yes ....firewalls perform very little benefit to securing the web application. I do realize that this little blurb is focused more (or less) on WS architecture, however, it's worth noting this with regards to SOA. SSL offers up a particular challenge with SOA where it provides no true, end-to-end encryption solution for SOA. Each SSL certificate installed to the infrastructure must be terminated at it's next hop so these certificates will only provide a client-to-server encryption solution. Therefore, at each point in the architecture, a new certificate must be installed -- no one certificate can cover a multihop architecture. Additionally, this also adds to the idea that assessing an architecture where you have very poor (or complete lack of) end-to-end visibility increases the difficulty for web assessments.

Open up my raincoat? Yes, please.

If you had read through our little blurb on AJAX [In]Security, you will recognize that WS's also offer a particular amount of exposure to your application. Here is a sample file from Google's WS directive -- I'm hoping we are safe in inserting it here since it is publically availabe (google, if you want me to take it down....just write).


< name="doGoogleSearch">
< name="key" type="">xsd:string"/ >
< name="q" type="">xsd:string"/ >
< name="start" type="">xsd:int"/ >
< name="maxResults" type="">xsd:int"/ >
< name="filter" type="">xsd:boolean"/ >
< name="restrict" type="">xsd:string"/ >
< name="safeSearch" type="">xsd:boolean"/ >
< name="lr" type="">xsd:string"/ >
< name="ie" type="">xsd:string"/ >
< name="oe" type="">xsd:string"/ >
< /message>
< name="GoogleSearchService">
< name="GoogleSearchPort" binding="typens:GoogleSearchBinding">
< location="">
< /port >
< /service>


The exposure to many of these applications (while they may appear harmless) is the identification to what variables and types are being presented by the application. In our google sample above, you will will notice that most of the variable types (string, int, boolean, etc).

So folks, please keep WS applications in mind when you begin your conversations around your assessment criteria....the web service you save may be your own.