Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Let's say I want to set up a sandbox or playground in PHP that users can use to create (or paste in) XML and XSLT, then transform the XML via the XSLT (by means of PHP 5's DOMDocument and related objects).

So, in a simple example, we'd have a form with two textareas - one for XML and one for XSLT. The user would enter his XML and XSLT and hit a button. The XSLT and XML would be posted to my server, where I'd transform the XML using the XSLT, then return the result to the user.

In some ways, this is like an eval(), but I have the feeling that the risks in this scenario are minimal, or much lower than if I put up a form with a textarea for PHP and just eval()ed that code.

Is my hunch correct, or are there hidden security issues here? If so, what are they, and what sort of precautions should I look into in order to secure my theoretical application.

share|improve this question
add comment

1 Answer 1

up vote 12 down vote accepted

I'm a PHP 'newbie' if you may call me one. But having analyzed XML and XSLT libraries in the past for security vulnerabilities, and having recently done work on an application that uses quite a bit of XML, here's what I could think of:

  • If it is possible to pass in a XSL transformation that causes execution of privileged code, you might have to find some means to disable such execution. In the Java world (where I come from), this 'feature' is not a standard, but you can find it implemented in the Xalan-J transformer, where several extensions have been built. If an attacker were to pass a XSL file, that attempted to execute a SQL query (using the SQL extension), or execute code already available on the server (using the Java extension), then Xalan-J would do so, if the conditions were right. I'm not sure if this applies to the transformers used by PHP, but it is worth ensuring that the transformer transforms XML into XML, and not perform anything else (which appears to be your requirement). I would restate this in simpler words as - choose a XML transformer than can be locked down as much as possible, to provide only the necessary function of transforming XML documents.
  • Files and other URIs (that are not visible to the attacker) can be specified in the XSL, which will be fetched by the transformer and could be included into the resulting XML. This is the external entity expansion (XXE) attack. It would be possible to obtain /etc/passwd, /etc/shadow etc. in this manner, if the files were accessible to underlying process. Disable expansion of entity references, if you can.
  • Related to XXE, is XDoS which allows for denial-of-service attacks to be mounted, resulting consumption of CPU cycles. The countermeasures include :
    • limiting the number of entity expansions that can be performed by the parser (which is akin to the secure processing support required by Java API for XML Processing 1.4). A related countermeasure in this area, is to limit the number of attributes that can appear in any element in the document.
    • disable the use of DTDs; your parser must be configured to reject any document with a DOCTYPE element in it. This is the approach adopted by SOAP implementations.
  • There is a possibility of reflected XSS (assuming that you are not populating the textarea using JavaScript) as well, for XSL transformations need not generate valid XML, or HTML. The result could simply be any random sequence of characters. The output would therefore have to be suitably escaped to prevent any XSS attack.
  • Vulnerabilities in the XML parser itself will make other forms of attacks possible. This CERT advisory, is a poster-boy, for it is indicative of the potential problems in XML parsing libraries. Parsers are complex, due to the various requirements imposed on them through various specifications; sometimes this results in edge cases where parsers would be unable to handle certain sequences of characters in a secure manner. Although quite a lot of work has gone into writing secure parsers, the work cannot be considered not complete. The appropriate recommendation in this case is to choose a well implemented and understood XML parsing library, and to patch the parsing library regularly for security fixes.

The above is not necessarily comprehensive, but I would assume that it is a good starting point.

share|improve this answer
    
Thank you for the excellent and detailed answer. Another vulnerability I came across: vigilance.fr/vulnerability/… . –  Tex Jun 8 '11 at 16:48
    
@Tex, you're welcome. The link you've posted describes a specific vulnerability. In general, XML parsers and libraries have quite a lot of code that could (or could have in the past) tripped over special sequences of characters. While XML might appear to be a well structured language with a good grammar, it is not necessary that a parser implementation is non-trivial. –  Vineet Reynolds Jun 8 '11 at 16:56
    
note that XDOS (aka XML Bomb) is based on DTDs, so the countermeasure in this case is blocking use of DTD. –  AviD Jun 11 '11 at 22:04
    
@AviD, thanks. it just didn't seem quite right. I'll edit it. –  Vineet Reynolds Jun 11 '11 at 22:05
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.