-
Notifications
You must be signed in to change notification settings - Fork 9
/
security.html
689 lines (635 loc) · 38.6 KB
/
security.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<!--
Copyright (C) 2005, 2006 Joe Walnes.
Copyright (C) 2006, 2007, 2008, 2021 XStream committers.
All rights reserved.
The software in this package is published under the terms of the BSD
style license a copy of which has been included with this distribution in
the LICENSE.txt file.
Created on 29. January 2005 by Joe Walnes
-->
<head>
<title>XStream - Security Aspects</title>
<link rel="stylesheet" type="text/css" href="style.css"/>
<!-- Google analytics -->
<script src="http://www.google-analytics.com/urchin.js" type="text/javascript">
</script>
<script type="text/javascript">
_uacct = "UA-110973-2";
urchinTracker();
</script>
</head>
<body>
<div id="banner">
<a href="index.html"><img id="logo" src="logo.gif" alt="XStream"/></a>
</div>
<div id="center" class="Content2Column"> <!-- Content3Column for index -->
<div id="content">
<h1 class="FirstChild">Security Aspects</h1>
<p>XStream is designed to be an easy to use library. It takes its main task seriously: converting Java objects to
XML, and XML to Java objects. As a result, it is possible to create an instance of XStream with the default
constructor, call a method to convert an object into XML, then call another method to turn the XML back into an
equivalent Java object. By design, there are few limits to the type of objects XStream can handle.</p>
<p>This flexibility comes at a price. XStream applies various techniques under the hood to ensure it is able to
handle all types of objects. This includes using undocumented Java features and reflection. The XML generated by
XStream includes all information required to build objects of almost any type. This introduces a potential
security problem.</p>
<p>The provided XML data is used by XStream to unmarshal Java objects. This data can be manipulated by injecting
the XML representation of other objects, that were not present at marshalling time. An attacker could take
advantage of this to access private data, delete local files, execute arbitrary code or shell commands in the
context of the server running the XStream process or cause a denial of service by crashing the application or
manage to enter an endless loop consuming 100% of CPU cycles.</p>
<p class=highlight>Note: XStream supports other data formats than XML, e.g. JSON. Those formats can usually be used
for the same attacks.</p>
<p>The XML data can be manipulated on different levels. For example, manipulating values on existing objects (such
as a price value), accessing private data, or breaking the format and causing the XML parser to fail. The latter
case will raise an exception, but the former case must be handled by validity checks in any application which
processes user-supplied XML.</p>
<h2 id="CVEs">Documented Vulnerabilities</h2>
<p>Over the years, several of these attacks have been reported and documented in the Common Vulnerability and
Exposure (CVE) system managed by the <a href="http://www.mitre.org/">Mitre Corporation</a>. Following a list of the
reported vulnerabilities for the different versions:</p>
<table summary="Table of reported vulnerabilities documented as CVE">
<tr>
<th>CVE</th>
<th>Description</th>
</tr>
<tr>
<th>Version 1.4.21</th>
<td></td>
</tr>
<tr>
<th><a href="CVE-2024-47072.html">CVE-2024-47072</a></th>
<td>XStream is vulnerable to a Denial of Service attack due to stack overflow from a manipulated binary input
stream.</td>
</tr>
<tr>
<th>Version 1.4.19</th>
<td></td>
</tr>
<tr>
<th><a href="CVE-2022-41966.html">CVE-2022-41966</a></th>
<td>XStream can cause a Denial of Service by injecting recursive collections or maps based on element's hash
values raising a stack overflow.</td>
</tr>
<tr>
<th><a href="CVE-2022-40151.html">CVE-2022-40151</a></th>
<td>XStream can cause a Denial of Service by injecting deeply nested objects raising a stack overflow.</td>
</tr>
<tr>
<th>CVE-2022-40152 to CVE-2022-40156</th>
<td>Although unconfirmed these issues had been assigned to XStream nonetheless. However, all these issues are
caused by the same problem in Woodstox. Therefore <a href="https://nvd.nist.gov/vuln/detail/CVE-2022-40152">
CVE-2022-40152</a> has been officially reassigned and the other CVEs have been revoked.</td>
</tr>
<tr>
<th>Version 1.4.18</th>
<td></td>
</tr>
<tr>
<th><a href="CVE-2021-43859.html">CVE-2021-43859</a></th>
<td>XStream can cause a Denial of Service by injecting highly recursive collections or maps.</td>
</tr>
<tr>
<th>Version 1.4.17</th>
<td></td>
</tr>
<tr>
<th><a href="CVE-2021-39139.html">CVE-2021-39139</a></th>
<td>XStream is vulnerable to an Arbitrary Code Execution attack.</td>
</tr>
<tr>
<th><a href="CVE-2021-39140.html">CVE-2021-39140</a></th>
<td>XStream can cause a Denial of Service.</td>
</tr>
<tr>
<th><a href="CVE-2021-39141.html">CVE-2021-39141</a></th>
<td>XStream is vulnerable to an Arbitrary Code Execution attack.</td>
</tr>
<tr>
<th><a href="CVE-2021-39144.html">CVE-2021-39144</a></th>
<td>XStream is vulnerable to a Remote Command Execution attack.</td>
</tr>
<tr>
<th><a href="CVE-2021-39145.html">CVE-2021-39145</a></th>
<td>XStream is vulnerable to an Arbitrary Code Execution attack.</td>
</tr>
<tr>
<th><a href="CVE-2021-39146.html">CVE-2021-39146</a></th>
<td>XStream is vulnerable to an Arbitrary Code Execution attack.</td>
</tr>
<tr>
<th><a href="CVE-2021-39147.html">CVE-2021-39147</a></th>
<td>XStream is vulnerable to an Arbitrary Code Execution attack.</td>
</tr>
<tr>
<th><a href="CVE-2021-39148.html">CVE-2021-39148</a></th>
<td>XStream is vulnerable to an Arbitrary Code Execution attack.</td>
</tr>
<tr>
<th><a href="CVE-2021-39149.html">CVE-2021-39149</a></th>
<td>XStream is vulnerable to an Arbitrary Code Execution attack.</td>
</tr>
<tr>
<th><a href="CVE-2021-39150.html">CVE-2021-39150</a></th>
<td>A Server-Side Forgery Request can be activated unmarshalling with XStream to access data streams from an
arbitrary URL referencing a resource in an intranet or the local host.</td>
</tr>
<tr>
<th><a href="CVE-2021-39151.html">CVE-2021-39151</a></th>
<td>XStream is vulnerable to an Arbitrary Code Execution attack.</td>
</tr>
<tr>
<th><a href="CVE-2021-39152.html">CVE-2021-39152</a></th>
<td>A Server-Side Forgery Request can be activated unmarshalling with XStream to access data streams from an
arbitrary URL referencing a resource in an intranet or the local host.</td>
</tr>
<tr>
<th><a href="CVE-2021-39153.html">CVE-2021-39153</a></th>
<td>XStream is vulnerable to an Arbitrary Code Execution attack.</td>
</tr>
<tr>
<th><a href="CVE-2021-39154.html">CVE-2021-39154</a></th>
<td>XStream is vulnerable to an Arbitrary Code Execution attack.</td>
</tr>
<tr>
<th>Version 1.4.16</th>
<td></td>
</tr>
<tr>
<th><a href="CVE-2021-29505.html">CVE-2021-29505</a></th>
<td>XStream is vulnerable to a Remote Command Execution attack.</td>
</tr>
<tr>
<th>Version 1.4.15</th>
<td></td>
</tr>
<tr>
<th><a href="CVE-2021-21341.html">CVE-2021-21341</a></th>
<td>XStream can cause a Denial of Service.</td>
</tr>
<tr>
<th><a href="CVE-2021-21342.html">CVE-2021-21342</a></th>
<td>A Server-Side Forgery Request can be activated unmarshalling with XStream to access data streams from an
arbitrary URL referencing a resource in an intranet or the local host.</td>
</tr>
<tr>
<th><a href="CVE-2021-21343.html">CVE-2021-21343</a></th>
<td>XStream is vulnerable to an Arbitrary File Deletion on the local host when unmarshalling as long as the
executing process has sufficient rights.</td>
</tr>
<tr>
<th><a href="CVE-2021-21344.html">CVE-2021-21344</a></th>
<td>XStream is vulnerable to an Arbitrary Code Execution attack.</td>
</tr>
<tr>
<th><a href="CVE-2021-21345.html">CVE-2021-21345</a></th>
<td>XStream is vulnerable to a Remote Command Execution attack.</td>
</tr>
<tr>
<th><a href="CVE-2021-21346.html">CVE-2021-21346</a></th>
<td>XStream is vulnerable to an Arbitrary Code Execution attack.</td>
</tr>
<tr>
<th><a href="CVE-2021-21347.html">CVE-2021-21347</a></th>
<td>XStream is vulnerable to an Arbitrary Code Execution attack.</td>
</tr>
<tr>
<th><a href="CVE-2021-21348.html">CVE-2021-21348</a></th>
<td>XStream is vulnerable to an attack using Regular Expression for a Denial of Service (ReDos).</td>
</tr>
<tr>
<th><a href="CVE-2021-21349.html">CVE-2021-21349</a></th>
<td>A Server-Side Forgery Request can be activated unmarshalling with XStream to access data streams from an
arbitrary URL referencing a resource in an intranet or the local host.</td>
</tr>
<tr>
<th><a href="CVE-2021-21350.html">CVE-2021-21350</a></th>
<td>XStream is vulnerable to an Arbitrary Code Execution attack.</td>
</tr>
<tr>
<th><a href="CVE-2021-21351.html">CVE-2021-21351</a></th>
<td>XStream is vulnerable to an Arbitrary Code Execution attack.</td>
</tr>
<tr>
<th>Version 1.4.14</th>
<td></td>
</tr>
<tr>
<th><a href="CVE-2020-26258.html">CVE-2020-26258</a></th>
<td>A Server-Side Forgery Request can be activated unmarshalling with XStream to access data streams from an
arbitrary URL referencing a resource in an intranet or the local host.</td>
</tr>
<tr>
<th><a href="CVE-2020-26259.html">CVE-2020-26259</a></th>
<td>XStream is vulnerable to an Arbitrary File Deletion on the local host when unmarshalling as long as the
executing process has sufficient rights.</td>
</tr>
<tr>
<th>Version 1.4.13</th>
<td></td>
</tr>
<tr>
<th><a href="CVE-2020-26217.html">CVE-2020-26217</a></th>
<td>XStream can be used for Remote Code Execution.</td>
</tr>
<tr>
<th>Version 1.4.9</th>
<td></td>
</tr>
<tr>
<th><a href="CVE-2017-7957.html">CVE-2017-7957</a></th>
<td>XStream can cause a Denial of Service when unmarshalling void.</td>
</tr>
<tr>
<th>Version 1.4.8</th>
<td></td>
</tr>
<tr>
<th><a href="CVE-2016-3674.html">CVE-2016-3674</a></th>
<td>XML External Entity (XXE) Vulnerability in XStream.</td>
</tr>
<tr>
<th>Version 1.4.6 (and 1.4.10)</th>
<td></td>
</tr>
<tr>
<th><a href="CVE-2013-7285.html">CVE-2013-7285</a></th>
<td>XStream can be used for Remote Code Execution.</td>
</tr>
</table>
<p>See <a href="#workaround">workarounds</a> for the different versions covering all the CVEs listed here.</p>
<p class="hightlight">This list contains only vulnerabilities, that could be created using the Java runtime with
XStream. Vulnerabilities introduced by using additional 3rd party libraries and classes are beyond XStream's
responsibility.</p>
<h2 id="external">External Security</h2>
<p>An active Java Security Manager can prevent actions required by XStream components or converters. The same
applies to environments such as Google Application Engine. XStream tries to some extent to check the functionality
of a converter before it claims to handle a type.</p>
<p>Therefore it is possible that XStream behaves differently in such an environment, because a converter suddenly
no longer handles a special type or any type at all. It is essential that an application that will have to run in
such an environment is tested at an early stage to prevent nasty surprises.</p>
<h2 id="implicit">Implicit Security</h2>
<p>As explained above, it is possible to inject other object instances if an attacker is able to define the data
used to deserialize the Java objects, see the different CVEs. Knowing how to define such an attack is the only
prerequisite.</p>
<p>All those scenarios were based on types that are delivered with the Java runtime at some version. Looking at
other well-known and commonly used Java libraries libraries such as ASM, CGLIB, or Groovy, you will have to assume
other scenarios for exploits as well. A class like InvokerTransformer of Apache Commons Collections has a high
potential for attacks. By default XStream 1.4.18 works now with a whitelist. If you modify the default setup, it
is also your responsibility to protect your clients from such vulnerabilities.</p>
<p>Note: This vulnerability is not even a special problem of XStream. XML being deserialized by XStream acts here
like a script, and the scenario above can be created with any script that is executed within a Java runtime (e.g.
using its JavaScript interpreter) if someone is able to manipulate it externally. The key message for application
developers is that deserializing arbitrary user-supplied content is a dangerous proposition in all cases. The best
approach to prevent such an attach is a <a href="#example">whitelist</a>, i.e. the deserialization mechanism should
only allow explicit types. See also the advice for vulnerabilities using
<a href="https://docs.oracle.com/javase/10/core/serialization-filtering1.htm">Java Serialization</a>.</p>
<p class="hightlight">A blacklist for special classes only creates therefore a scenario for a false security,
because no-one can assure, that no other vulnerability is found. A better approach is the usage of a whitelist
i.e. the allowed class types are setup explicitly. This is the default for XStream 1.4.18 (see below).</p>
<p>XStream supports references to objects already occuring on the object graph in an earlier location. This allows
an attacker to create a highly recursive object structure. Some collections or maps calculate the position of a
member based on the data of the member itself. This is true for sorting collections or maps, but also for
collections or maps based on the hash code of the individual members. The calculation time for the member's
position can increase exponentially depending on the recursive depth of the structure and cause therefore a Denial
of Service. Therefore XStream measures the time consumed to add an element to a collection or map since version
1.4.19. Normally this operation is performed in a view milliseconds, but if adding elements take longer than a
second, then the time is accumulated and an exception is thrown if it exceeds a definable limit (20 seconds by
default).</p>
<h2 id="explicit">Explicit Security</h2>
<p>Starting with XStream 1.4.7, it is possible to define <a href="#framework">permissions</a> for types, to check
the type of an object that should be unmarshalled. Those permissions can be used to allow or deny types explicitly
With these permissions it is at least not possible to inject unexpected types into an object graph. The security
framework supports the setup of a blacklist or whitelist scenario. Any application should use this feature to
limit the danger of arbitrary command execution if it deserializes data from an external source.</p>
<p>XStream itself sets up a whitelist by default, i.e. it blocks all classes except those types it has explicit
converters for. Until version 1.4.17 it used a blacklist by default, i.e. it tried to block all currently known
critical classes of the Java runtime. Main reason for the blacklist were compatibility, it allowed to use newer
versions of XStream as drop-in replacement. However, this approach has failed. A growing list of security reports
has proven, that a blacklist is inherently unsafe, apart from the fact that types of 3rd libraries were not even
considered. XStream provides the ability to setup a whitelist since version 1.4.7, a version released nine years
before 1.4.18. Clients who have adapted their setup and initialize the security framework are able to use newer
versions again as drop-in replacement. A blacklist scenario should be avoided in general, because it provides a
false sense of security.</p>
<p class=highlight>Note: If a type on a whitelist contains itself other members that are handled by XStream, you
will have to add those member's types to the whitelist also. There is no automatism for indirect references.</p>
<p>Separate to the XStream security framework, it has always been possible to overwrite the setupConverter method
of XStream to register only the required converters.</p>
<p class=highlight>Apart from value manipulations, this implementation still allows the injection of allowed
objects at wrong locations, e.g. inserting an integer into a list of strings.</p>
<p>To avoid an attack based on the position of an element in a collection or map, you should also use XStream's
default converters for 3rd party or own implementations of collections or maps. Own custom converters of such
types should measure the time to add an element at deserialization time using the following sequence in the
implementation of the unmarshal method:<div class="Source Java">
<pre>// unmarshal element of collection
long now = System.currentTimeMillis();
// add element here, e.g. list.add(element);
SecurityUtils.checkForCollectionDoSAttack(context, now);
</pre></div></p>
<h2 id="validation">XML Validation</h2>
<p>XML itself supports input validation using a schema and a validating parser. With XStream, you can use e.g. a
DOM parser for validation, but it will take some effort to ensure that the XML read and written by XStream matches
the schema in first place, because XStream uses additionally own attributes. Typically you will have to write some
custom converters, but it can be worth the effort depending on the use case.</p>
<h1 id="framework">Security Framework</h1>
<p>Noted above, it might be possible that other combinations are found with the Java runtime itself, or other
commonly-used Java libraries that allow a similar vulnerability like the known case using the Java Beans
EventHandler. To prevent such a possibility at all, XStream version 1.4.7 and above contains a security framework,
allowing application developers to define which types are allowed to be unmarshalled with XStream. Use
<a href="javadoc/com/thoughtworks/xstream/XStream.html#setupDefaultSecurity-com.thoughtworks.xstream.XStream-">XStream.setupDefaultSecurity()</a>
to install the default whitelist of 1.4.18 already with 1.4.7 to 1.4.10.</p>
<p>The core interface is <a href="javadoc/com/thoughtworks/xstream/security/TypePermission.html">TypePermission</a>.
The <a href="javadoc/com/thoughtworks/xstream/mapper/SecurityMapper.html">SecurityMapper</a> will evaluate a list
of registered instances for every type that will be required while unmarshalling input data. The interface has one
simple method:</p><div class="Source Java"><pre>boolean allow(Class);</pre></div>
<p>The <a href="javadoc/com/thoughtworks/xstream/XStream.html">XStream</a> facade provides the following methods to
register such type permissions within the SecurityMapper:</p><div class="Source Java">
<pre>XStream.addPermission(TypePermission);
XStream.allowTypes(Class[]);
XStream.allowTypes(String[]);
XStream.allowTypesByRegExp(String[]);
XStream.allowTypesByRegExp(Pattern[]);
XStream.allowTypesByWildcard(String[]);
XStream.allowTypeHierary(Class);
XStream.denyPermission(TypePermission);
XStream.denyTypes(Class[]);
XStream.denyTypes(String[]);
XStream.denyTypesByRegExp(String[]);
XStream.denyTypesByRegExp(Pattern[]);
XStream.denyTypesByWildcard(String[]);
XStream.denyTypeHierary(Class);</pre></div>
<p>The sequence of registration is essential. The most recently registered permission will be evaluated first.</p>
<p>Every TypePermission has three options to implement the allow method and make decisions on the provided type:<p>
<ul>
<li>if the method returns <i>true</i>, the type is accepted and no other permissions are evaluated</li>
<li>if the method returns <i>false</i>, the implementation cannot judge over the type and the SecurityMapper will
continue with the next permission instance in its registration list</li>
<li>the method throws a <a href="javadoc/com/thoughtworks/xstream/security/ForbiddenClassException.html">ForbiddenClassException</a>
to stop the unmarshalling process</li>
</ul>
<h2 id="predefined">Predefined Permission Types</h2>
<p>XStream provides some TypePermission implementations to allow any or no type at all, to allow primitive types
and their counterpart, null, array types, implementations match the name of the type by regular or wildcard
expression and one to invert a permission.</p>
<p class="highlight">Note: The examples below are <strong>examples</strong>. Some will or might enable types that
are target of a security issue from above and are highlighted as dangerous.</p>
<table class="examplesTable" summary="Overview over all type permissions delivered with XStream">
<!-- .................................................................................................. -->
<tr>
<th>Permission</th>
<th>Description</th>
<th width="33%">Example</th>
<th width="33%">Default</th>
</tr>
<tr>
<td><a href="javadoc/com/thoughtworks/xstream/security/AnyTypePermission.html">AnyTypePermission</a></td>
<td><b>Start a blacklist</b> and allow any type. A registration of this permission will wipe any prior one.
You may use the ANY instance directly. Note, that it is now in the responsibility of the developer to deny any
type that might be used for arbitrary code execution as described in the CVEs above.</td>
<td class="example danger">addPermission(<i>AnyTypePermission.ANY</i>);</td>
<td>no</td>
</tr>
<tr>
<td><a href="javadoc/com/thoughtworks/xstream/security/ArrayTypePermission.html">ArrayTypePermission</a></td>
<td>Allow any array type. You may use the ARRAYS instance directly.</td>
<td class="example">addPermission(<i>ArrayTypePermission.ARRAYS</i>);</td>
<td>yes</td>
</tr>
<tr>
<td><a href="javadoc/com/thoughtworks/xstream/security/CGLIBProxyTypePermission.html">CGLIBProxyTypePermission</a></td>
<td>Allow any CGLIB proxy type. You may use the PROXIES instance directly.</td>
<td class="example danger">addPermission(<i>CGLIBProxyTypePermission.PROXIES</i>);</td>
<td>no</td>
</tr>
<tr>
<td><a href="javadoc/com/thoughtworks/xstream/security/ExplicitTypePermission.html">ExplicitTypePermission</a></td>
<td>Allow types explicitly by name.</td>
<td class="example danger">allowTypes(new String[] {"<i>java.io.File</i>", "<i>java.lang.ProcessBuilder</i>"});<br/>
allowTypes(new Class[] {<i>java.io.File.class</i>, <i>java.lang.ProcessBuilder.class</i>});</td>
<td>java.io.File, java.nio.charset.Charset, java.util.BitSet, java.lang.Class, java.lang.Object,
java.lang.StackTraceElement, java.lang.String, java.lang.StringBuffer, java.lang.StringBuilder, java.net.URI,
java.net.URL, java.sql.Date, java.sql.Time, java.sql.Timestamp, java.text.DecimalFormatSymbols,
java.time.Duration, java.time.Instant, java.time.LocalDate, java.time.LocalDateTime, java.time.LocalTime,
java.time.MonthDay, java.time.OffsetDateTime, java.time.OffsetTime, java.time.Period, java.time.Ser,
java.time.Year, java.time.YearMonth, java.time.ZonedDateTime, java.time.chrono.HijrahDate,
java.time.chrono.JapaneseDate, java.time.chrono.JapaneseEra, java.time.chrono.MinguoDate, java.time.chrono.Ser,
java.time.chrono.ThaiBuddhistDate, java.time.temporal.ValueRange, java.time.temporal.WeekFields,
java.util.Currency, java.util.Date, java.util.Locale, java.util.regex.Pattern, java.util.UUID</td>
</tr>
<tr>
<td><a href="javadoc/com/thoughtworks/xstream/security/InterfaceTypePermission.html">InterfaceTypePermission</a></td>
<td>Allow any interface type. You may use the INTERFACES instance directly.</td>
<td class="example">addPermission(<i>InterfaceTypePermission.INTERFACES</i>);</td>
<td>yes</td>
</tr>
<tr>
<td><a href="javadoc/com/thoughtworks/xstream/security/NoPermission.html">NoPermission</a></td>
<td>Invert any other permission. Instances of this type are used by XStream in the deny methods wrapping a permission.</td>
<td class="example">denyPermission(<i>permissionInstance</i>);</td>
<td>no</td>
</tr>
<tr>
<td><a href="javadoc/com/thoughtworks/xstream/security/NoTypePermission.html">NoTypePermission</a></td>
<td><b>Start a whitelist</b> and allow no type. A registration of this permission will wipe any prior one.
You may use the NONE instance directly.</td>
<td class="example">addPermission(<i>NoTypePermission.NONE</i>);</td>
<td>yes</td>
</tr>
<tr>
<td><a href="javadoc/com/thoughtworks/xstream/security/NullPermission.html">NullPermission</a></td>
<td>Allow null as type. You may use the NULL instance directly.</td>
<td class="example">addPermission(<i>NullPermission.NULL</i>);</td>
<td>yes</td>
</tr>
<tr>
<td><a href="javadoc/com/thoughtworks/xstream/security/PrimitiveTypePermission.html">PrimitiveTypePermission</a></td>
<td>Allow any primitive type and its boxed counterpart (excluding void). You may use the PRIMITIVES instance
directly.</td>
<td class="example">addPermission(<i>PrimitiveTypePermission.PRIMITIVES</i>);</td>
<td>yes</td>
</tr>
<tr>
<td><a href="javadoc/com/thoughtworks/xstream/security/ProxyTypePermission.html">ProxyTypePermission</a></td>
<td>Allow any Java proxy type. You may use the PROXIES instance directly.</td>
<td class="example">addPermission(<i>ProxyTypePermission.PROXIES</i>);</td>
<td>no</td>
</tr>
<tr>
<td><a href="javadoc/com/thoughtworks/xstream/security/RegExpTypePermission.html">RegExpTypePermission</a></td>
<td>Allow any type that matches with its name a regular expression.</td>
<td class="example danger">allowTypesByRegExp(new String[]{"<i>.*\\.core\\..*</i>", "<i>[^$]+</i>"});<br/>
allowTypesByRegExp(new Pattern[]{Pattern.compile("<i>.*\\.core\\..*</i>"), Pattern.compile("<i>[^$]+</i>")});</td>
<td>–</td>
</tr>
<tr>
<td><a href="javadoc/com/thoughtworks/xstream/security/TypeHierarchyPermission.html">TypeHierarchyPermission</a></td>
<td>Allow types of a hierarchy.</td>
<td class="example">allowTypeHierarchy(<i>java.lang.Throwable.class</i>);</td>
<td>java.lang.Enum, java.lang.Number, java.lang.Throwable, java.lang.reflect.Member, java.nio.file.Path,
java.time.Clock, java.time.ZoneId, java.time.chrono.Chronology, java.util.Calendar, java.util.Collection,
java.util.Map, java.util.Map.Entry, java.util.TimeZone</td>
</tr>
<tr>
<td><a href="javadoc/com/thoughtworks/xstream/security/WildcardTypePermission.html">WildcardTypePermission</a></td>
<td>Allow any type that matches with its name a wildcard expression.</td>
<td class="example danger">allowTypesByWildcard(new String[]{"<i>java.lang.*</i>", "<i>java.util.**"</i>});</td>
<td>–</td>
</tr>
</table>
<h2 id="example">Example Code Whitelist</h2>
<p>XStream uses now the NoTypePermission by default with an internal whitelist. You can clear out this default
and/or register your own permissions to adjust the security framework (the Blog type is from the
<a href="alias-tutorial.html">Alias Tutorial</a>):</p>
<div class="Source Java"><pre>XStream xstream = new XStream();
// clear out existing permissions and start a whitelist
xstream.addPermission(NoTypePermission.NONE);
// allow some basics
xstream.addPermission(NullPermission.NULL);
xstream.addPermission(PrimitiveTypePermission.PRIMITIVES);
xstream.allowTypeHierarchy(Collection.class);
// allow any type from the same package
xstream.allowTypesByWildcard(new String[] {
Blog.class.getPackage().getName()+".*"
});
</pre></div>
<p>You may have a further look at XStream's acceptance tests, the security framework is enabled there in general.</p>
<h2 id="workaround">Workarounds for older XStream versions</h2>
<p>As recommended, use XStream's security framework to implement a whitelist for the allowed types. This is
possible since XStream 1.4.7 and it is the default since XStream 1.4.18.</p>
<p>Users of XStream 1.4.17 who insist to use XStream default blacklist - despite that clear recommendation - can
add these lines to XStream's setup code:</p>
<div class="Source Java"><pre>xstream.denyTypesByWildcard(new String[]{ "sun.reflect.**", "sun.tracing.**", "com.sun.corba.**" });
xstream.denyTypesByRegExp(new String[]{ ".*\\.ws\\.client\\.sei\\..*", ".*\\$ProxyLazyValue", "com\\.sun\\.jndi\\..*Enumerat(?:ion|or)", ".*\\$URLData", ".*\\.xsltc\\.trax\\.TemplatesImpl" });
</pre></div>
<p>Users of XStream 1.4.16 should add these lines and <strong>additionally</strong> the lines for version 1.4.17:</p>
<div class="Source Java"><pre>xstream.denyTypesByRegExp(new String[]{ ".*\\.Lazy(?:Search)?Enumeration.*", "(?:java|sun)\\.rmi\\..*" });
</pre></div>
<p>Users of XStream 1.4.15 should add these lines and <strong>additionally</strong> the lines for version 1.4.16 and 1.4.17:</p>
<div class="Source Java"><pre>xstream.denyTypes(new String[]{ "sun.awt.datatransfer.DataTransferer$IndexOrderComparator", "com.sun.tools.javac.processing.JavacProcessingEnvironment$NameProcessIterator" });
xstream.denyTypesByRegExp(new String[]{ ".*\\$ServiceNameIterator", "(javax|sun.swing)\\..*LazyValue", "javafx\\.collections\\.ObservableList\\$.*", ".*\\.bcel\\..*\\.util\\.ClassLoader" });
xstream.denyTypeHierarchy(java.io.InputStream.class );
xstream.denyTypeHierarchy(java.nio.channels.Channel.class );
xstream.denyTypeHierarchy(javax.activation.DataSource.class );
xstream.denyTypeHierarchy(javax.sql.rowset.BaseRowSet.class );
</pre></div>
<p>Users of XStream 1.4.13 and 1.4.14 should add these lines and <strong>additionally</strong> the lines for version 1.4.15 to 1.4.17:</p></p>
<div class="Source Java"><pre>xstream.denyTypes(new String[]{ "javax.imageio.ImageIO$ContainsFilter" });
xstream.denyTypes(new Class[]{ java.lang.ProcessBuilder.class });
</pre></div>
<p>Users of XStream 1.4.7 to 1.4.12 who want to use XStream with a blacklist will have to setup such a list from
scratch:</p>
<div class="Source Java"><pre>xstream.denyTypes(new String[]{ "javax.imageio.ImageIO$ContainsFilter", "sun.awt.datatransfer.DataTransferer$IndexOrderComparator", "com.sun.tools.javac.processing.JavacProcessingEnvironment$NameProcessIterator" });
xstream.denyTypes(new Class[]{ java.lang.ProcessBuilder.class, java.beans.EventHandler.class, java.lang.ProcessBuilder.class, java.lang.Void.class, void.class });
".*\\.xsltc\\.trax\\.TemplatesImpl"xstream.denyTypesByRegExp(new String[]{ ".*\\$ServiceNameIterator", "javafx\\.collections\\.ObservableList\\$.*", ".*\\.bcel\\..*\\.util\\.ClassLoader", ".*\\$GetterSetterReflection", ".*\\$LazyIterator", ".*\\$PrivilegedGetter", ".*\\.ws\\.client\\.sei\\..*", ".*\\$ProxyLazyValue", "com\\.sun\\.jndi\\..*Enumerat(?:ion|tor)", ".*\\$URLData", ".*\\.xsltc\\.trax\\.TemplatesImpl" });
xstream.denyTypesByWildcard(new String[]{ "sun.reflect.**", "sun.tracing.**", "com.sun.corba.**" });
xstream.denyTypeHierarchy(java.io.InputStream.class);
xstream.denyTypeHierarchy(java.nio.channels.Channel.class);
xstream.denyTypeHierarchy(javax.activation.DataSource.class);
xstream.denyTypeHierarchy(javax.sql.rowset.BaseRowSet.class);
</pre></div>
<p>Users of XStream 1.4.6 or below can register an own converter to prevent the unmarshalling of the currently
know critical types of the Java runtime. It is in fact an updated version of the workaround for CVE-2013-7285:</p>
<div class="Source Java"><pre>xstream.registerConverter(new Converter() {
public boolean canConvert(Class type) {
return type != null
&& (type == java.beans.EventHandler.class || type == java.lang.ProcessBuilder.class || type == java.lang.Void.class || void.class
|| type.getName().equals("javax.imageio.ImageIO$ContainsFilter") || type.getName().equals("sun.awt.datatransfer.DataTransferer$IndexOrderComparator") || type.getName().equals("com.sun.corba.se.impl.activation.ServerTableEntry") || type.getName().equals("com.sun.tools.javac.processing.JavacProcessingEnvironment$NameProcessIterator")
|| type.getName().matches("javafx\\.collections\\.ObservableList\\$.*") || type.getName().matches(".*\\$ServiceNameIterator") || type.getName().matches(".*\\$GetterSetterReflection") || type.getName().matches(".*\\$LazyIterator") || type.getName().matches(".*\\$ProxyLazyValue") || type.getName().matches(".*\\.bcel\\..*\\.util\\.ClassLoader") || type.getName().matches(".*\\.ws\\.client\\.sei\\..*") || type.getName().matches("com\\.sun\\.jndi\\..*Enumerat(?:ion|or)")
|| type.getName().endsWith(".$URLData") || type.getName().endsWith(".xsltc.trax.TemplatesImpl")
|| type.getName().startsWith("sun.reflect.") || type.getName().startsWith("sun.tracing.") || type.getName().startsWith("com.sun.corba.")
|| java.io.InputStream.class.isAssignableFrom(type) || java.nio.channels.Channel.isAssignableFrom(type) || javax.activation.DataSource.isAssignableFrom(type) ||javax.sql.rowset.BaseRowSet.isAssignableFrom(type)
|| Proxy.isProxy(type));
}
public Object unmarshal(HierarchicalStreamReader reader, UnmarshallingContext context) {
throw new ConversionException("Unsupported type due to security reasons.");
}
public void marshal(Object source, HierarchicalStreamWriter writer, MarshallingContext context) {
throw new ConversionException("Unsupported type due to security reasons.");
}
}, XStream.PRIORITY_VERY_HIGH);
</pre></div>
<br/>
</div>
</div>
<div class="SidePanel" id="left">
<div class="MenuGroup">
<h1>Software</h1>
<ul>
<li><a href="index.html">About XStream</a></li>
<li><a href="news.html">News</a></li>
<li><a href="changes.html">Change History</a></li>
<li class="currentLink">Security Aspects</li>
<li><a href="versioning.html">About Versioning</a></li>
</ul>
</div>
<div class="MenuGroup">
<h1>Evaluating XStream</h1>
<ul>
<li><a href="tutorial.html">Two Minute Tutorial</a></li>
<li><a href="license.html">License</a></li>
<li><a href="download.html">Download</a></li>
<li><a href="references.html">References</a></li>
<li><a href="benchmarks.html">Benchmarks</a></li>
<li><a href="https://www.openhub.net/p/xstream">Code Statistics</a></li>
</ul>
</div>
<div class="MenuGroup">
<h1>Using XStream</h1>
<ul>
<li><a href="architecture.html">Architecture Overview</a></li>
<li><a href="graphs.html">Object references</a></li>
<li><a href="manual-tweaking-output.html">Tweaking the Output</a></li>
<li><a href="converters.html">Converters</a></li>
<li><a href="faq.html">Frequently Asked Questions</a></li>
<li><a href="mailing-lists.html">Mailing Lists</a></li>
<li><a href="issues.html">Reporting Issues</a></li>
</ul>
</div>
<div class="MenuGroup">
<h1>Javadoc</h1>
<ul>
<li><a href="javadoc/index.html">XStream Core</a></li>
<li><a href="hibernate-javadoc/index.html">Hibernate Extensions</a></li>
<li><a href="jmh-javadoc/index.html">JMH Module</a></li>
</ul>
</div>
<div class="MenuGroup">
<h1>Tutorials</h1>
<ul>
<li><a href="tutorial.html">Two Minute Tutorial</a></li>
<li><a href="alias-tutorial.html">Alias Tutorial</a></li>
<li><a href="annotations-tutorial.html">Annotations Tutorial</a></li>
<li><a href="converter-tutorial.html">Converter Tutorial</a></li>
<li><a href="objectstream.html">Object Streams Tutorial</a></li>
<li><a href="persistence-tutorial.html">Persistence API Tutorial</a></li>
<li><a href="json-tutorial.html">JSON Tutorial</a></li>
<li><a href="http://www.studytrails.com/java/xml/xstream/xstream-introduction.jsp">StudyTrails</a></li>
</ul>
</div>
<div class="MenuGroup">
<h1>Developing XStream</h1>
<ul>
<li><a href="how-to-contribute.html">How to Contribute</a></li>
<li><a href="team.html">Development Team</a></li>
<li><a href="repository.html">Source Repository</a></li>
<li><a href="https://travis-ci.org/x-stream/xstream/branches">Continuous Integration</a></li>
</ul>
</div>
</div>
</body>
</html>