Summary

• Page properties (2 modified, 0 added, 0 removed)

Details

Page properties

Author

...	...	@@ -1,1 +1,1 @@
1		-XWiki.ManuelSmeria
	1	+XWiki.ThomasMortagne

Content

...	...	@@ -8,11 +8,14 @@
8	8
9	9	== Admin password ==
10	10
11		-The default password for the Admin user is admin. Make sure you either change the password or remove that user.
	11	+The default password for the Admin user is admin. Make sure you change the password.
12	12
	13	+You could also remove that user but first you need to make sure it's not used as author of any page as it might create issue otherwise (some standard pages require their author to have enough right to be taken into account).
	14	+
13	13	== Superadmin account ==
14	14
15	15	XWiki provides a superadmin account. It is special, because:
	18	+
16	16	* It is not stored in the database
17	17	* It cannot be modified in any way
18	18	* It always has full access, regardless of the rights settings
...	...	@@ -35,6 +35,7 @@
35	35
36	36	When a user logs in, three cookies are saved on his machine containing the username, password and a "nothing up my sleeve" hash. The cookies are encrypted so that nobody having access to them can see the username/password. This encryption is done using 2 configuration parameters located in the //xwiki.cfg// configuration file. This file is located in //WEB-INF/// in the XWiki WAR (see the [[Installation guide>>AdminGuide.Installation]] for where it's installed).
37	37	It's important you edit the //[[xwiki.cfg>>AdminGuide.Configuration#HSamplexwiki.cfg]]// file to modify the cookie authentication and encryption keys as they use default values when you install XWiki and these predefined values could be used by an attacker to decipher the username and password. To prevent this, change the following 2 configuration parameters:
	41	+
38	38	* //xwiki.authentication.validationKey//
39	39	* //xwiki.authentication.encryptionKey//
40	40
...	...	@@ -101,8 +101,7 @@
101	101
102	102	=== Mitigation Methods ===
103	103
104		-* You can use this groovy snippet to test your database to see if it supports [[stacked queries>>http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#StackingQueries]]. If your database does not support stacked queries, injection in a SELECT query can only lead to additional arbitrary SELECT queries:
105		-(((
	108	+* You can use this groovy snippet to test your database to see if it supports [[stacked queries>>http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#StackingQueries]]. If your database does not support stacked queries, injection in a SELECT query can only lead to additional arbitrary SELECT queries:(((
106	106	{{code language="java"}}
107	107	{{groovy}}
108	108	try {
...	...	@@ -172,15 +172,13 @@
172	172
173	173	==== Mitigation Methods ====
174	174
175		-* The only way to be sure that script cannot be injected in content (xwiki/1.0 or xwiki/2.0) is to make that content completely passive as follows:
176		-(((
	178	+* The only way to be sure that script cannot be injected in content (xwiki/1.0 or xwiki/2.0) is to make that content completely passive as follows:(((
177	177	{{code}}
178	178	{{html}}
179	179	$escapetool.html($userContent)
180	180	{{/html}}
181	181	{{/code}}
182		-)))
183		-There are however some methods to minimize the risk:
	184	+)))There are however some methods to minimize the risk:
184	184	* Disable creation of syntax 1.0 pages. **NOTE**: Pages which are already written in syntax 1.0 can still be altered and should be updated to syntax 2.0, otherwise they must have edit permission locked down so that only authorized users may edit them.
185	185	* Force unauthorized users to post through a script which escapes //~{~{// (double squigly brackets) because there is currently no way to prevent injection of html macro for unauthorized users.
186	186	* Set up ObservationManager to scan all page content and object property updates for HTML macro invocation and alert a moderator.