Summary

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

Details

Page properties

Content

...	...	@@ -1,12 +1,17 @@
1		-{{box cssClass="floatinginfobox" title="**Contents**"}}{{toc/}}{{/box}}
	1	+{{box cssClass="floatinginfobox" title="**Contents**"}}
	2	+{{toc/}}
	3	+{{/box}}
2	2
3	3	= Security related features =
	6	+
4	4	XWiki offers some features for protecting security and some features which have security implications.
5	5
6	6	== Admin password ==
	10	+
7	7	The default password for the Admin user is admin. Make sure you either change the password or remove that user.
8	8
9	9	== Superadmin account ==
	14	+
10	10	XWiki provides a superadmin account. It is special, because:
11	11
12	12	* It is not stored in the database
...	...	@@ -24,9 +24,11 @@
24	24	{{/info}}
25	25
26	26	== Cookies ==
	32	+
27	27	By default XWiki (as with most of the web) identifies users who have already logged in by setting cookies. These can be the target of attacks.
28	28
29	29	=== Cookie Encryption Keys ===
	36	+
30	30	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).
31	31	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:
32	32
...	...	@@ -38,6 +38,7 @@
38	38	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).
39	39
40	40	=== Encrypt cookies using IP address ===
	48	+
41	41	Even if the password cannot be extracted from the cookie, the cookies might be stolen See: [[XSS>>#Hcrosssitescripting]] and used as they are.
42	42	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.
43	43
...	...	@@ -55,15 +55,19 @@
55	55
56	56
57	57	= Discussion of attack vectors =
	66	+
58	58	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.
59	59
60	60	== Server root attacks ==
	70	+
61	61	This attack is characterized by assent of power in the operating system and is largely beyond the scope of this document as it is the responsibility of the operating system to prevent users ascending power.
62	62
63	63	=== Likelihood / Known Issues ===
	74	+
64	64	Not a very common attack method.
65	65
66	66	=== Mitigation Methods ===
	78	+
67	67	* Run a decent operating system
68	68	* 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.
69	69	* Don't run extraneous processes on the server
...	...	@@ -71,21 +71,26 @@
71	71	* Firewall all ports not explicitly needed
72	72
73	73	== Java VM attacks ==
	86	+
74	74	This attack is characterized by the attacker running arbitrary code on Java and perhaps using Java level security flaws to execute native code thus gaining access in the user level of the Java VM process.
75	75
76	76	=== Likelihood / Known Issues ===
	90	+
77	77	* XWiki requires reflection of private fields and variables for the [[component module>>code:Modules.ComponentModule]] 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
78	78	** This attack method requires the use of a registered username which has programming permission.
79	79
80	80	=== Mitigation Methods ===
	95	+
81	81	* Enable a SecurityManager which peeks at the calling stack and only allows unchecked reflection if called by the component manager.
82	82	* Disable Groovy entirely.
83	83	* Guard programming rights closely, have a special username just for saving documents which contain approved Groovy scripts.
84	84
85	85	== Database Injection attacks ==
	101	+
86	86	Such an attack happens from inside of unsafe scripting and results in unintended information being given up by the database.
87	87
88	88	=== Likelihood / Known Issues ===
	105	+
89	89	{{error}}
90	90	Versions older than [[Enterprise-2.2.6>>xwiki:Main.ReleaseNotesXWikiEnterprise226]] and [[Enterprise-2.3.0>>xwiki:Main.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:XWIKI%2D4755%2DescapeBackslashes.patch]] which was used to fix this issue and the [[security advisory>>http://lists.xwiki.org/pipermail/users/2010-April/020481.html]]
91	91	{{/error}}
...	...	@@ -94,9 +94,10 @@
94	94	** This attack method may often be performed without a registered username.
95	95
96	96	=== Mitigation Methods ===
	114	+
97	97	* 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.
98	98
99		-{{code language=java}}
	117	+{{code language="java"}}
100	100	{{groovy}}
101	101	try {
102	102	session = xcontext.getContext().getWiki().getHibernateStore().getSessionFactory().openSession();
...	...	@@ -112,7 +112,7 @@
112	112	{{/groovy}}
113	113	{{/code}}
114	114
115		-* 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.
	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.
116	116
117	117	* When designing scripts avoid the temptation to concatenate user input into database queries.
118	118
...	...	@@ -125,7 +125,7 @@
125	125	If the user enters: {{code}} ' or doc.hidden = 1 or doc.fullName = ' {{/code}}
126	126	Your code will create the Hibernate query:
127	127
128		-{{code language=sql}}
	146	+{{code language="sql"}}
129	129	where doc.fullName = '' or doc.hidden = 1 or doc.fullName = ''
130	130	{{/code}}
131	131
...	...	@@ -132,7 +132,7 @@
132	132	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.
133	133	Fortunately Hibernate itself protects against the worst type of injection such as:
134	134
135		-{{code language=sql}}
	153	+{{code language="sql"}}
136	136	Embarrassing Mistake'); DROP TABLE xwikidoc;--
137	137	{{/code}}
138	138
...	...	@@ -153,10 +153,12 @@
153	153	http://platform.xwiki.org/xwiki/bin/download/DevGuide/API/xwiki-core-2.0.5-javadoc.jar/index.html
154	154
155	155	== Cross Site Scripting ==
	174	+
156	156	Cross site scripting or XSS is the least harmful to the server of all attack methods, however it is the most common.
157	157	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	158
159	159	=== Attack vectors (persistent injection) ===
	179	+
160	160	Persistent injection is characterized by saving content in the system which when loaded by the unwitting user, executes as javascript in their browser. This is the more dangerous variety because it sits in a page waiting for a victim.
161	161
162	162	1. Persistent injection through XWiki document content by editing the document.
...	...	@@ -163,11 +163,13 @@
163	163	2. Persistent injecting through comments.
164	164
165	165	==== Likelihood / Known Issues ====
	186	+
166	166	* XWiki syntax 1.0 does not filter out HTML so script injection is possible
167	167	* 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
168	168	** This attack method requires the attacker have a registered username (unless anonymous editing or commenting is allowed.)
169	169
170	170	==== Mitigation Methods ====
	192	+
171	171	* 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.
172	172
173	173	{{code}}
...	...	@@ -177,17 +177,20 @@
177	177	{{/code}}
178	178
179	179	There are however some methods to minimize the risk:
	202	+
180	180	* 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
181	181	syntax 2.0, otherwise they must have edit permission locked down so that only authorized users may edit them.
182		-* 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.
	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.
183	183	* Set up ObservationManager to scan all page content and object property updates for HTML macro invocation, alert moderator.
184	184
185	185	=== Attack vectors (reflective injection) ===
	209	+
186	186	Reflective injection is characterized by convincing a user to click on a specially crafted link which causes a page to generate javascript.
187	187
188	188	1. Reflective injection through form fields.
189	189
190	190	==== Mitigation Methods ====
	215	+
191	191	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.
192	192
193	193	* 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]]
...	...	@@ -194,22 +194,24 @@
194	194
195	195	**WRONG:**
196	196
197		-{{code language=xml}}
	222	+{{code language="xml"}}
198	198	<input type=text value="$request.get('name')" />
199	199	{{/code}}
200	200
201	201	**RIGHT:**
202	202
203		-{{code language=xml}}
	228	+{{code language="xml"}}
204	204	<input type=text value="$escapetool.html($request.get('name'))" />
205	205	{{/code}}
206	206
207	207	== Cross site request forgery (CSRF) ==
	233	+
208	208	The basis of this attack is that a foreign website can craft a malicious link or form which points to the save action in your system and when clicked by a logged in user will cause the user to save the page.
209	209
210	210	=== Likelihood / Known Issues ===
	237	+
211	211	* 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]]
212	212
213	213	=== Mitigation Methods ===
214		-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.
215	215
	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.