Article:		Multi-Interface Web Services Made Easy
Subject:		Security
Date:		2002-05-09 06:59:31
From:		Kip Hampton
Response to: Security
chrishmorris wrote: "return $style_path . 'semdiff_' . $style . '.xsl'; can be attacked with the double dot/poisoned null exploit.." Careful examination reveals that the $style_path property is set internally within the unexposed application class ( via $context->{style} ) and is at no time exposed to the world (or based on data passed in from the user). "sub getXSLparameter passes user data to XSLT style sheets without examining it. Stylesheet authors are not used to looking at security issues - what if they use one of these parameters as the name of an included file?" Putting aside your presumptons about what XSLT stylesheet authors typically do or think about, no external document can be included (accidently or otherwise) into a stylesheet via an <xsl:param/> element. Aslo, any key/value pairs passed to a stylesheet processor (which I'm sure your're aware is neither a script interpreter, nor able to call other executables) that are not explictly addressed in the stylesheet *by name* are ignored so, assuming that one did hack in a "mystery field" into the POST, it would have no effect whatsoever on the stylesheet transformation, or its result. That said though, yes, it is good practice, for production code to explicitly pass only that data to the XSLT processor that the stylesheet requires. "SOAP::Lite has a serious security hole, see http://www.phrack.com/show.php?p=58&a=9" Which is fixed in the current version (.55). See soaplite.com "If your aim is to illustrate how to use some new technologies, you could at least put a comment in: #TODO validate data here" You mean like: "Now that we have a working (if not totally complete and sanity-checked) application..." ? Maybe I need to dust off the <blink> tag? Yes, it is true, in this column I often do presume that the reader is smart enough to take the code samples as intended; that is, as merely illustrative of a specific concept and not something to be dropped as-is into production. I also realize that treating my readers as capable peers that do not require each jot and tittle to be pre-chewed for them puts me at odds some of the accepted conventions of technical writing. You do raise a very good point about security and "web services". Dillegence in this area key-- especially as more and more services become available. Thanks for reading, and for your comments. -kip

Previous Message

Up

Next Message

• Middleware and software contracts
  2002-05-13 04:31:55 Chris Morris
  
  Thank you for your thoughtful reply.

  
  You rightly object to my statement that "Stylesheet authors are not used to looking at security issues". It isn't a question of anyone's skills or character - it is a question of the division of responsibilities between modules.

  
  As you say, <xsl:include> does not accept parameters. However, document() and <xsl:document> do, and unfortunately some people work around the limitation in include by writing a stylesheet whose output is another stylesheet. So it seems likely that there will be some exploitable XSLT created.

  
  Your perl script knows that the parameters are user input, and the XSLT will know whether one of them is being used as a file path. One or the other has to clean the input. Since the perl is taking care of / hiding the network interface, it seems to me that it is responsible for security.

  
  I agree that $context->{style} can't be exploited in your script. But you are publishing model code here. The context object that CGI::XMLApplication uses has the power and risk of global variables. If someone decides for other reasons to copy the CGI parameters into $context - much like you did with the XSLT call - then this could create an exploit.

  
  Thinking about these issues has made me reconsider a script I recently wrote which attempts to match the CGI parameter names to SQL column names.

  
  I think the issue is one of middleware design, and goes wider than security. To make middleware powerful, we try to make it transparent. We look for a design that enforces few preconditions, and promises few postconditions. If we succeed, any design contract must be agreed between the outer layers of the sandwich. Unfortunately such contracts can get neglected. At least, the documentation of the middleware must point out to its clients which responsibilites still lie with them.

  
  It is good to hear that the problem in SOAP::Lite is fixed. I think it came about by starting with considerations of power, transparency, and elegance, instead of starting with the question "What do we want this component to do?".

  
  I agree that you couldn't cover everything in a short article ... I hope you agree that published code is fair game for criticism!