On 30 Jul 2009, at 10:08, Alexander Klimetschek wrote:
On Thu, Jul 30, 2009 at 10:46 AM, Ian Boston<i...@tfd.co.uk> wrote:
Looking at [3], 2 things jump out.
1. On post @typeHint gives a hint for the type of a property, If when
posting to a non existing resource you could pick up the resource
type from
the post sling:resourceType POST parameter would it be possible to
perform
the servlet resolution appropriately. Ie its still a non existing
resource,
but it gets routed to the correct servlet ?
This is probably not safe, because if any resource type = script
selector is injected from the outside, you can upload and run
arbitrary scripts on the server, provided you have rights to modify
content at one part of the repository (eg. /tmp for uploads). It is
possible to restrict against such an attack by additional guarding
(eg. restricting the script user, not allowing resource types located
in /tmp), but the generality of this issue makes it easy to have a
hole open in a running system.
I might be missing the point, but,
I think this is a generic problem not just limited to this area, if I
can create a node and set sling:resourceType=something/nasty, *and*
upload an arbitrary script to somewhere that is resoled to by
"something/nasty" , then I can do the same in 2 steps ?
IIRC, there is some work in progress to limit how scripts are loaded,
but it may not extend as far as protecting the location.
also... how does a script resolve *outside* /apps ?
2. (slightly off track) when posting to /content/new/* a path
generation
algorithm kicks in, being able to configure that algorithm might
help with
some of the virtual cases (probably should talk about this in another
thread)
:name and :nameHint are not enough?
yes, for names like /content/new/a_file_that_was_hinted
but not so good for
/content/new/a/file/that/was/hinted
where the name is a path, perhaps derived from the post.
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetsc...@day.com
