[xwiki-devs] [VOTE] Restrict the location of skin resources inside Jars for security
Hi devs, Initially I didn't activate the resource skin extensions plugins (jsrx and ssrx) for security considerations, since they can be used to read any file from the classpath. I had forgotten to work on that, and now they have been enabled and used in their current implementation for a while. This means that changing the behavior will cause backward incompatibilities... So, I'm proposing that all skin resources packaged inside Jars should reside under the /skinx/ root directory. This prefix shouldn't be included in the pulled URL, it will be appended internally, and enforced to prevent any /skinx/../privateresource tricks. For example: $xwiki.jsrx.use('/gmaps/gmaps.js') will look for /skinx/gmaps/gmaps.js inside jars and the /classes/ directory. As a migration plan I'd like to implement this check ASAP, add a configuration for enabling the old behavior (if no resource was found with the skinx prefix, search without the prefix), which should be set to true by default in 4.5. Trigger a warning (in the logs) when such a deprecated resource is found. For 5.0 we switch to false by default, and in 6.0 we remove the switch completely. WDYT? -- Sergiu Dumitriu http://purl.org/net/sergiu
On Sun, Jan 13, 2013 at 1:53 AM, Sergiu Dumitriu <[email protected]> wrote:
Hi devs,
Initially I didn't activate the resource skin extensions plugins (jsrx and ssrx) for security considerations, since they can be used to read any file from the classpath. I had forgotten to work on that, and now they have been enabled and used in their current implementation for a while. This means that changing the behavior will cause backward incompatibilities...
So, I'm proposing that all skin resources packaged inside Jars should reside under the /skinx/ root directory. This prefix shouldn't be included in the pulled URL, it will be appended internally, and enforced to prevent any /skinx/../privateresource tricks.
For example:
$xwiki.jsrx.use('/gmaps/gmaps.js')
will look for /skinx/gmaps/gmaps.js inside jars and the /classes/ directory.
The downside is that we won't be able to (re)use JS/CSS from third party jars (not build by us). Why not filter access based on file extension? jsrx could accept only *.js and ssrx only *.css . Thanks, Marius
As a migration plan I'd like to implement this check ASAP, add a configuration for enabling the old behavior (if no resource was found with the skinx prefix, search without the prefix), which should be set to true by default in 4.5. Trigger a warning (in the logs) when such a deprecated resource is found. For 5.0 we switch to false by default, and in 6.0 we remove the switch completely.
WDYT? -- Sergiu Dumitriu http://purl.org/net/sergiu _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Sergiu, Just my two cents since I have not thought deeply about it, but couldn't we benefit on the fact that we minimize those files ? If we impose that jrsx and ssrx files always got minimized, and that minimization somewhat does not succeed unless we have a valid input, it would limit a lot what could be read in the classpath ? Only Admin would still be able to request unminimized files for debugging. Is this really difficult or still present too much risks ? On Sun, Jan 13, 2013 at 12:53 AM, Sergiu Dumitriu <[email protected]> wrote:
Hi devs,
Initially I didn't activate the resource skin extensions plugins (jsrx and ssrx) for security considerations, since they can be used to read any file from the classpath. I had forgotten to work on that, and now they have been enabled and used in their current implementation for a while. This means that changing the behavior will cause backward incompatibilities...
So, I'm proposing that all skin resources packaged inside Jars should reside under the /skinx/ root directory. This prefix shouldn't be included in the pulled URL, it will be appended internally, and enforced to prevent any /skinx/../privateresource tricks.
For example:
$xwiki.jsrx.use('/gmaps/gmaps.js')
will look for /skinx/gmaps/gmaps.js inside jars and the /classes/ directory.
As a migration plan I'd like to implement this check ASAP, add a configuration for enabling the old behavior (if no resource was found with the skinx prefix, search without the prefix), which should be set to true by default in 4.5. Trigger a warning (in the logs) when such a deprecated resource is found. For 5.0 we switch to false by default, and in 6.0 we remove the switch completely.
WDYT? -- Sergiu Dumitriu http://purl.org/net/sergiu _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
Hi, On Jan 13, 2013, at 12:53 AM, Sergiu Dumitriu <[email protected]> wrote:
Hi devs,
Initially I didn't activate the resource skin extensions plugins (jsrx and ssrx) for security considerations, since they can be used to read any file from the classpath. I had forgotten to work on that, and now they have been enabled and used in their current implementation for a while. This means that changing the behavior will cause backward incompatibilities...
So, I'm proposing that all skin resources packaged inside Jars should reside under the /skinx/ root directory. This prefix shouldn't be included in the pulled URL, it will be appended internally, and enforced to prevent any /skinx/../privateresource tricks.
For example:
$xwiki.jsrx.use('/gmaps/gmaps.js')
will look for /skinx/gmaps/gmaps.js inside jars and the /classes/ directory.
As a migration plan I'd like to implement this check ASAP, add a configuration for enabling the old behavior (if no resource was found with the skinx prefix, search without the prefix), which should be set to true by default in 4.5. Trigger a warning (in the logs) when such a deprecated resource is found. For 5.0 we switch to false by default, and in 6.0 we remove the switch completely.
WDYT?
Another solution which comes to mind is to define a java policy file and forbid access outside the webapp root by default (allow the tmp dir, the data dir, etc). It's a bit more complex to set up but it is also more secure for the user, more generic and I believe we'll need to do that at some point anyway. Thanks -Vincent
participants (4)
-
Denis Gervalle -
Marius Dumitru Florea -
Sergiu Dumitriu -
Vincent Massol