- From: Alessandro Vernet <avernet@orbeon.com>
- Date: Sun, 10 Jun 2007 18:24:46 +0200
- To: public-xml-processing-model-wg <public-xml-processing-model-wg@w3.org>
Thank you for picking this up and taking this to the mailing list. Maybe we can make some progress on this and iron out some misunderstand we might have. Before going over the points in your message, let me mention two use cases I have in mind as we talk about parameters: 1) A pipeline is called from the command line and parameters are the mechanism used to pass command line arguments to the pipeline. 2) A web framework maps URI to pipelines and parameters is the mechanism used to pass request parameters to the pipeline. E.g. on loads http://server/approve-transaction.xpl?id=123 and the pipeline approve-transaction.xpl is called with a parameter "id" that has a value "123". In both cases, I imagine 3 different actors: A) End-users: they call the pipeline from the command line in (1) and use the web site in (2). B) Pipeline authors: they write the pipeline and invoke steps (stylesheets through the XSLT component, other components, other pipelines, ...). Those step are potentially written by someone else. C) Step authors: write the other pipelines, stylesheets, or components used by pipeline authors. The behavior of steps can be influenced by the parameters they receive. If by default, parameters received by the pipeline are automatically passed to all the steps, an end-user can influence the behavior of steps by passing parameters to the pipeline, without that influence being made clearly apparent to the pipeline author. If the end-user is well-intentioned, we might call this flexibility. But it the end user is ill-intentioned, this becomes a security risk. To make this even more concrete, imagine that pipeline which handles an expense report it receives as an input document. Amongst other things the pipeline calls a stylesheet that implements business logic checking if the expense report is receivable. That stylesheet has a parameter "always-approve", with default value false(). The pipeline author is not careful and doesn't explicitly set the value of this parameter to false() nor writes additional code to prevent parameters from being passed to the stylesheet. This allows some ill-intentioned end-users to pass always-approve=true to the pipeline and have their expense report always approved. With this in mind, I consider that: i) It is not wise to have parameters received by the pipeline passed by default to all the steps. ii) Requiring pipeline authors to make it explicit in the their code when they want parameters received by the pipeline to be passed to a step will make some pipelines slightly more verbose. But this is not an unreasonable burden on the pipeline author in the light of (i). On 6/7/07, Alex Milowski <alex@milowski.org> wrote: > I reject the argument against this because of security concern as: > > * parameters are no different than pipeline inputs or outputs in > terms of security. That is, if you are concerned about pipeline > invocation from a security perspective, all inputs--xml or parameters--are > equally troubling. There are few important differences between inputs and parameters: 1) Inputs to the pipeline must be declared by the pipeline. If a pipeline has a input always-approve, the pipeline will have a <p:input port="always-approve"/>. This is not the case for parameters. The fact that the pipeline might receive parameters won't even be explicit. 2) The defaulting story we for inputs doesn't say that if a pipeline has an input "always-approve" port, then that port is automatically connected to any input port named "always-approve" that a step might have. To do with inputs what we are considering to do with parameters, we would have to say that one can call the pipeline passing a document to an input port that is not declared by the pipeline and that this document will be passed to any step in the pipeline that has an input port with the same name. I wouldn't consider this to be a good idea either. > * the pipeline author now has the control to exclude pipeline > parameters from a step. This means a pipeline author can write > a "secure step" than can't be affected by pipeline parameters Yes, the pipeline author has that choice. The pipeline author can indeed by adding some markup write a "secure step". But I would like this to be the default, rather than requiring the pipeline author to do extra work to make things secure. > * true security relies upon securing the execution environment from > doing harm to the local system (e.g. as a "jail" or "secure VM"). As such, > parameters, inputs, and outputs have little to do with this. Yes, securing the execution environment is part of your security story. If your pipeline engine is handling HTTP requests, you want that engine to be executed by a non-privileged user. If your pipelines send queries to a database, you want pipelines to do so using a non-privileged database user. But as you know, this is not the whole story. Alex -- Orbeon Forms - Web 2.0 Forms, open-source, for the Enterprise http://www.orbeon.com/
Received on Sunday, 10 June 2007 16:24:52 UTC