We started by thinking about the XML deserialisation problem and workflow, namelly from a REST point of view (since the idea is to use XML to submit data to the REST server)
So we come up with 3 server patterns for the XML to Object conversion:
- Server looks where to go before going?
- Server asks user where to go?
- Server asks user where to go and what to do?
Here is how we presented each of these ideas (in red are the actions that have dangerous security implications):
And as you can see by in these two blog posts:
- XStream "Remote Code Execution" exploit on code from "Standard way to serialize and deserialize Objects with XStream" article
- Using XMLDecoder to execute server-side Java Code on an Restlet application (i.e. Remote Command Execution)
We found that XStream used the Server asks user where to go technique, and XmlDecoder uses the Server asks user where to go and what to do one:
Here are the questions that I think we need good answers for:
- What are the patterns used by other real-world Xml deserialisation APIs? (note that some might support more than one of these patterns)
- How can we detect (in code reviews,pentests and scanners) the dangerous uses of these APIs? (note that it is OKish to use XmlDecoder and XStream on XML content that come from trusted sources (for example an config XML file stored in the main class path)
- How can developers (and managers, buyers, lawyers) be exposed to that usage? (so that they can make good security decisions)
- Where should all these tool's mappings exists? (for example at the moment there are already some commercial tools that detect the use of XMLDecoder, but that info/mappings is currently hidden inside those tool's private/proprietary rule packs)
- What should be added to the documentation of these APIs, so that developers are aware of its dangers? (ideally this should be done in a way that is consistent across multiple APIs, languages and patterns)
- How should this documentation be added, and where should it go?
- How can we create 'API Labels' so that it is easy to understand and see the security foot-print of each of these APIS (see Software Labels – Jeff’s OWASP AppSecDC 2010 presentation (another dropped good idea) )
And here is the challenge for our industry, we still don't have good solutions/answers all these questions, which shows how much we still have to go (in the Application Security space), and how much the current development (and security analysis) workflow still needs to improve.
What I think is very interesting about this scenario is that there isn't a clean solution (like in SQL Injection, CSRF or XSS).
Basically, these XML deserialisation APIs are doing what they were designed to do, and they perform a valid business activity (which is why they are used in real-world apps).
This means that the problem is not really in the API, but how it is used.
Which leads us to the problem of 'if developers are not aware of that is happening under the hood and the security implications of what they are coding, it will be just about impossible for them to create secure applications'.
Basically, these XML deserialisation APIs are doing what they were designed to do, and they perform a valid business activity (which is why they are used in real-world apps).
This means that the problem is not really in the API, but how it is used.
Which leads us to the problem of 'if developers are not aware of that is happening under the hood and the security implications of what they are coding, it will be just about impossible for them to create secure applications'.
I like to think of these APIs as radioactive, where they have a lot of power, but need to be handled very carefully, or they could have a LOT of side effects (and security implications).
