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 [email protected] 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=globaladmin§ion=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-manage... Sent from the XWiki- Users mailing list archive at Nabble.com.

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.0<http://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=132503&page=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: 9 Bug GROOVY-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=132505&page=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 private means also that any Java class in the same package can access the fields with pure Java.By this you can bypass properties, even if it was not your intention. Of course you can do the same in Groovy, even today, but at last for Groovy you have to enforce it if you want to bypass the getter/setter method calls. I see this as a much bigger problem from the Java side, than the Groovy side, because Java is the language that tries to enforce these things. And there is one more thing to say to a possible fix. "package private"as well as protected are handled like public atm. That is not only by the compiler, but also by the runtime the case. Making the private fields "package private" means a major change to the way the runtime handles inheritance of fields for one, but also you would need to discover such an access and forbid it. While not a problem for private, any check to "package private" is doomed to be not done unless private is implemented "correctly". Such changes are affected the semantics in this area in extreme ways. I am pretty sure I won't do such a change in the 1.x series, because it is simply too much. Doing such a change now means to make a 2.x line and ones it has been fixed it would be a 3.x line. Also, as for testing purposes, meaning writing unit test for Java or Groovy code, it makes sense to allow access to private. For me Closures accessing private fields and testing are the main reasons why this issue was not yet solved. A complete fix for this issue needs several incompatible changes to the MOP and that means it won't be done before 2.0. And that is the reason why I set the fix target to 2.0 here. A complete fix does not only include field access, but also method acceess. I know many partial solutions to the problem, but a partial solution will not do. I think a false but consistent solution is much better than inconsistent changes and also not completely correct ones (there would be no need for further changes if they were completely correct), that do change the way Groovy behaves with probably each version. If you think your solution does do the job, then I suggest you do a fix and we discuss the implications of it. Sometimes a case seems rather different if there is prominent evidence. [ Permalink</browse/GROOVY-1875?focusedCommentId=132508&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_132508> | « Hide ] Jim White </secure/ViewProfile.jspa?name=jimwhite> added a comment - 24/Apr/08 12:45 PM - edited *The Java-Groovy Privacy Manifesto* 1) Groovy must respect 'private' scope. To do otherwise is in total conflict with it's groovy nature of being the best scripting language for Java. 2) The issue that some thought was preventing #1, and is reflected in the current implementation, is the compilation of closures. 3) The easy and correct fix (and the solution used by Java for inner classes) for #2 is to make private members of Groovy classes that need to be accessed by it's closures accessible using package scope. 4) The current Groovy compiler implementation probably makes it difficult to know exactly which private members are accessed by the relevant closures. 5) The conclusion of #4 and #5 is that the correct, easy, and reliable fix is to compile all private members of Groovy classes as package scoped in the bytecode. 6) The change in member visibility from a Groovy perspective for Groovy classes is unchanged. 7) The change in member visibility from a Java perspective for Groovy classes is unchanged, *except* for Java classes in the same package as Groovy classes. The only difference being that such Java code has access to Groovy 'private' members (which are already *only* private from Java code, never from Groovy code). 8) #7 is a *huge* improvement in the class integrity situation. 9) The Java-code-in-same-package-access-to-Groovy-private-members exception of #7 is only even true for Java code that is linked to*precompiled* Groovy classes. For those that use the unified Java-Groovy compiler, private members need not be visible. 10) Respecting private scope of *all* Java bytecode and compiling Groovy 'private' members as package scope in the bytecode is giant step forward in making Groovy consistent with the Java platform and should be done in 1.6x. --------------------- finally, previously [email protected] asked:

Re: #2 / #3Forgive 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?

I'm not sure what you mean by a "friendly URL." Do you mean a URL that doesn't specify a nonstandard port, e.g. http://x.com:8080/foo vs http://x.com/foo ? <http://jira.codehaus.org/browse/GROOVY-1875> Niels http://nielsmayer.com