Wiki source code of Security

Version 9.1 by Ricardo Rodríguez on 2010/11/06

Show last authors
1 {{box cssClass="floatinginfobox" title="**Contents**"}}
2 {{toc/}}
3 {{/box}}
4
5 = Security related features =
6
7 XWiki offers some features for protecting security and some features which have security implications.
8
9 == Admin password ==
10
11 The default password for the Admin user is admin. Make sure you either change the password or remove that user.
12
13 == Superadmin account ==
14
15 XWiki provides a superadmin account. It is special, because:
16
17 * It is not stored in the database
18 * It cannot be modified in any way
19 * It always has full access, regardless of the rights settings
20
21 {{warning}}
22 Because it is so powerful, it is not safe to leave it enabled for a long time.
23 {{/warning}}
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## .
26
27 {{info}}
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.
29 {{/info}}
30
31 == Cookies ==
32
33 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.
34
35 === Cookie Encryption Keys ===
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
40 * //xwiki.authentication.validationKey//
41 * //xwiki.authentication.encryptionKey//
42
43 See: [[AdminGuide.Authentication#HAuthenticationparameters]]
44
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
47 === Encrypt cookies using IP address ===
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.
51
52 == Override version information ==
53
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
56 You can change the version string shown in the footer using the [[Administration Application>>code:Applications.AdministrationApplication]]. Click on ##Presentaton## icon and change the version string in the //Version// field.
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:
59
60 {{code}}
61 version=your version string here
62 {{/code}}
63
64
65 = Discussion of attack vectors =
66
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.
68
69 == Server root attacks ==
70
71 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.
72
73 === Likelihood / Known Issues ===
74
75 Not a very common attack method.
76
77 === Mitigation Methods ===
78
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.
81 * Don't run extraneous processes on the server
82 * Run services on non-standard ports (ssh)
83 * Firewall all ports not explicitly needed
84
85 == Java VM attacks ==
86
87 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.
88
89 === Likelihood / Known Issues ===
90
91 * 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
92 ** This attack method requires the use of a registered username which has programming permission.
93
94 === Mitigation Methods ===
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.
99
100 == Database Injection attacks ==
101
102 Such an attack happens from inside of unsafe scripting and results in unintended information being given up by the database.
103
104 === Likelihood / Known Issues ===
105
106 {{error}}
107 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]]
108 {{/error}}
109
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 ** This attack method may often be performed without a registered username.
112
113 === Mitigation Methods ===
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
117 {{code language="java"}}
118 {{groovy}}
119 try {
120 session = xcontext.getContext().getWiki().getHibernateStore().getSessionFactory().openSession();
121 session.connection().createStatement().execute("begin transaction; rollback;");
122 println("Your database supports stacked queries.")
123 } catch (Exception e) {
124 println("Your database does not support stacked queries.");
125 } finally {
126 try {
127 session.close()
128 } catch (Exception e) {}
129 }
130 {{/groovy}}
131 {{/code}}
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 **WRONG:**
138
139 {{code}}
140 #set($x = $xwiki.searchDocuments("where doc.fullName = '${userContent}'"))
141 {{/code}}
142
143 If the user enters: {{code}} ' or doc.hidden = 1 or doc.fullName = ' {{/code}}
144 Your code will create the Hibernate query:
145
146 {{code language="sql"}}
147 where doc.fullName = '' or doc.hidden = 1 or doc.fullName = ''
148 {{/code}}
149
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 Fortunately Hibernate itself protects against the worst type of injection such as:
152
153 {{code language="sql"}}
154 Embarrassing Mistake'); DROP TABLE xwikidoc;--
155 {{/code}}
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.)
158
159 **THE RIGHT WAY:**
160
161 {{code}}
162 ## We are passing a ? in the query and then passing the parameter as a list (Velocity notation for list is [element, element] )
163 #set($x = $xwiki.searchDocuments("where doc.fullName = ?", [$userContent]))
164 {{/code}}
165
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
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.
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
172
173 == Cross Site Scripting ==
174
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.
177
178 === Attack vectors (persistent injection) ===
179
180 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.
181
182 1. Persistent injection through XWiki document content by editing the document.
183 2. Persistent injecting through comments.
184
185 ==== Likelihood / Known Issues ====
186
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.)
190
191 ==== Mitigation Methods ====
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
195 {{code}}
196 {{html}}
197 $escapetool.html($userContent)
198 {{/html}}
199 {{/code}}
200
201 There are however some methods to minimize the risk:
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 === Attack vectors (reflective injection) ===
209
210 Reflective injection is characterized by convincing a user to click on a specially crafted link which causes a page to generate javascript.
211
212 1. Reflective injection through form fields.
213
214 ==== Mitigation Methods ====
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.
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]]
219
220 **WRONG:**
221
222 {{code language="xml"}}
223 <input type=text value="$request.get('name')" />
224 {{/code}}
225
226 **RIGHT:**
227
228 {{code language="xml"}}
229 <input type=text value="$escapetool.html($request.get('name'))" />
230 {{/code}}
231
232 == Cross site request forgery (CSRF) ==
233
234 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.
235
236 === Likelihood / Known Issues ===
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]]
239
240 === Mitigation Methods ===
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.

Get Connected