Re: [xwiki-users] Security best practices for Xwiki deployment and management
Adding to the list of potential security issues, Caleb DeLisle brought up an interesting point in a different thread, regarding users granted programming rights (which is not enabled for Xwiki users unless specifically granted via Rights administration doc.): Programming permission opens up a lot of security holes which are unsafe to give to subwiki admins Specifically this: http://jira.codehaus.org/browse/GROOVY-1875 It would be useful to get a discussion going on the security ramifications of this issue for a singe-xwiki instance and also for a wiki-farm. Don't at least some of the pages have to be installed with programming rights, such as the OpenOffice import administration and the Task Manager? And how much private information could be accessed in a compromised system, where someone inappropriately gained control over one of these special documents with programming rights? For example, could the private password fields of XWiki.user documents be accessed, or is that separately gated by the rights administration in Xwiki? What happens for the case where authentication happens over LDAP? Does LDAP auth prevent inadvertent access to password information in a system with a compromised page w/ programming rights? It would be useful to develop a set of Xwiki best-practices to prevent this groovy bug from being a security issue with Xwiki. The underlying groovy bug won't be addressed, apparently, till Groovy 2.0http://jira.codehaus.org/browse/GROOVY-3010, and it's especially complicated because it's one of those bugs that's a feature: fix private field visibility Michael Kebe http://secure/ViewProfile.jspa?name=michael.kebe added a comment - 02/Oct/09 03:55 AM I just read Neal Ford's book The Productive Programmer. And in chapter 12 Meta-Programming he just picked this bug to show testing a private method of Java with Groovy. Here is a quote: Technically, this is a bug in Groovy (that has been there since day one), but it's so insanely useful, no one has bothered to fix it. And I hope they never do. In any language with strong reflection capabilities, the private keyword is not much more than documentation anyway: I can always use reflection to get to it if the need arises. There's a lively, deep. discussion on the issue, http://jira.codehaus.org/browse/GROOVY-1875 which is apparently the top issue for groovy in Jira: Jim White /secure/ViewProfile.jspa?name=jimwhite added a comment - 24/Apr/08 11:00 AM why don't you explain what we get from compiling private as package private? As it is atm, the class is at last correct from a Java view. Groovy currently destroys the Java class model by ignoring private scope. It is a big enough leap for many enterprises to accept dynamic typing as a change from standard Java static typing. But by making it impossible to have safely operating API implementations this issue alone will make Groovy a non-starter for many of them. Since there is a simple fix, and IMHO should have been done this way from the start rather than the hack against privacy, you need to defend why this should not be fixed and ASAP. [ Permalink/browse/GROOVY-1875?focusedCommentId=132503page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_132503 | « Hide ] Paul King /secure/ViewProfile.jspa?name=paulk added a comment - 24/Apr/08 11:28 AM - edited It is interesting to look at Jira stats. Top (9 votes) and equal 2nd (8 votes) issues: 9BugGROOVY-1875 private fields and private methods are not private 8 Improvement GROOVY-1591 Private Fields Are Accessible From Other Classes 8 Bug GROOVY-1063 No access protection for private static fields [ Permalink/browse/GROOVY-1875?focusedCommentId=132505page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_132505 | « Hide ] Jochen Theodorou /secure/ViewProfile.jspa?name=blackdrag added a comment - 24/Apr/08 12:09 PM - edited Jim you quoted my question, yet you don't answer it. Why is this? And I don't see your easy fix. Ok, let us assume we make private fields in*Groovy classes* package private, then why does this not violate the Java class model? You can still access the fields, nothing has changed. What could be done then is to avoid access to private fields in general, which would solve the access problem for String for example. But there are two drawbacks here. For example I always thought that package private excludes the access from subclasses, but they can access if they are in the same package. This means if we replace private with package private, then the field becomes visible where it was not visible before. This is incompatible to both Java and Groovy. Is see that much more as a danger for the class model than being able to access private. Because the ability of private as not being inherited remains untouched in current Groovy. making private package
Re: [xwiki-users] Security best practices for Xwiki deployment and management
Very useful tips. Thanks On 12/20/09, Niels Mayer nielsma...@gmail.com wrote: On Sat, Dec 19, 2009 at 5:49 AM, esdaniel xw...@esdaniel.com wrote: I asked Vincent if there was a security how-to / checklist page in the xwiki user guide and as such this does not yet exist. As security is such an important issue for public-facing sites, coupled with the fact that in order to help those who have to ensure they can carry out necessary due diligence on security before they are allowed to adopt solutions such as Xwiki, I'd like to request the help of the community to gather knowledge and best practices together. This thread is a request to gather information from experts and users alike to then create pages in the user guide that provide security guidance for administrators of public-facing Xwiki deployments (1) Have the java-web-server (e.g. tomcat) only accessible on localhost:8080 such that server configuration requires special access beyond port 80/443 seen by outside world (e.g. SSH tunnel : ssh -x -L 8080:localhost:8080 u...@host.com cat). This also enables java to not run as superuser -- having the smallest amount of new things running with privileges is what make sysadmins and security czars happy that they're not introducing new untested technology and new security holes into their fortress. (2) One of the well-understood parts of the sysadmin fortress is Apache httpd. Therefore, front the Xwiki-based website with Apache HTTPD and use mod_proxy_ajp to firewall the parts of the xwiki site you want exposed to the outside world on public ports (80/443) -- e.g. to access /xwiki use ProxyPass /xwiki/ajp://127.0.0.1:8009/xwiki/. With this in place you can use Apache to SSL-wrap access to a java based site, and potentially add further gating based on SSL-authentication (mod_ssl) and Apache basic auth (e.g. like the 2-factor authentication I setup for https://www.ipssources.com/ https://ipsssources.net ). You can also use Apache configurations to further limit or disable access to any parts of the wiki that aren't used or you don't want available to the public. E.g. /xwiki/webdav/ and /xwiki/admin/ might be limited to access from certain IPs, or only using SSL, etc. For additional level of protection (beyond Xwiki's auth gating users not having admin rights), one may want to block outside access to URL's like /xwiki/bin/export/XWiki/* to prevent access to hidden password data even if something breaks, or someone accidentally gives the wrong users, or guests admin or other rights that could compromise a xwiki based site. (3) No passwords in the clear: Use aforementioned Apache httpd gating to prevent access to /xwiki/bin/login/* unless user accessing via HTTPS. Depending on the level of security desired, the session can then remain in HTTPS entirely, or be redirected back to HTTP... It might be a good idea to further gate destructive operations (e.g. /xwiki/bin/admin/ ) so that they require an SSL login. This would at least force admins to not transmit the admin password for the site in the clear. (4) xwiki.cfg, etc. (i) change xwiki.authentication.validationKey and xwiki.authentication.encryptionKey; (ii) be sure xwiki.superadminpassword not set. (5) Initial XAR import of xwiki-enterprise-wiki-*.xar or on each upgrade importation: (i) After installing XAR from upgrade be sure to skip install of XWiki.Admin which will override the admin password you set for this user, setting it back to default/public password. (ii). Be sure to set a secure password for XWiki.Admin (iii). Those having imported from older 1.X xwikis may want to check to make sure XWiki.Admin doesn't have *XWiki.XWikiRights[1]* set with so that nonexistent user 'WikiWiki' can edit the 'XWiki.Admin' user. This could grant unexpected privileges to a wiki with open registration and no user XWiki.WikiWiki existing already. (iv) In /xwiki/bin/admin/XWiki/XWikiPreferences?editor=globaladminsection=Rights check Prevent unregistered users from editing pages, regardless of the page or space rights Niels http://nielsmayer.com ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users -- Sent from my mobile device ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Security best practices for Xwiki deployment and management
Thanks Niels, this is very helpful. A few questions... Re: #2 / #3 Forgive my lack of understanding here but how might this affect friendly URLs, if at all - what's best way to approach friendly URL config when following advice below? Niels Mayer wrote: (1) Have the java-web-server (e.g. tomcat) only accessible on localhost:8080 such that server configuration requires special access beyond port 80/443 seen by outside world (e.g. SSH tunnel : ssh -x -L 8080:localhost:8080 u...@host.com cat). This also enables java to not run as superuser -- having the smallest amount of new things running with privileges is what make sysadmins and security czars happy that they're not introducing new untested technology and new security holes into their fortress. (2) One of the well-understood parts of the sysadmin fortress is Apache httpd. Therefore, front the Xwiki-based website with Apache HTTPD and use mod_proxy_ajp to firewall the parts of the xwiki site you want exposed to the outside world on public ports (80/443) -- e.g. to access /xwiki use ProxyPass /xwiki/ajp://127.0.0.1:8009/xwiki/. With this in place you can use Apache to SSL-wrap access to a java based site, and potentially add further gating based on SSL-authentication (mod_ssl) and Apache basic auth (e.g. like the 2-factor authentication I setup for https://www.ipssources.com/ https://ipsssources.net ). You can also use Apache configurations to further limit or disable access to any parts of the wiki that aren't used or you don't want available to the public. E.g. /xwiki/webdav/ and /xwiki/admin/ might be limited to access from certain IPs, or only using SSL, etc. For additional level of protection (beyond Xwiki's auth gating users not having admin rights), one may want to block outside access to URL's like /xwiki/bin/export/XWiki/* to prevent access to hidden password data even if something breaks, or someone accidentally gives the wrong users, or guests admin or other rights that could compromise a xwiki based site. (3) No passwords in the clear: Use aforementioned Apache httpd gating to prevent access to /xwiki/bin/login/* unless user accessing via HTTPS. Depending on the level of security desired, the session can then remain in HTTPS entirely, or be redirected back to HTTP... It might be a good idea to further gate destructive operations (e.g. /xwiki/bin/admin/ ) so that they require an SSL login. This would at least force admins to not transmit the admin password for the site in the clear. (4) xwiki.cfg, etc. (i) change xwiki.authentication.validationKey and xwiki.authentication.encryptionKey; (ii) be sure xwiki.superadminpassword not set. (5) Initial XAR import of xwiki-enterprise-wiki-*.xar or on each upgrade importation: (i) After installing XAR from upgrade be sure to skip install of XWiki.Admin which will override the admin password you set for this user, setting it back to default/public password. (ii). Be sure to set a secure password for XWiki.Admin (iii). Those having imported from older 1.X xwikis may want to check to make sure XWiki.Admin doesn't have *XWiki.XWikiRights[1]* set with so that nonexistent user 'WikiWiki' can edit the 'XWiki.Admin' user. This could grant unexpected privileges to a wiki with open registration and no user XWiki.WikiWiki existing already. (iv) In /xwiki/bin/admin/XWiki/XWikiPreferences?editor=globaladminsection=Rights check Prevent unregistered users from editing pages, regardless of the page or space rights Niels http://nielsmayer.com -- View this message in context: http://n2.nabble.com/Security-best-practices-for-Xwiki-deployment-and-management-tp4191478p4197507.html Sent from the XWiki- Users mailing list archive at Nabble.com. ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
[xwiki-users] Security best practices for Xwiki deployment and management
Hi, I asked Vincent if there was a security how-to / checklist page in the xwiki user guide and as such this does not yet exist. As security is such an important issue for public-facing sites, coupled with the fact that in order to help those who have to ensure they can carry out necessary due diligence on security before they are allowed to adopt solutions such as Xwiki, I'd like to request the help of the community to gather knowledge and best practices together. This thread is a request to gather information from experts and users alike to then create pages in the user guide that provide security guidance for administrators of public-facing Xwiki deployments... where applicable we could link to security how-tos for Xwiki dependencies such as web application servers rather than duplicate well known information, feel free to share links you would recommend, please. Some of the questions I'm interested in are... * how-to 'harden' a xwiki site ** such as the correct access permissions for each file / folder object and permission lifecycle * what other dependencies should we ensure we have 'hardenend' ** such as Tomcat, Jetty, the DBs etc... and 'links to' or 'sub-pages in the wiki' on the essential tasks to carry out * ensuring the prevention of common attacks such as cross-site scripting and sql-injection ** is there a test suite we could use or introduce, such as Ronin written in Ruby, that would help us test that both xwiki and community plugins meet security standards we aim to achieve? There are various groups that focus on aspects of security we can study for guidance such as: http://www.owasp.org http://www.cloudsecurityalliance.org/guidance/ Please feel free to suggest others you feel offer professional and insightful guidance. Also, perhaps of interest is an example of a good working security team, I tip my hat to the Drupal security team who do an excellent job and here's an interesting post on that subject from the founder of Drupal: http://buytaert.net/drupal-security-team-past-current-and-future Thanks for reading and I sincerely hope this is of interest to the wider community of Xwiki and helps to gain further adoption and success for the Xwiki project. -- View this message in context: http://n2.nabble.com/Security-best-practices-for-Xwiki-deployment-and-management-tp4191478p4191478.html Sent from the XWiki- Users mailing list archive at Nabble.com. ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Security best practices for Xwiki deployment and management
On Sat, Dec 19, 2009 at 5:49 AM, esdaniel xw...@esdaniel.com wrote: I asked Vincent if there was a security how-to / checklist page in the xwiki user guide and as such this does not yet exist. As security is such an important issue for public-facing sites, coupled with the fact that in order to help those who have to ensure they can carry out necessary due diligence on security before they are allowed to adopt solutions such as Xwiki, I'd like to request the help of the community to gather knowledge and best practices together. This thread is a request to gather information from experts and users alike to then create pages in the user guide that provide security guidance for administrators of public-facing Xwiki deployments (1) Have the java-web-server (e.g. tomcat) only accessible on localhost:8080 such that server configuration requires special access beyond port 80/443 seen by outside world (e.g. SSH tunnel : ssh -x -L 8080:localhost:8080 u...@host.com cat). This also enables java to not run as superuser -- having the smallest amount of new things running with privileges is what make sysadmins and security czars happy that they're not introducing new untested technology and new security holes into their fortress. (2) One of the well-understood parts of the sysadmin fortress is Apache httpd. Therefore, front the Xwiki-based website with Apache HTTPD and use mod_proxy_ajp to firewall the parts of the xwiki site you want exposed to the outside world on public ports (80/443) -- e.g. to access /xwiki use ProxyPass /xwiki/ajp://127.0.0.1:8009/xwiki/. With this in place you can use Apache to SSL-wrap access to a java based site, and potentially add further gating based on SSL-authentication (mod_ssl) and Apache basic auth (e.g. like the 2-factor authentication I setup for https://www.ipssources.com/ https://ipsssources.net ). You can also use Apache configurations to further limit or disable access to any parts of the wiki that aren't used or you don't want available to the public. E.g. /xwiki/webdav/ and /xwiki/admin/ might be limited to access from certain IPs, or only using SSL, etc. For additional level of protection (beyond Xwiki's auth gating users not having admin rights), one may want to block outside access to URL's like /xwiki/bin/export/XWiki/* to prevent access to hidden password data even if something breaks, or someone accidentally gives the wrong users, or guests admin or other rights that could compromise a xwiki based site. (3) No passwords in the clear: Use aforementioned Apache httpd gating to prevent access to /xwiki/bin/login/* unless user accessing via HTTPS. Depending on the level of security desired, the session can then remain in HTTPS entirely, or be redirected back to HTTP... It might be a good idea to further gate destructive operations (e.g. /xwiki/bin/admin/ ) so that they require an SSL login. This would at least force admins to not transmit the admin password for the site in the clear. (4) xwiki.cfg, etc. (i) change xwiki.authentication.validationKey and xwiki.authentication.encryptionKey; (ii) be sure xwiki.superadminpassword not set. (5) Initial XAR import of xwiki-enterprise-wiki-*.xar or on each upgrade importation: (i) After installing XAR from upgrade be sure to skip install of XWiki.Admin which will override the admin password you set for this user, setting it back to default/public password. (ii). Be sure to set a secure password for XWiki.Admin (iii). Those having imported from older 1.X xwikis may want to check to make sure XWiki.Admin doesn't have *XWiki.XWikiRights[1]* set with so that nonexistent user 'WikiWiki' can edit the 'XWiki.Admin' user. This could grant unexpected privileges to a wiki with open registration and no user XWiki.WikiWiki existing already. (iv) In /xwiki/bin/admin/XWiki/XWikiPreferences?editor=globaladminsection=Rights check Prevent unregistered users from editing pages, regardless of the page or space rights Niels http://nielsmayer.com ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
