Web 2.0 Security Part 2: A MASHup of Problems

This is Part 2 of a series on Web 2.0 Security.

A good way to remember things is to use mnemonics, so when you're trying to list the security issues relevant to Web 2.0 just remember this: it's a MASHup.

• More of everything.
• Asymmetric data formats
• Scripting based
• Hidden URLs and code

This episode is brought to you by the letter "A".

Asymmetric Data Formats

AJAX-based Web 2.0 applications, like traditional web applications, can incorporate a number of different data formats. Traditional web applications often include some sort of scripting language such as Javascript, VBScript, or ActionScript, Cascading StyleSheets (CSS), and HTML. Web 2.0 and specifically AJAX-based applications incorporate these data formats and add a mix of others such as JSON (JavaScript Object Notation), XML, SOAP, plain text, and even CSV (Comma Separated Values).

AJAX-based requests are often submitted using traditional GET and POST www-url-encoded data, but the return data can - and is - formatted in a number of ways. Often it's simply HTML, but in a growing number of applications, especially those built atop toolkits such as Script.actulo.us and Dojo, the underlying data format is JSON or XML.

The primary issue with data exchange in an XML format is that the data is exchanged sans schema. This is problematic in that one of the primary mechanisms for securing XML over HTTP is to enforce existing schemas. In many cases the existing schemas are loose, and can be "tightened" to exert even better security over the data transferred.

Except in the cases of RSS and RDF, the XML exchanged in Web 2.0 applications is rarely associated with a schema, making it difficult to troubleshoot issues or track down security vulnerabities. If you don't know what the data is supposed to look like, you can't very well ensure that the data being exchanged is valid, can you?

Further exacerbating the issue is the use of JSON, which has a core BNF that describes the format, but provides no mechanism for ensuring that a Javascript Number object actually conforms to what one would expect for a numeric value.

Combining the lack of ability to enforce a specific data format on any given data exchange with the ability to send data to the server in one format and receive a response in another format makes securing Web 2.0 applications exceedingly difficult. Data cleansing products that may provide excellent security for well-understood formats such as GET and POST of www-url-encoded data are not capable of providing the same assurances for relatively new formats such as JSON, and are further hampered by the lack of a schema for XML-based data.

Web application firewalls, as well, can have difficulties securing multiple, asymmetric data exchanges because a firm pattern to the exchanges cannot always be reliably established, and these products rarely understand emerging formats such as JSON. These products work on the basis that they understand and are able to parse data formats and then enforce specific policies on the data, such as numeric fields containing only numeric data, etc... Without the ability to parse the data and distinguish between attribute and value, these products are essentially blind to malicious data that may be transported via an emerging format.

Many security products are also unable to cope with a mixture of data in a single "page", such as is the case with XML Islands.

The Risks

• Traditional security mechanisms may be unable to cope with asymmetric data format exchanges, leaving applications vulnerable to a wider variety of data-based attacks
• Data cleansing products are not aware or able to parse and apply policy to emerging data formats such as JSON, leaving applications and application infrastructure vulnerable to attack via malicious data
• The possible combinations make it difficult to troubleshoot and require more skills than traditional applications
• The schema-less nature of the XML exchanged in Web 2.0 applications leaves it vulnerable to XML poisoning attacks
• The use of interpreted data formats such as JSON leave the client vulnerable to scripting-based attacks
  
  The issue of scripting is the subject of the letter "S", which we'll discuss in the next part of this series.

Next: Scripting based  

Imbibing: Nothing