1,364 Posts served
5,674 Conversations started
We are all familiar with a basic firewall; limiting the ports and protocols that are available to the outside world. And many firewall vendors are pushing “deep packet inspection” as a way to further control access by analyzing the data sent and received.
There are a number of XML appliance vendors (http://en.wikipedia.org/wiki/XML_appliance) all provide security to some degree but some bill themselves as XML security gateways. These products implement various standards including WS-Security. But today we will focus on defending against malicious XML traffic.
Malicious XML can be classified in three categories: Malformed Requests, Denial of Service and Content attacks.
Malformed Requests: May not be XML at all, but typically malformed requests have bad encodings, incomplete nodes or don’t adhere to a given schema. Early, fast and complete validation is the best way to eliminate bad requests, but keep in mind if this processing is done on the perimeter it often means having to reparse the XML for all good requests when it finally reaches the application server.
Denial of Service: Large payload requests, “billion laughs attack” and missing or broken URI references are some examples of requests were the sole intent is to consume processing time and create a denial of service. Like malformed requests these attacks are most effectively handled with proper validation. Again this if this is done on the perimeter the XML will need to be reparsed when it reaches the application machine.
Content Attacks: Are normally valid for a known schema. These are attacks that use the data or XML elements to carry the attack payload. SQL injection, Trojans and various application specific attacks are possible. These application centric attacks can not be defended on the perimeter by a firewall. It is the application that must properly process the data to prevent these attacks.
What is my advice? Parse once, validate once. The application server is the best place to do this, as it knows the schema and data rules that need to be applied. Just because the perimeter can identify a bad request doesn’t mean it should. Use a fast XML validator that makes use of multi-core in you application. And when your app sees a bad request; allow it to notify the network layer to ignore all future requests from that source. Bad requests are just that, bad requests.
No comments have been posted for this entry yet.