Summary

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

Details

Page properties

Author

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

Content

...	...	@@ -13,16 +13,15 @@
13	13	== Superadmin account ==
14	14
15	15	XWiki provides a superadmin account. It is special, because:
16		-
17	17	* It is not stored in the database
18	18	* It cannot be modified in any way
19	19	* It always has full access, regardless of the rights settings
20	20
21	21	{{warning}}
22		-Because it is so powerful, it is not safe to leave it enabled for a long time.
	21	+Because the Superadmin account is so powerful, it is not safe to leave it enabled for a long time.
23	23	{{/warning}}
24	24
25		-By default, this account is disabled. To enable it, you have to edit ##<xwiki-dir>/WEB-INF/xwiki.cfg##, uncomment the ##xwiki.superadminpassword=system## line and set a proper password. To disable it, just comment this line. Remember to restart the servlet container after changing ##xwiki.cfg## .
	24	+By default, this account is disabled. To enable it, you have to edit ##<xwiki-dir>/WEB-INF/xwiki.cfg##, uncomment the ##xwiki.superadminpassword=system## line and set a proper password. To disable it, just comment this line. Remember to restart the servlet container after changing ##xwiki.cfg##.
26	26
27	27	{{info}}
28	28	Using this superadmin account is useful when you cannot log in anymore, for example when you forgot your admin user password, if you messed up some rights or if you have deleted your admin user by mistake.
...	...	@@ -34,34 +34,28 @@
34	34
35	35	=== Cookie Encryption Keys ===
36	36
37		-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>>AdminGuide.Installation]] for where it's installed).
38		-It's important you edit the //[[xwiki.cfg>>AdminGuide.Configuration#HSamplexwikiproperties]]// 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:
39		-
	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	+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:
40	40	* //xwiki.authentication.validationKey//
41	41	* //xwiki.authentication.encryptionKey//
42	42
43		-See: [[AdminGuide.Authentication#HAuthenticationparameters]]
	41	+See the [[Authentication parameters section>>AdminGuide.Authentication#HAuthenticationparameters]] for more details.
44	44
45	45	In future versions we'd like to generate random and host-dependent key pairs at installation time (see the following [[issue>>http://jira.xwiki.org/jira/browse/XWIKI-542]] for details).
46	46
47	47	=== Encrypt cookies using IP address ===
48	48
49		-Even if the password cannot be extracted from the cookie, the cookies might be stolen See: [[XSS>>#Hcrosssitescripting]] and used as they are.
50		-By setting the //[[xwiki.cfg>>AdminGuide.Configuration#HSamplexwikiproperties]]// parameter ##xwiki.authentication.useip## to true you can block the cookies from being used except by the same ip address which got them.
	47	+Even if the password cannot be extracted from the cookie, the cookies might be stolen (see [[XSS>>#HCrossSiteScripting]]) and used as they are.
	48	+By setting the //[[xwiki.cfg>>AdminGuide.Configuration#HSamplexwiki.cfg]]// parameter ##xwiki.authentication.useip## to true you can block the cookies from being used except by the same IP address which got them.
51	51
52	52	== Override version information ==
53	53
54	54	By default, the exact XWiki Enterprise version is shown in the footer of every page. This is not harmful by itself, but can provide useful information to the attacker, who can use known vulnerabilities against this version.
55	55
56		-You can change the version string shown in the footer using the [[Administration Application>>extensions:Extension.Administration Application]]. Click on ##Presentaton## icon and change the version string in the //Version// field.
	54	+You can change the version string shown in the footer using the [[Administration Application>>extensions:Extension.Administration Application]]. Click on the ##Presentaton## icon and change the version string in the //Version// field.
57	57
58		-If you want to be sure the version is definitely not leaked somewhere else, you can replace the file //WEB-INF/version.properties// by your own version with the following content:
	56	+If you want to be sure the version is definitely not leaked somewhere else, you can replace the file //WEB-INF/version.properties// by your own version with the following content: {{code}}version=your version string here{{/code}}.
59	59
60		-{{code}}
61		-version=your version string here
62		-{{/code}}
63		-
64		-
65	65	= Discussion of attack vectors =
66	66
67	67	Perfect security is generally considered impossible. With simple static HTML servers we can have near perfect security but those are not very useful. This document discusses different threat models and how to fortify against each. These attacks are grouped by type of access gained if successful. More dangerous attacks are near the top yet the most common attacks are less dangerous (and easier to perform) and will be seen at the bottom.
...	...	@@ -77,7 +77,7 @@
77	77	=== Mitigation Methods ===
78	78
79	79	* Run a decent operating system
80		-* Run the Java VM with XWiki under it's own username, only give this user permissions to files needed for the operation of XWiki, make sure this user doesn't have sudo access.
	73	+* Run the Java VM with XWiki under its own username, only give this user permissions to files needed for the operation of XWiki and make sure this user doesn't have sudo access
81	81	* Don't run extraneous processes on the server
82	82	* Run services on non-standard ports (ssh)
83	83	* Firewall all ports not explicitly needed
...	...	@@ -88,14 +88,14 @@
88	88
89	89	=== Likelihood / Known Issues ===
90	90
91		-* XWiki requires reflection of private fields and variables for the [[component module>>extensions:Extension.Component Module]] This means that jsr223 scripts such as Groovy and Python are able to read and write any field or variable in the system which may lead to execution of native code via Java Native Access. Virtual wikis are not insulated against this attack method and as such virtual wiki administrators cannot be given programming permission (Note that there is another reason for not giving wiki admin programming rights in a farm, it is because you may access any document without rights being checked, even in another wiki). This flaw could lead to dumping of connected databases, however user passwords are SHA-512 hashed. See: http://jira.codehaus.org/browse/GROOVY-1875
92		-** This attack method requires the use of a registered username which has programming permission.
	84	+* XWiki requires reflection of private fields and variables for the [[component module>>extensions:Extension.Component Module]] This means that jsr223 scripts such as Groovy and Python are able to read and write any field or variable in the system which may lead to execution of native code via Java Native Access. Virtual wikis are not insulated against this attack method and as such virtual wiki administrators cannot be given programming permission (note that there is another reason for not giving wiki admin programming rights in a farm, it is because you may access any document without rights being checked, even in another wiki). This flaw could lead to dumping of connected databases, however user passwords are SHA-512 hashed (see [[this issue>>http://jira.codehaus.org/browse/GROOVY-1875]] for more details.
	85	+** This attack method requires the use of a registered username which has programming rights
93	93
94	94	=== Mitigation Methods ===
95	95
96		-* Enable a SecurityManager which peeks at the calling stack and only allows unchecked reflection if called by the component manager.
97		-* Disable Groovy entirely.
98		-* Guard programming rights closely, have a special username just for saving documents which contain approved Groovy scripts.
	89	+* Enable a SecurityManager which peeks at the calling stack and only allows unchecked reflection if called by the component manager
	90	+* Disable Groovy entirely
	91	+* Guard programming rights closely, have a special username just for saving documents which contain approved Groovy scripts
99	99
100	100	== Database Injection attacks ==
101	101
...	...	@@ -103,17 +103,13 @@
103	103
104	104	=== Likelihood / Known Issues ===
105	105
106		-{{error}}
107		-Versions older than [[Enterprise-2.2.6>>xwiki:ReleaseNotes.ReleaseNotesXWikiEnterprise226]] and [[Enterprise-2.3.0>>xwiki:ReleaseNotes.ReleaseNotesXWikiEnterprise23]] are susceptible to SQL injection through the $xwiki.search and $xwiki.searchDocuments functions. This means that logged in users are able to finish a query with native SQL and run other queries if the database supports stacked queries. See: the [[patch>>attach:XWIKI4755escapeBackslashes.patch]] which was used to fix this issue and the [[security advisory>>http://lists.xwiki.org/pipermail/users/2010-April/020481.html]]
108		-{{/error}}
109		-
110	110	* XWiki uses Hibernate as a database controller so some of the injection methods are mitigated. XWiki gives you the capability to create safe scripts and unsafe scripts.
111	111	** This attack method may often be performed without a registered username.
112	112
113	113	=== Mitigation Methods ===
114	114
115		-* 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.
116		-
	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	+(((
117	117	{{code language="java"}}
118	118	{{groovy}}
119	119	try {
...	...	@@ -129,11 +129,10 @@
129	129	}
130	130	{{/groovy}}
131	131	{{/code}}
	121	+)))
	122	+* Configure your database to log or if possible disable comment syntax {{code language="none"}} -- /* */ and # {{/code}}. Comments are not used by Hibernate and are central to most of the more dangerous SQL injection.
	123	+* When designing scripts avoid the temptation to concatenate user input into database queries
132	132
133		-* Configure your database to log or if possible disable comment syntax {{code language="none"}} -- /* */ and # {{/code}} comments are not used by Hibernate and are central to most of the more dangerous SQL injection.
134		-
135		-* When designing scripts avoid the temptation to concatenate user input into database queries.
136		-
137	137	**WRONG:**
138	138
139	139	{{code}}
...	...	@@ -140,13 +140,8 @@
140	140	#set($x = $xwiki.searchDocuments("where doc.fullName = '${userContent}'"))
141	141	{{/code}}
142	142
143		-If the user enters: {{code}} ' or doc.hidden = 1 or doc.fullName = ' {{/code}}
144		-Your code will create the Hibernate query:
	131	+If the user enters: {{code}} ' or doc.hidden = 1 or doc.fullName = ' {{/code}} your code will create the Hibernate query: {{code language="sql"}}where doc.fullName = '' or doc.hidden = 1 or doc.fullName = ''{{/code}}.
145	145
146		-{{code language="sql"}}
147		-where doc.fullName = '' or doc.hidden = 1 or doc.fullName = ''
148		-{{/code}}
149		-
150	150	This may not be a horrible outcome but it is not what you wanted and others surely can invent far more dangerous injections than this.
151	151	Fortunately Hibernate itself protects against the worst type of injection such as:
152	152
...	...	@@ -154,9 +154,9 @@
154	154	Embarrassing Mistake'); DROP TABLE xwikidoc;--
155	155	{{/code}}
156	156
157		-This is because it does not allow multiple commands in one call and does not allow the ~-~- comment syntax. (Can be bypassed in some versions, see above.)
	140	+This is because it does not allow multiple commands in one call and does not allow the ~-~- comment syntax (can be bypassed in some versions; see above).
158	158
159		-**THE RIGHT WAY:**
	142	+**RIGHT:**
160	160
161	161	{{code}}
162	162	## We are passing a ? in the query and then passing the parameter as a list (Velocity notation for list is [element, element] )
...	...	@@ -165,15 +165,14 @@
165	165
166	166	Your code will now instruct Hibernate to name the userContent parameter and pass it to the database separately from the query. The above injection trick will not work.
167	167
168		-* Avoid "Privileged API" whenever possible and only use non API when absolutely necessary. If your each of your calls to require you to pass the context as a parameter, your doing it wrong.
	151	+* Avoid "Privileged API" whenever possible and only use non API when absolutely necessary. If each of your calls requires you to pass the context as a parameter, you're doing it wrong.
169	169
170		-The API for reference:
171		-http://platform.xwiki.org/xwiki/bin/download/DevGuide/API/xwiki-core-2.0.5-javadoc.jar/index.html
	153	+For more information check the [[XWiki API Reference>>http://platform.xwiki.org/xwiki/bin/view/DevGuide/API]].
172	172
173	173	== Cross Site Scripting ==
174	174
175	175	Cross site scripting or XSS is the least harmful to the server of all attack methods, however it is the most common.
176		-XSS can lead to users altering documents which they didn't want to or having their authentication cookies copied. XSS can also lead to exploitation of web browsers and plugins such as pdf or activex. Such exploits often install malware.
	158	+XSS can lead to users altering documents which they didn't want to or having their authentication cookies copied. XSS can also lead to exploitation of web browsers and plugins such as pdf or ActiveX. Such exploits often install malware.
177	177
178	178	=== Attack vectors (persistent injection) ===
179	179
...	...	@@ -185,26 +185,24 @@
185	185	==== Likelihood / Known Issues ====
186	186
187	187	* XWiki syntax 1.0 does not filter out HTML so script injection is possible
188		-* XWiki syntax 2.0 contains html macro which when invoked allows injection of raw html and script. There is still no safe way to disable this. See: http://jira.xwiki.org/jira/browse/XWIKI-3953
189		-** This attack method requires the attacker have a registered username (unless anonymous editing or commenting is allowed.)
	170	+* XWiki syntax 2.0 contains html macro which when invoked allows injection of raw html and script. There is still no safe way to disable this (see [[this issue>>http://jira.xwiki.org/jira/browse/XWIKI-3953]] for more information.
	171	+** This attack method requires the attacker to have a registered username (unless anonymous editing or commenting is allowed).
190	190
191	191	==== Mitigation Methods ====
192	192
193		-* 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.
194		-
	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	+(((
195	195	{{code}}
196	196	{{html}}
197	197	$escapetool.html($userContent)
198	198	{{/html}}
199	199	{{/code}}
200		-
	182	+)))
201	201	There are however some methods to minimize the risk:
	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	+* 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	+* Set up ObservationManager to scan all page content and object property updates for HTML macro invocation and alert a moderator.
202	202
203		-* 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
204		- syntax 2.0, otherwise they must have edit permission locked down so that only authorized users may edit them.
205		-* 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.
206		-* Set up ObservationManager to scan all page content and object property updates for HTML macro invocation, alert moderator.
207		-
208	208	=== Attack vectors (reflective injection) ===
209	209
210	210	Reflective injection is characterized by convincing a user to click on a specially crafted link which causes a page to generate javascript.
...	...	@@ -213,9 +213,9 @@
213	213
214	214	==== Mitigation Methods ====
215	215
216		-Advise admins to use addons such as [[noscript>>https://addons.mozilla.org/en-US/firefox/addon/722]] which will detect reflective injection attacks and warn the user when it suspects foul play, also avoid clicking on suspicious links.
	196	+Advise admins to use addons such as [[noscript>>https://addons.mozilla.org/en-US/firefox/addon/noscript/]] which will detect reflective injection attacks and warn the user when it suspects foul play and also avoid clicking on suspicious links.
217	217
218		-* when content is loaded from request parameters into a form field, make sure it is escaped using [[$escapetool.html>>http://velocity.apache.org/tools/devel/generic/EscapeTool.html]]
	198	+* when content is loaded from request parameters into a form field, make sure it is escaped using [[EscapeTool>>http://velocity.apache.org/tools/devel/generic/EscapeTool.html]]
219	219
220	220	**WRONG:**
221	221
...	...	@@ -235,8 +235,8 @@
235	235
236	236	=== Likelihood / Known Issues ===
237	237
238		-* Currently there is no system implemented to prevent form submission from external sites. See discussion in mailing list about implementing [[secret tokens>>http://lists.xwiki.org/pipermail/devs/2010-March/017727.html]]
	218	+Currently there is no system implemented to prevent form submission from external sites. See discussion in mailing list about implementing [[secret tokens>>http://lists.xwiki.org/pipermail/devs/2010-March/017727.html]].
239	239
240	240	=== Mitigation Methods ===
241	241
242		-Advise admins to use addons such as [[noscript>>https://addons.mozilla.org/en-US/firefox/addon/722]] which will help prevent automatic form submission by an attack site, also avoid clicking on suspicious links.
	222	+Advise admins to use addons such as [[noscript>>https://addons.mozilla.org/en-US/firefox/addon/noscript/]] which will help prevent automatic form submission by an attack site and also avoid clicking on suspicious links.