A few months ago we released the first version of the Secure Web Application Framework Manifesto: a set of requirements intended to guide web application framework developers in making more secure web application frameworks from the start.

Today we’re pleased to announce our next draft of the manifesto. We’ve reformatted the requirements according to much of the feedback we’ve received.

Check it out: Secure Web Application Framework Manifesto v0.08

We need your help - for some of the requirements in the manifesto we couldn’t find easily find examples of frameworks already fulfilling that requirement. Know of any? Please email us at labs [ a t ] securitycompass.com! As always, we appreciate any feedback you may have. Once we’ve collected the responses from this draft we’ll turn it into an OWASP project!

Edit: Many people helped shape the contents of this document. We have an acknowledgements section inside of the doc but would like to explicitly thank the following people for their ideas and/or support:

• Arshan Dabirsiaghi and the OWASP Intrinsic Security Working Group
• James Landis
• Jim Manico
• Dinis Cruz
• James McGovern
• Paco Hope
• Paul Johnston

It’s clear that your choice of web application framework makes a significant impact on the security of individual applications. Today we’re releasing a draft version of the Secure Web Application Framework Manifesto - a document that provides a set of security requirements to web application frameworks themselves. Once we’ve collected feedback from the community, we’d like to turn this into a living OWASP project that is updated annually.

We’re eagerly looking forward to any feedback you have. Please email us at labs [ a t ] securitycompass.com

Download it here

This article is based on the Command Injection in XML Signatures and Encryption whitepaper authored by Bradley W. Hill from Information Security Partners.

XSLT is a simple language designed to facilitate cross platform content generation by selecting and merging datasets presented in an XML document. The vulnerability described in the whitepaper still exists in today’s XSLT processing engines, which are widely used in web service implementations. In this article, we will look into reproducing this attack on two of the common XSLT processing engines: Microsft’s MSXML and Xalan (Java’s XML processing library). In addition to an overview of reproducing the attack, this article also features video demonstrations of the exploit that we feature in our Training courses. In both these scenarios we are using the latest versions of the frameworks’ XSLT processing engine as of September 16, 2009.

MSXML implemented in a .NET Application:
MSXML, Microsoft’s XSLT processor, provides a scripting engine to allow for dynamic content generation. The tag, amongst other things, allows developers to define custom functions that can then be called from XSLT code. The engine also provides functions within blocks complete access to .NET classes and methods as long as they fully qualified (e.g. System.Console.WriteLine). This extensibility raises the possibility of remote command execution from the code within the blocks. For instance, in our demonstration video we add a call to System.Diagnostics.Process.Start() method, which enables the attacker to spawn a command prompt.

Xalan implemented in a Java Application:
Xalan, on the other hand provides versions of standard Java classes such as Java.lang.Runtime and Java.lang.Object that can be included with the XSLT signature. These classes can then be used in tags to invoke member methods. In our demonstration video we will be using Java.lang.Runtime.exec() method to spawn a new process that launches Windows Notepad.