Re: (In)Security in Sling
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
Re: (In)Security in Sling
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
Re: (In)Security in Sling
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
Re: (In)Security in Sling
Hi, thanks John, for pointing this out. Part of the problem you describe is misconfigurations on my part (I did not realize that the anonymous user is not part of the everyone group). But as Felix has described the problem with the /apps directory cannot be fixed by configuration. I just filed bug 989 [1] for this (an in-the-air collision with Felix' mail). As a third aspect: I believe there are parts in most sites where the json representation is not desired. What do you think about making the json servlet more configurable in terms of black/whitelisting properties it renders? That would be on top of all other proper security measures, of course. Michael [1] https://issues.apache.org/jira/browse/SLING-989 On Tue, Jun 2, 2009 at 12:33 PM, Felix Meschberger fmesc...@gmail.comwrote: 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 -- Michael Marth | http://dev.day.com/
Re: (In)Security in Sling
Hi, Michael Marth schrieb: Hi, thanks John, for pointing this out. Part of the problem you describe is misconfigurations on my part (I did not realize that the anonymous user is not part of the everyone group). But as Felix has described the problem with the /apps directory cannot be fixed by configuration. I just filed bug 989 [1] for this (an in-the-air collision with Felix' mail). As a third aspect: I believe there are parts in most sites where the json representation is not desired. What do you think about making the json servlet more configurable in terms of black/whitelisting properties it renders? That would be on top of all other proper security measures, of course. It is difficult to decide, when json access is desired (for example if you have client-side JavaScript which wants to grab content) and when not (attack case) - I am not really sure, whether we can solve this with proper black/whitelisting. Maybe just some ACL should be enough. Regards Felix Michael [1] https://issues.apache.org/jira/browse/SLING-989 On Tue, Jun 2, 2009 at 12:33 PM, Felix Meschberger fmesc...@gmail.comwrote: 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
Re: (In)Security in Sling
So that marker should be and ACL containing an ACE with execute privilege granted to the appropriate session. I wasn't aware that there was such a privilege in the Jackrabbit DefaultAccessManager or 283, but I agree thats were it should be. On a practical note, Unless DefaultAccessManager et al is going to be re-implemented for Sling, then this should go back to Jackrabbit as DAM is heavily protected for obvious reasons, and when I looked trying to extend the way in which principals for a session were resolved, there didn't appear to be many (if any) extension points available in DAM since registration of bits in the compiled privileges bitmap (o .a.j.core.security.authorization.PrivilegeRegistry.registerPrivilege) is private (very) Ian On 2 Jun 2009, at 11:59, David Nuescheler wrote: 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
Re: (In)Security in Sling
hi ian, sorry for the confusion. there are is no privilege to execute something in jcr. i am not even sure that they should be part of the repository since the repository is not going to execute things anyway. i think if one has a tight coupling like between the os and the fs this may make sense, but i see the repo/sling coupling much looser so i would probably just go for the read privilege. the read privilege seems to be cause issue as far as i can tell not necessarily the execute privilege. right? regards, david On Tue, Jun 2, 2009 at 2:00 PM, Ian Boston i...@tfd.co.uk wrote: So that marker should be and ACL containing an ACE with execute privilege granted to the appropriate session. I wasn't aware that there was such a privilege in the Jackrabbit DefaultAccessManager or 283, but I agree thats were it should be. On a practical note, Unless DefaultAccessManager et al is going to be re-implemented for Sling, then this should go back to Jackrabbit as DAM is heavily protected for obvious reasons, and when I looked trying to extend the way in which principals for a session were resolved, there didn't appear to be many (if any) extension points available in DAM since registration of bits in the compiled privileges bitmap (o.a.j.core.security.authorization.PrivilegeRegistry.registerPrivilege) is private (very) Ian On 2 Jun 2009, at 11:59, David Nuescheler wrote: 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 -- David Nuescheler Chief Technology Officer mailto: david.nuesche...@day.com web: http://www.day.com/ http://dev.day.com twitter: @daysoftware
Re: (In)Security in Sling
David, On 2 Jun 2009, at 13:06, David Nuescheler wrote: hi ian, sorry for the confusion. there are is no privilege to execute something in jcr. i am not even sure that they should be part of the repository since the repository is not going to execute things anyway. agreed. i think if one has a tight coupling like between the os and the fs this may make sense, but i see the repo/sling coupling much looser so i would probably just go for the read privilege. the read privilege seems to be cause issue as far as i can tell not necessarily the execute privilege. right? If the execute session only ever requires read to the areas of the repository that are executable and no other areas, read will work. If that session requires read elsewhere, then there needs to be some other mechanism. (ideally a AccessControlPolicy (named, or list)) Ian regards, david
Re: (In)Security in Sling
Michael, No worries at all. I figured I could resolve most of this through a front end proxy (like Apache2), but wanted to see if there was a better way. +1 on the json restriction. Would be kind of cool to be able to restrict/grant access based upon a regexp as well. Thank you for your help. Respectfully, John On Tue, Jun 2, 2009 at 6:03 AM, Michael Marth mma...@day.com wrote: Hi, thanks John, for pointing this out. Part of the problem you describe is misconfigurations on my part (I did not realize that the anonymous user is not part of the everyone group). But as Felix has described the problem with the /apps directory cannot be fixed by configuration. I just filed bug 989 [1] for this (an in-the-air collision with Felix' mail). As a third aspect: I believe there are parts in most sites where the json representation is not desired. What do you think about making the json servlet more configurable in terms of black/whitelisting properties it renders? That would be on top of all other proper security measures, of course. Michael [1] https://issues.apache.org/jira/browse/SLING-989 On Tue, Jun 2, 2009 at 12:33 PM, Felix Meschberger fmesc...@gmail.com 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 -- Michael Marth | http://dev.day.com/
Re: (In)Security in Sling
Hi all This is something that has been nagging me for a while now: imho the whole JSR 283 security stuff looks good from the JCR context, but Sling is a different beast: it is a web framework, and therefore susceptible to the whole web attack vectors, like information disclosure (e.g. unwanted JSON output), injection attacks (unsure about possible attack vectors), malicious file execution and others, see http://www.owasp.org/index.php/Top_10_2007 for some examples. Therefore relying on JSR 283 is necessary but not sufficient to provide state of the art security for Sling. There are several possibilities to provide this additional layer of security, one is to provide a secure reverse proxy with filter possibilities, like John mentioned. This is state of the art for enterprises, but not necessarly the best approach for more lightweight environments. Another approach would be to have a servlet filter handling all web attack mitigation strategies and in the same time beeing able to communicate with the underlying repository. Perhaps this would also allow to create something like an execute privilege, which doesn't make sense in JCR context but does make very much sense for Sling. The spec doc btw, mentions the possibility to define additional javax.jcr.security.Privilege namespaces, so it looks (without knowing details) to be well prepared for enhancements. I am unsure if and how OSGI might be another mechanism to implement web security. wdyt? Cheers, CSp.
Re: (In)Security in Sling
I have been wondering about this as well. The reverse proxy seems not to be the right place to add the security since once bypassed one would have full access to the site and the code of the site. a sling based lockdown may be a problem too, since one site may need json (say the content management on top of sling) but another may not (such as a public web site). The content reported by some formats should also be different based on what server accesses it and be better filtered - so for example there is no need to output some nodes in a .json file when used by the web site but there is for a content management system. Otherwise too many attack vectors are exposed for potential attacks. Ruben Christian Sprecher wrote: Hi all This is something that has been nagging me for a while now: imho the whole JSR 283 security stuff looks good from the JCR context, but Sling is a different beast: it is a web framework, and therefore susceptible to the whole web attack vectors, like information disclosure (e.g. unwanted JSON output), injection attacks (unsure about possible attack vectors), malicious file execution and others, see http://www.owasp.org/index.php/Top_10_2007 for some examples. Therefore relying on JSR 283 is necessary but not sufficient to provide state of the art security for Sling. There are several possibilities to provide this additional layer of security, one is to provide a secure reverse proxy with filter possibilities, like John mentioned. This is state of the art for enterprises, but not necessarly the best approach for more lightweight environments. Another approach would be to have a servlet filter handling all web attack mitigation strategies and in the same time beeing able to communicate with the underlying repository. Perhaps this would also allow to create something like an execute privilege, which doesn't make sense in JCR context but does make very much sense for Sling. The spec doc btw, mentions the possibility to define additional javax.jcr.security.Privilege namespaces, so it looks (without knowing details) to be well prepared for enhancements. I am unsure if and how OSGI might be another mechanism to implement web security. wdyt? Cheers, CSp.
(In)Security in Sling
Hello, 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. For Example: http://dev.day.com/discussion-groups/users.infinity.json http://dev.day.com/discussion-groups/apps.infinity.json http://dev.day.com/discussion-groups/apps/mailingLists/mailingLists.jsp(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
Re: (In)Security in Sling
Hi, On Tue, May 26, 2009 at 5:15 PM, John Crawford craw...@gmail.com wrote: Is there a better way to handle this? Access control. BR, Jukka Zitting
Restricting SlingRepository.loginAdministrative()? (was: Security in Sling)
Hi, On Wed, Apr 22, 2009 at 6:22 PM, Rory Douglas rory.doug...@oracle.com wrote: Bertrand Delacretaz wrote: 2) Prevent legitimate scripts from messing up with the system An variant of 2) just showed up in the Accessing JCR thread. Looks like anyone that can upload a script can do the following: sling:defineObjects/ % SlingRepository repo = sling.getService(SlingRepository.class); Session superSession = repo.loginAdministrative(null); // and then do anything, like superSession.getRootNode().remove(); % loginAdministrative is fine for trusted code, but you're right that we might want to restrict it. Not sure how to best approach this...what do people think? -Bertrand
Re: Restricting SlingRepository.loginAdministrative()? (was: Security in Sling)
Hi, Bertrand Delacretaz schrieb: Hi, On Wed, Apr 22, 2009 at 6:22 PM, Rory Douglas rory.doug...@oracle.com wrote: Bertrand Delacretaz wrote: 2) Prevent legitimate scripts from messing up with the system An variant of 2) just showed up in the Accessing JCR thread. Looks like anyone that can upload a script can do the following: sling:defineObjects/ % SlingRepository repo = sling.getService(SlingRepository.class); Session superSession = repo.loginAdministrative(null); // and then do anything, like superSession.getRootNode().remove(); % loginAdministrative is fine for trusted code, but you're right that we might want to restrict it. Not sure how to best approach this...what do people think? In terms of OPSGi and Java Security, the best approach would probably be to guard this method by the SecurityManager and introduce a Permission for this. Regards Felix
Re: Restricting SlingRepository.loginAdministrative()? (was: Security in Sling)
Hello For sure not the easiest solution, but what about storing the application in a separate workspace from the content. If scripts were only executable in the application workspace, malicious attackers could maybe create a script in the content workspace, but it would not be possible to execute it. Regards Julian On Thu, Apr 23, 2009 at 10:51 AM, Felix Meschberger fmesc...@gmail.com wrote: Hi, Bertrand Delacretaz schrieb: Hi, On Wed, Apr 22, 2009 at 6:22 PM, Rory Douglas rory.doug...@oracle.com wrote: Bertrand Delacretaz wrote: 2) Prevent legitimate scripts from messing up with the system An variant of 2) just showed up in the Accessing JCR thread. Looks like anyone that can upload a script can do the following: sling:defineObjects/ % SlingRepository repo = sling.getService(SlingRepository.class); Session superSession = repo.loginAdministrative(null); // and then do anything, like superSession.getRootNode().remove(); % loginAdministrative is fine for trusted code, but you're right that we might want to restrict it. Not sure how to best approach this...what do people think? In terms of OPSGi and Java Security, the best approach would probably be to guard this method by the SecurityManager and introduce a Permission for this. Regards Felix -- Julian Sedding, Solution Engineer, Day Software AG email: julian.sedd...@day.com office: +41 61 226 98 92 http://www.day.com/ -- This message is a private communication. If you are not the intended recipient, please do not read, copy, or use it, and do not disclose it to others. Please notify the sender of the delivery error by replying to this message, and then delete it from your system. Thank you. The sender does not assume any liability for timely, trouble-free, complete, virus free, secure, error free or uninterrupted arrival of this e-mail. For verification please request a hard-copy version.
Security in Sling
Hi, I was thinking about the implications of giving a user write access to a subtree of the repository. With that access the user could now upload a new script and create a node that invokes that script when rendered. What if the script contains something like System.exit(1)? Or something even more malicious? Do we have mechanisms for preventing attack scenarios like that? BR, Jukka Zitting
Re: Security in Sling
The servlet container usually have default security policies defined, which can easily be changed. Eg for tomcat, look at conf/catalina.policy. Am not sure what facilities ogsi containers provide in this area though? 2009/4/22 Jukka Zitting jukka.zitt...@gmail.com Hi, I was thinking about the implications of giving a user write access to a subtree of the repository. With that access the user could now upload a new script and create a node that invokes that script when rendered. What if the script contains something like System.exit(1)? Or something even more malicious? Do we have mechanisms for preventing attack scenarios like that? BR, Jukka Zitting -- -Tor
Re: Security in Sling
Hi, Jukka Zitting schrieb: Hi, I was thinking about the implications of giving a user write access to a subtree of the repository. With that access the user could now upload a new script and create a node that invokes that script when rendered. What if the script contains something like System.exit(1)? Or something even more malicious? Do we have mechanisms for preventing attack scenarios like that? No, unless Java platform security (SecurityManager) is enabled, in which case the exitVM PlatformPersmission would be required to call System.exit() and likewise for other actions. Regards Felix
Re: Security in Sling
This is an interesting one for us, since all users will have write access to the repository. Is there an 'execute' permission in sling, or perhaps even an equivalent to the no execute mount option in posix. I see some extensions to the DefaultAccessControlManager looming. Ian On 22 Apr 2009, at 11:25, Jukka Zitting wrote: Hi, I was thinking about the implications of giving a user write access to a subtree of the repository. With that access the user could now upload a new script and create a node that invokes that script when rendered. What if the script contains something like System.exit(1)? Or something even more malicious? Do we have mechanisms for preventing attack scenarios like that? BR, Jukka Zitting
Re: Security in Sling
Hi, On Wed, Apr 22, 2009 at 12:40 PM, Torgeir Veimo torg...@pobox.com wrote: The servlet container usually have default security policies defined, which can easily be changed. Eg for tomcat, look at conf/catalina.policy. What would such a policy file look like, i.e. what codeBase should be used and what permissions granted? Also, I'm not sure how easy it would be to apply the Java security policies to things like ESP scripts. BR, Jukka Zitting
Re: Security in Sling
Hi, Torgeir Veimo schrieb: The servlet container usually have default security policies defined, which can easily be changed. Eg for tomcat, look at conf/catalina.policy. Am not sure what facilities ogsi containers provide in this area though? OSGi containers basically also depend on standard Java security, for example many operations in the framework and compendium services are defined to fail with a SecurityException if some Permission is not granted. By defualt (in Sling), Java security is turned off. Be warned, though, Java Security is a thorny road ;-) Regards Felix 2009/4/22 Jukka Zitting jukka.zitt...@gmail.com Hi, I was thinking about the implications of giving a user write access to a subtree of the repository. With that access the user could now upload a new script and create a node that invokes that script when rendered. What if the script contains something like System.exit(1)? Or something even more malicious? Do we have mechanisms for preventing attack scenarios like that? BR, Jukka Zitting
Re: Security in Sling
Hi, Ian Boston schrieb: This is an interesting one for us, since all users will have write access to the repository. Is there an 'execute' permission in sling, or perhaps even an equivalent to the no execute mount option in posix. I see some extensions to the DefaultAccessControlManager looming. No, there is no such thing. Neither on the repository level nor on the Sling level. In fact such an exception can also not be enforced by the repository, since it has no notion of execution. I think, though, the storing such a permission would probably be possible and the scriping handlers we have would have to ensure the permissions, which is not currently done. Regards Felix Ian On 22 Apr 2009, at 11:25, Jukka Zitting wrote: Hi, I was thinking about the implications of giving a user write access to a subtree of the repository. With that access the user could now upload a new script and create a node that invokes that script when rendered. What if the script contains something like System.exit(1)? Or something even more malicious? Do we have mechanisms for preventing attack scenarios like that? BR, Jukka Zitting
Re: Security in Sling
Hi Jukka, On Wed, Apr 22, 2009 at 12:25 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: ...I was thinking about the implications of giving a user write access to a subtree of the repository. With that access the user could now upload a new script and create a node that invokes that script when rendered Requiring scripts to be stored under /libs or /apps, as a first step until we have something better, could help here, as website users are not supposed to be able to write to these locations. -Bertrand
Re: Security in Sling
Bertrand Delacretaz wrote: Hi Jukka, On Wed, Apr 22, 2009 at 12:25 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: ...I was thinking about the implications of giving a user write access to a subtree of the repository. With that access the user could now upload a new script and create a node that invokes that script when rendered Requiring scripts to be stored under /libs or /apps, as a first step until we have something better, could help here, as website users are not supposed to be able to write to these locations. I'm not sure if I understand the whole discussion here. But scripts are only picked up from configured paths (libs and apps by default). So as long as the user is not allowed to write in these locations, everything should be fine. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Security in Sling
Hi, Carsten Ziegeler schrieb: Bertrand Delacretaz wrote: Hi Jukka, On Wed, Apr 22, 2009 at 12:25 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: ...I was thinking about the implications of giving a user write access to a subtree of the repository. With that access the user could now upload a new script and create a node that invokes that script when rendered Requiring scripts to be stored under /libs or /apps, as a first step until we have something better, could help here, as website users are not supposed to be able to write to these locations. I'm not sure if I understand the whole discussion here. But scripts are only picked up from configured paths (libs and apps by default). So as long as the user is not allowed to write in these locations, everything should be fine. Well, there is a chance here, of course: Consider the node is created as /content/bad with resource type /content/malicious and the script as /content/malicious/html.esp. Then the request to /content/bad.html would in fact call the script. This is kind of the security downside of the full flexibility and openness we have Of course, restricing scripts to live in side any of the ResourceResolver.getSearchPath() or defining an excecution permission would help resolve this issue. I personally would prefer the execution permission approach (though it may fall short of scripting languages calling into the resource resolver (or the repository directly) to load included scripts ) But it would not prevent a properly authorized user from writing and using malicious script in /apps/sling/servlet/default/html.esp. Regards Felix
Re: Security in Sling
On Wed, Apr 22, 2009 at 1:42 PM, Felix Meschberger fmesc...@gmail.com wrote: Hi, Carsten Ziegeler schrieb: ...scripts are only picked up from configured paths (libs and apps by default). So as long as the user is not allowed to write in these locations, everything should be fine. Well, there is a chance here, of course: Consider the node is created as /content/bad with resource type /content/malicious and the script as /content/malicious/html.esp... Then the request to /content/bad.html would in fact call the script. That's what I meant. ...Of course, restricing scripts to live in side any of the ResourceResolver.getSearchPath() or defining an excecution permission would help resolve this issue. I personally would prefer the execution permission approach (though it may fall short of scripting languages calling into the resource resolver (or the repository directly) to load included scripts )... Restricting scripts to ResourceResolver.getSearchPath() locations sounds much easier and less risky, at least until we have a concept of execution permissions. There's no real reason to have scripts anywhere else than under those search paths. -Bertrand
Re: Security in Sling
Felix, That sounds like it would address the issue of accepting scripts from trusted sources but would not, make the scripts safe as per your original post. On System.exit itself I cant remember if the runtime shutdown handler can veto System.exit, although the damage will already be done. enabling java security feels (to me at least) like potentially hard work, especially with all the OSGi classloaders in play. Ian On 22 Apr 2009, at 12:00, Felix Meschberger wrote: Hi, Ian Boston schrieb: This is an interesting one for us, since all users will have write access to the repository. Is there an 'execute' permission in sling, or perhaps even an equivalent to the no execute mount option in posix. I see some extensions to the DefaultAccessControlManager looming. No, there is no such thing. Neither on the repository level nor on the Sling level. In fact such an exception can also not be enforced by the repository, since it has no notion of execution. I think, though, the storing such a permission would probably be possible and the scriping handlers we have would have to ensure the permissions, which is not currently done. Regards Felix Ian On 22 Apr 2009, at 11:25, Jukka Zitting wrote: Hi, I was thinking about the implications of giving a user write access to a subtree of the repository. With that access the user could now upload a new script and create a node that invokes that script when rendered. What if the script contains something like System.exit(1)? Or something even more malicious? Do we have mechanisms for preventing attack scenarios like that? BR, Jukka Zitting
Re: Security in Sling
On Wed, Apr 22, 2009 at 12:41 PM, Felix Meschberger fmesc...@gmail.com wrote: Hi, Jukka Zitting schrieb: Hi, I was thinking about the implications of giving a user write access to a subtree of the repository. With that access the user could now upload a new script and create a node that invokes that script when rendered. What if the script contains something like System.exit(1)? Or something even more malicious? Do we have mechanisms for preventing attack scenarios like that? No, unless Java platform security (SecurityManager) is enabled, in which case the exitVM PlatformPersmission would be required to call System.exit() and likewise for other actions. System.exit() bears IMO no real risk, since it can be prevented by java security. scripts that heavily consume resources and/or eat CPU in endless loops are more dangerous and much harder to detect and prevent. regards, toby
Re: Security in Sling
Hi, On Wed, Apr 22, 2009 at 2:22 PM, Tobias Bocanegra tri...@day.com wrote: System.exit() bears IMO no real risk, since it can be prevented by java security. I'd like to see the relevant java security settings. With all the OSGi stuff, JCR bundle loading, and script compiling in place I think coming up with a correct security policy is a major undertaking. Do we want to go down that path, or use alternative means like the proposed script resolution restrictions? BR, Jukka Zitting
Re: Security in Sling
Hi, Jukka Zitting schrieb: Hi, On Wed, Apr 22, 2009 at 2:22 PM, Tobias Bocanegra tri...@day.com wrote: System.exit() bears IMO no real risk, since it can be prevented by java security. I'd like to see the relevant java security settings. With all the OSGi stuff, JCR bundle loading, and script compiling in place I think coming up with a correct security policy is a major undertaking. Do we want to go down that path, or use alternative means like the proposed script resolution restrictions? The result is different: with Java security, we do not prevent anyone from injection scripts in the wrong location. With the path alternative we do not prevent anyone from calling System.exit(0). So, it depends on what you want ;-) I think, the first thing might be better to be approached first. Though I would prefer the execution permission approach over the path based approach, I think the path based approach is probably easier to implement. Regards Felix
Re: Security in Sling
On Wed, Apr 22, 2009 at 2:44 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, On Wed, Apr 22, 2009 at 2:22 PM, Tobias Bocanegra tri...@day.com wrote: System.exit() bears IMO no real risk, since it can be prevented by java security. I'd like to see the relevant java security settings. With all the OSGi stuff, JCR bundle loading, and script compiling in place I think coming up with a correct security policy is a major undertaking. Do we want to go down that path, or use alternative means like the proposed script resolution restrictions?... Those are different concerns: 1) Prevent users from uploading and executing arbitrary scripts 2) Prevent legitimate scripts from messing up with the system So we probably need both approaches. -Bertrand
Security in Sling
Bertrand Delacretaz wrote: 2) Prevent legitimate scripts from messing up with the system An variant of 2) just showed up in the Accessing JCR thread. Looks like anyone that can upload a script can do the following: sling:defineObjects/ % SlingRepository repo = sling.getService(SlingRepository.class); Session superSession = repo.loginAdministrative(null); // and then do anything, like superSession.getRootNode().remove(); % Regards, Rory
