Revisiting Defending from XEE Attacks With Security Managers
Bear Giles | December 19, 2011A little over a year ago I wrote about using security managers and used XEE attacks (that is, using XML External Entities (XEE) in XML for denial of service or information disclosure attacks) in passing.
Using a SecurityManager and Identifying Requirements.
Since then I’ve had a ‘duh’ moment and realized a simple solution to this problem. I am currently working on a longer piece but XEE attacks are serious enough to warrant a quick update to the earlier piece.
In a nutshell there’s no need to explicitly list all of the required permissions – we can simply train our SecurityManager. The process is straightforward:
- write a logging SecurityManager as described earlier[1]
- process a few sample documents that exercise all of the requirements
- flip a flag
- the SecurityManager now checks all future requests against the permissions already seen. If there’s a match it’s permitted. If not it’s denied.
A human should still review the identified permissions before putting this into production – you want to ensure it’s the most restrictive permissions. E.g., you should only grant permission to read a specific file, not an arbitrary file.
That’s the problem holding up the broader paper. XML processing is a very tightly constrained problem and we can identify precisely what’s required. We can’t say that about many other problems so we would want wildcard matching of pre-specified permissions and that’s a lot more complex.
[1] I would make one change today – I would call the existing SecurityManager, if it exists, instead of blindly accepting all requests.