hi guys, i really think this should be dealt with, using proper repository access control. as soon as we start to let the application deal with security we need to worry about it every specific application, and become prone to "xyz-injection" similar to the problem that db's have with "sql injection". it becomes particularly tricky if you try to filter things out of the query results and the likes...
my personal guidance would be to make the access control "tighter" in the sense that one would forbid read privileges to "/apps" and "/homes" for the anonymous user (in case that is not desired) and have the script execution use a session with appropriate privileges to read and execute. regards, david On Tue, Jun 2, 2009 at 12:50 PM, Ian Boston <i...@tfd.co.uk> wrote: > Felix, > +1 > In addition, I would like to see a marker on the parent nodes that > designates the subtree as containing executable content. > > Then the special session can be used to execute the scripts, but only after > it had checked to see the script is located in an "executable" subtree. > A suitably authorized user could read and write, > > Perhaps this already exists ? > Ian > On 2 Jun 2009, at 11:33, Felix Meschberger wrote: > >> Hi, >> >> John Crawford schrieb: >>> >>> I have been working with sling for quite some time and, of course, Day >>> products. One thing that I have been increasingly concerned with is the >>> end >>> users ability to scrape all of the sites content and code with minimal >>> effort using the built in functionality of the SlingPostServlet. >> >> The Sling Get Servlet to be precise ;-) >> >>> >>> For Example: >>> >>> http://dev.day.com/discussion-groups/users.infinity.json >>> http://dev.day.com/discussion-groups/apps.infinity.json >> >> As Jukka said, you may employ access control to prevent this. >> >> But there is a glitch for the scripts located in /apps and /libs: >> Currently scripts are read from the repository using the session of the >> current user, that is the request user. >> >> So preventing access to >> >>> http://dev.day.com/discussion-groups/apps/mailingLists/mailingLists.jsp >> >> by simply denying read-access for the anonymous user actually prevents >> using the site at all. >> >> One solution to this problem could be to not load the scripts with the >> session of the current user but to use a special-purpose session (for >> example an admin session) to do this. >> >> This way, you may lock down /apps and /libs for general consumption but >> may still execute the scripts in there. >> >> WDYT ? >> >> Regards >> Felix >> >> >> (this >>> >>> one really disturbs me) >>> >>> So far, my solution has been to provide a proxy (namely Apache2) in front >>> of >>> sling to filter out any undesired requests. Seems to work. But, by >>> doing >>> this, it takes way what is so cool about Sling. I have reported to Day >>> Support numerous times, but they don't seem too concerned about it. But >>> for >>> sites where the content is critical or where we require users to pay for >>> our >>> content, it is very important to us. >>> >>> Is there a better way to handle this? >>> >>> Please let me know your thoughts. >>> >>> Respectfully, >>> John >>> > > -- David Nuescheler Chief Technology Officer mailto: david.nuesche...@day.com web: http://www.day.com/ http://dev.day.com twitter: @daysoftware
