This file is indexed.

/usr/lib/python3/dist-packages/defusedxml-0.4.1.egg-info is in python3-defusedxml 0.4.1-2.

This file is owned by root:root, with mode 0o644.

The actual contents of the file can be viewed below.

  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
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
Metadata-Version: 1.1
Name: defusedxml
Version: 0.4.1
Summary: XML bomb protection for Python stdlib modules
Home-page: https://bitbucket.org/tiran/defusedxml
Author: Christian Heimes
Author-email: christian@python.org
License: PSFL
Download-URL: http://pypi.python.org/pypi/defusedxml
Description: ===================================================
        defusedxml -- defusing XML bombs and other exploits
        ===================================================
        
            "It's just XML, what could probably go wrong?"
        
        Christian Heimes <christian@python.org>
        
        Synopsis
        ========
        
        The results of an attack on a vulnerable XML library can be fairly dramatic.
        With just a few hundred **Bytes** of XML data an attacker can occupy several
        **Gigabytes** of memory within **seconds**. An attacker can also keep
        CPUs busy for a long time with a small to medium size request. Under some
        circumstances it is even possible to access local files on your
        server, to circumvent a firewall, or to abuse services to rebound attacks to
        third parties.
        
        The attacks use and abuse less common features of XML and its parsers. The
        majority of developers are unacquainted with features such as processing
        instructions and entity expansions that XML inherited from SGML. At best
        they know about ``<!DOCTYPE>`` from experience with HTML but they are not
        aware that a document type definition (DTD) can generate an HTTP request
        or load a file from the file system.
        
        None of the issues is new. They have been known for a long time. Billion
        laughs was first reported in 2003. Nevertheless some XML libraries and
        applications are still vulnerable and even heavy users of XML are
        surprised by these features. It's hard to say whom to blame for the
        situation. It's too short sighted to shift all blame on XML parsers and
        XML libraries for using insecure default settings. After all they
        properly implement XML specifications. Application developers must not rely
        that a library is always configured for security and potential harmful data
        by default.
        
        
        .. contents:: Table of Contents
           :depth: 2
        
        
        Attack vectors
        ==============
        
        billion laughs / exponential entity expansion
        ---------------------------------------------
        
        The `Billion Laughs`_ attack -- also known as exponential entity expansion --
        uses multiple levels of nested entities. The original example uses 9 levels
        of 10 expansions in each level to expand the string ``lol`` to a string of
        3 * 10 :sup:`9` bytes, hence the name "billion laughs". The resulting string
        occupies 3 GB (2.79 GiB) of memory; intermediate strings require additional
        memory. Because most parsers don't cache the intermediate step for every
        expansion it is repeated over and over again. It increases the CPU load even
        more.
        
        An XML document of just a few hundred bytes can disrupt all services on a
        machine within seconds.
        
        Example XML::
        
            <!DOCTYPE xmlbomb [
            <!ENTITY a "1234567890" >
            <!ENTITY b "&a;&a;&a;&a;&a;&a;&a;&a;">
            <!ENTITY c "&b;&b;&b;&b;&b;&b;&b;&b;">
            <!ENTITY d "&c;&c;&c;&c;&c;&c;&c;&c;">
            ]>
            <bomb>&d;</bomb>
        
        
        quadratic blowup entity expansion
        ---------------------------------
        
        A quadratic blowup attack is similar to a `Billion Laughs`_ attack; it abuses
        entity expansion, too. Instead of nested entities it repeats one large entity
        with a couple of thousand chars over and over again. The attack isn't as
        efficient as the exponential case but it avoids triggering countermeasures of
        parsers against heavily nested entities. Some parsers limit the depth and
        breadth of a single entity but not the total amount of expanded text
        throughout an entire XML document.
        
        A medium-sized XML document with a couple of hundred kilobytes can require a
        couple of hundred MB to several GB of memory. When the attack is combined
        with some level of nested expansion an attacker is able to achieve a higher
        ratio of success.
        
        ::
        
            <!DOCTYPE bomb [
            <!ENTITY a "xxxxxxx... a couple of ten thousand chars">
            ]>
            <bomb>&a;&a;&a;... repeat</bomb>
        
        
        external entity expansion (remote)
        ----------------------------------
        
        Entity declarations can contain more than just text for replacement. They can
        also point to external resources by public identifiers or system identifiers.
        System identifiers are standard URIs. When the URI is a URL (e.g. a
        ``http://`` locator) some parsers download the resource from the remote
        location and embed them into the XML document verbatim.
        
        Simple example of a parsed external entity::
        
            <!DOCTYPE external [
            <!ENTITY ee SYSTEM "http://www.python.org/some.xml">
            ]>
            <root>&ee;</root>
        
        The case of parsed external entities works only for valid XML content. The
        XML standard also supports unparsed external entities with a
        ``NData declaration``.
        
        External entity expansion opens the door to plenty of exploits. An attacker
        can abuse a vulnerable XML library and application to rebound and forward
        network requests with the IP address of the server. It highly depends
        on the parser and the application what kind of exploit is possible. For
        example:
        
        * An attacker can circumvent firewalls and gain access to restricted
          resources as all the requests are made from an internal and trustworthy
          IP address, not from the outside.
        * An attacker can abuse a service to attack, spy on or DoS your servers but
          also third party services. The attack is disguised with the IP address of
          the server and the attacker is able to utilize the high bandwidth of a big
          machine.
        * An attacker can exhaust additional resources on the machine, e.g. with
          requests to a service that doesn't respond or responds with very large
          files.
        * An attacker may gain knowledge, when, how often and from which IP address
          a XML document is accessed.
        * An attacker could send mail from inside your network if the URL handler
          supports ``smtp://`` URIs.
        
        
        external entity expansion (local file)
        --------------------------------------
        
        External entities with references to local files are a sub-case of external
        entity expansion. It's listed as an extra attack because it deserves extra
        attention. Some XML libraries such as lxml disable network access by default
        but still allow entity expansion with local file access by default. Local
        files are either referenced with a ``file://`` URL or by a file path (either
        relative or absolute).
        
        An attacker may be able to access and download all files that can be read by
        the application process. This may include critical configuration files, too.
        
        ::
        
            <!DOCTYPE external [
            <!ENTITY ee SYSTEM "file:///PATH/TO/simple.xml">
            ]>
            <root>&ee;</root>
        
        
        DTD retrieval
        -------------
        
        This case is similar to external entity expansion, too. Some XML libraries
        like Python's xml.dom.pulldom retrieve document type definitions from remote
        or local locations. Several attack scenarios from the external entity case
        apply to this issue as well.
        
        ::
        
            <?xml version="1.0" encoding="utf-8"?>
            <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
              "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
            <html>
                <head/>
                <body>text</body>
            </html>
        
        
        Python XML Libraries
        ====================
        
        .. csv-table:: vulnerabilities and features
           :header: "kind", "sax", "etree", "minidom", "pulldom", "xmlrpc", "lxml", "genshi"
           :widths: 24, 7, 8, 8, 7, 8, 8, 8
           :stub-columns: 0
        
           "billion laughs", "**True**", "**True**", "**True**", "**True**", "**True**", "False (1)", "False (5)"
           "quadratic blowup", "**True**", "**True**", "**True**", "**True**", "**True**", "**True**", "False (5)"
           "external entity expansion (remote)", "**True**", "False (3)", "False (4)", "**True**", "false", "False (1)", "False (5)"
           "external entity expansion (local file)", "**True**", "False (3)", "False (4)", "**True**", "false", "**True**", "False (5)"
           "DTD retrieval", "**True**", "False", "False", "**True**", "false", "False (1)", "False"
           "gzip bomb", "False", "False", "False", "False", "**True**", "**partly** (2)", "False"
           "xpath support (7)", "False", "False", "False", "False", "False", "**True**", "False"
           "xsl(t) support (7)", "False", "False", "False", "False", "False", "**True**", "False"
           "xinclude support (7)", "False", "**True** (6)", "False", "False", "False", "**True** (6)", "**True**"
           "C library", "expat", "expat", "expat", "expat", "expat", "libxml2", "expat"
        
        1. Lxml is protected against billion laughs attacks and doesn't do network
           lookups by default.
        2. libxml2 and lxml are not directly vulnerable to gzip decompression bombs
           but they don't protect you against them either.
        3. xml.etree doesn't expand entities and raises a ParserError when an entity
           occurs.
        4. minidom doesn't expand entities and simply returns the unexpanded entity
           verbatim.
        5. genshi.input of genshi 0.6 doesn't support entity expansion and raises a
           ParserError when an entity occurs.
        6. Library has (limited) XInclude support but requires an additional step to
           process inclusion.
        7. These are features but they may introduce exploitable holes, see
           `Other things to consider`_
        
        
        Settings in standard library
        ----------------------------
        
        
        xml.sax.handler Features
        ........................
        
        feature_external_ges (http://xml.org/sax/features/external-general-entities)
          disables external entity expansion
        
        feature_external_pes (http://xml.org/sax/features/external-parameter-entities)
          the option is ignored and doesn't modify any functionality
        
        DOM xml.dom.xmlbuilder.Options
        ..............................
        
        external_parameter_entities
          ignored
        
        external_general_entities
          ignored
        
        external_dtd_subset
          ignored
        
        entities
          unsure
        
        
        defusedxml
        ==========
        
        The `defusedxml package`_ (`defusedxml on PyPI`_)
        contains several Python-only workarounds and fixes
        for denial of service and other vulnerabilities in Python's XML libraries.
        In order to benefit from the protection you just have to import and use the
        listed functions / classes from the right defusedxml module instead of the
        original module. Merely `defusedxml.xmlrpc`_ is implemented as monkey patch.
        
        Instead of::
        
           >>> from xml.etree.ElementTree import parse
           >>> et = parse(xmlfile)
        
        alter code to::
        
           >>> from defusedxml.ElementTree import parse
           >>> et = parse(xmlfile)
        
        Additionally the package has an **untested** function to monkey patch
        all stdlib modules with ``defusedxml.defuse_stdlib()``.
        
        All functions and parser classes accept three additional keyword arguments.
        They return either the same objects as the original functions or compatible
        subclasses.
        
        forbid_dtd (default: False)
          disallow XML with a ``<!DOCTYPE>`` processing instruction and raise a
          *DTDForbidden* exception when a DTD processing instruction is found.
        
        forbid_entities (default: True)
          disallow XML with ``<!ENTITY>`` declarations inside the DTD and raise an
          *EntitiesForbidden* exception when an entity is declared.
        
        forbid_external (default: True)
          disallow any access to remote or local resources in external entities
          or DTD and raising an *ExternalReferenceForbidden* exception when a DTD
          or entity references an external resource.
        
        
        defusedxml (package)
        --------------------
        
        DefusedXmlException, DTDForbidden, EntitiesForbidden,
        ExternalReferenceForbidden, NotSupportedError
        
        defuse_stdlib() (*experimental*)
        
        
        defusedxml.cElementTree
        -----------------------
        
        parse(), iterparse(), fromstring(), XMLParser
        
        
        defusedxml.ElementTree
        -----------------------
        
        parse(), iterparse(), fromstring(), XMLParser
        
        
        defusedxml.expatreader
        ----------------------
        
        create_parser(), DefusedExpatParser
        
        
        defusedxml.sax
        --------------
        
        parse(), parseString(), create_parser()
        
        
        defusedxml.expatbuilder
        -----------------------
        
        parse(), parseString(), DefusedExpatBuilder, DefusedExpatBuilderNS
        
        
        defusedxml.minidom
        ------------------
        
        parse(), parseString()
        
        
        defusedxml.pulldom
        ------------------
        
        parse(), parseString()
        
        
        defusedxml.xmlrpc
        -----------------
        
        The fix is implemented as monkey patch for the stdlib's xmlrpc package (3.x)
        or xmlrpclib module (2.x). The function `monkey_patch()` enables the fixes,
        `unmonkey_patch()` removes the patch and puts the code in its former state.
        
        The monkey patch protects against XML related attacks as well as
        decompression bombs and excessively large requests or responses. The default
        setting is 30 MB for requests, responses and gzip decompression. You can
        modify the default by changing the module variable `MAX_DATA`. A value of
        `-1` disables the limit.
        
        
        defusedxml.lxml
        ---------------
        
        The module acts as an *example* how you could protect code that uses
        lxml.etree. It implements a custom Element class that filters out
        Entity instances, a custom parser factory and a thread local storage for
        parser instances. It also has a check_docinfo() function which inspects
        a tree for internal or external DTDs and entity declarations. In order to
        check for entities lxml > 3.0 is required.
        
        parse(), fromstring()
        RestrictedElement, GlobalParserTLS, getDefaultParser(), check_docinfo()
        
        
        defusedexpat
        ============
        
        The `defusedexpat package`_ (`defusedexpat on PyPI`_)
        comes with binary extensions and a
        `modified expat`_ libary instead of the standard `expat parser`_. It's
        basically a stand-alone version of the patches for Python's standard
        library C extensions.
        
        Modifications in expat
        ----------------------
        
        new definitions::
        
          XML_BOMB_PROTECTION
          XML_DEFAULT_MAX_ENTITY_INDIRECTIONS
          XML_DEFAULT_MAX_ENTITY_EXPANSIONS
          XML_DEFAULT_RESET_DTD
        
        new XML_FeatureEnum members::
        
          XML_FEATURE_MAX_ENTITY_INDIRECTIONS
          XML_FEATURE_MAX_ENTITY_EXPANSIONS
          XML_FEATURE_IGNORE_DTD
        
        new XML_Error members::
        
          XML_ERROR_ENTITY_INDIRECTIONS
          XML_ERROR_ENTITY_EXPANSION
        
        new API functions::
        
          int XML_GetFeature(XML_Parser parser,
                             enum XML_FeatureEnum feature,
                             long *value);
          int XML_SetFeature(XML_Parser parser,
                             enum XML_FeatureEnum feature,
                             long value);
          int XML_GetFeatureDefault(enum XML_FeatureEnum feature,
                                    long *value);
          int XML_SetFeatureDefault(enum XML_FeatureEnum feature,
                                    long value);
        
        XML_FEATURE_MAX_ENTITY_INDIRECTIONS
           Limit the amount of indirections that are allowed to occur during the
           expansion of a nested entity. A counter starts when an entity reference
           is encountered. It resets after the entity is fully expanded. The limit
           protects the parser against exponential entity expansion attacks (aka
           billion laughs attack). When the limit is exceeded the parser stops and
           fails with `XML_ERROR_ENTITY_INDIRECTIONS`.
           A value of 0 disables the protection.
        
           Supported range
             0 .. UINT_MAX
           Default
             40
        
        XML_FEATURE_MAX_ENTITY_EXPANSIONS
           Limit the total length of all entity expansions throughout the entire
           document. The lengths of all entities are accumulated in a parser variable.
           The setting protects against quadratic blowup attacks (lots of expansions
           of a large entity declaration). When the sum of all entities exceeds
           the limit, the parser stops and fails with `XML_ERROR_ENTITY_EXPANSION`.
           A value of 0 disables the protection.
        
           Supported range
             0 .. UINT_MAX
           Default
             8 MiB
        
        XML_FEATURE_RESET_DTD
           Reset all DTD information after the <!DOCTYPE> block has been parsed. When
           the flag is set (default: false) all DTD information after the
           endDoctypeDeclHandler has been called. The flag can be set inside the
           endDoctypeDeclHandler. Without DTD information any entity reference in
           the document body leads to `XML_ERROR_UNDEFINED_ENTITY`.
        
           Supported range
             0, 1
           Default
             0
        
        
        How to avoid XML vulnerabilities
        ================================
        
        Best practices
        --------------
        
        * Don't allow DTDs
        * Don't expand entities
        * Don't resolve externals
        * Limit parse depth
        * Limit total input size
        * Limit parse time
        * Favor a SAX or iterparse-like parser for potential large data
        * Validate and properly quote arguments to XSL transformations and
          XPath queries
        * Don't use XPath expression from untrusted sources
        * Don't apply XSL transformations that come untrusted sources
        
        (based on Brad Hill's `Attacking XML Security`_)
        
        
        Other things to consider
        ========================
        
        XML, XML parsers and processing libraries have more features and possible
        issue that could lead to DoS vulnerabilities or security exploits in
        applications. I have compiled an incomplete list of theoretical issues that
        need further research and more attention. The list is deliberately pessimistic
        and a bit paranoid, too. It contains things that might go wrong under daffy
        circumstances.
        
        
        attribute blowup / hash collision attack
        ----------------------------------------
        
        XML parsers may use an algorithm with quadratic runtime O(n :sup:`2`) to
        handle attributes and namespaces. If it uses hash tables (dictionaries) to
        store attributes and namespaces the implementation may be vulnerable to
        hash collision attacks, thus reducing the performance to O(n :sup:`2`) again.
        In either case an attacker is able to forge a denial of service attack with
        an XML document that contains thousands upon thousands of attributes in
        a single node.
        
        I haven't researched yet if expat, pyexpat or libxml2 are vulnerable.
        
        
        decompression bomb
        ------------------
        
        The issue of decompression bombs (aka `ZIP bomb`_) apply to all XML libraries
        that can parse compressed XML stream like gzipped HTTP streams or LZMA-ed
        files. For an attacker it can reduce the amount of transmitted data by three
        magnitudes or more. Gzip is able to compress 1 GiB zeros to roughly 1 MB,
        lzma is even better::
        
            $ dd if=/dev/zero bs=1M count=1024 | gzip > zeros.gz
            $ dd if=/dev/zero bs=1M count=1024 | lzma -z > zeros.xy
            $ ls -sh zeros.*
            1020K zeros.gz
             148K zeros.xy
        
        None of Python's standard XML libraries decompress streams except for
        ``xmlrpclib``. The module is vulnerable <http://bugs.python.org/issue16043>
        to decompression bombs.
        
        lxml can load and process compressed data through libxml2 transparently.
        libxml2 can handle even very large blobs of compressed data efficiently
        without using too much memory. But it doesn't protect applications from
        decompression bombs. A carefully written SAX or iterparse-like approach can
        be safe.
        
        
        Processing Instruction
        ----------------------
        
        `PI`_'s like::
        
          <?xml-stylesheet type="text/xsl" href="style.xsl"?>
        
        may impose more threats for XML processing. It depends if and how a
        processor handles processing instructions. The issue of URL retrieval with
        network or local file access apply to processing instructions, too.
        
        
        Other DTD features
        ------------------
        
        `DTD`_ has more features like ``<!NOTATION>``. I haven't researched how
        these features may be a security threat.
        
        
        XPath
        -----
        
        XPath statements may introduce DoS vulnerabilities. Code should never execute
        queries from untrusted sources. An attacker may also be able to create a XML
        document that makes certain XPath queries costly or resource hungry.
        
        
        XPath injection attacks
        -----------------------
        
        XPath injeciton attacks pretty much work like SQL injection attacks.
        Arguments to XPath queries must be quoted and validated properly, especially
        when they are taken from the user. The page `Avoid the dangers of XPath injection`_
        list some ramifications of XPath injections.
        
        Python's standard library doesn't have XPath support. Lxml supports
        parameterized XPath queries which does proper quoting. You just have to use
        its xpath() method correctly::
        
           # DON'T
           >>> tree.xpath("/tag[@id='%s']" % value)
        
           # instead do
           >>> tree.xpath("/tag[@id=$tagid]", tagid=name)
        
        
        XInclude
        --------
        
        `XML Inclusion`_ is another way to load and include external files::
        
           <root xmlns:xi="http://www.w3.org/2001/XInclude">
             <xi:include href="filename.txt" parse="text" />
           </root>
        
        This feature should be disabled when XML files from an untrusted source are
        processed. Some Python XML libraries and libxml2 support XInclude but don't
        have an option to sandbox inclusion and limit it to allowed directories.
        
        
        XMLSchema location
        ------------------
        
        A validating XML parser may download schema files from the information in a
        ``xsi:schemaLocation`` attribute.
        
        ::
        
          <ead xmlns="urn:isbn:1-931666-22-9"
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
               xsi:schemaLocation="urn:isbn:1-931666-22-9 http://www.loc.gov/ead/ead.xsd">
          </ead>
        
        
        XSL Transformation
        ------------------
        
        You should keep in mind that XSLT is a Turing complete language. Never
        process XSLT code from unknown or untrusted source! XSLT processors may
        allow you to interact with external resources in ways you can't even imagine.
        Some processors even support extensions that allow read/write access to file
        system, access to JRE objects or scripting with Jython.
        
        Example from `Attacking XML Security`_ for Xalan-J::
        
            <xsl:stylesheet version="1.0"
             xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
             xmlns:rt="http://xml.apache.org/xalan/java/java.lang.Runtime"
             xmlns:ob="http://xml.apache.org/xalan/java/java.lang.Object"
             exclude-result-prefixes= "rt ob">
             <xsl:template match="/">
               <xsl:variable name="runtimeObject" select="rt:getRuntime()"/>
               <xsl:variable name="command"
                 select="rt:exec($runtimeObject, &apos;c:\Windows\system32\cmd.exe&apos;)"/>
               <xsl:variable name="commandAsString" select="ob:toString($command)"/>
               <xsl:value-of select="$commandAsString"/>
             </xsl:template>
            </xsl:stylesheet>
        
        
        Related CVEs
        ============
        
        CVE-2013-1664
          Unrestricted entity expansion induces DoS vulnerabilities in Python XML
          libraries (XML bomb)
        
        CVE-2013-1665
          External entity expansion in Python XML libraries inflicts potential
          security flaws and DoS vulnerabilities
        
        
        Other languages / frameworks
        =============================
        
        Several other programming languages and frameworks are vulnerable as well. A
        couple of them are affected by the fact that libxml2 up to 2.9.0 has no
        protection against quadratic blowup attacks. Most of them have potential
        dangerous default settings for entity expansion and external entities, too.
        
        Perl
        ----
        
        Perl's XML::Simple is vulnerable to quadratic entity expansion and external
        entity expansion (both local and remote).
        
        
        Ruby
        ----
        
        Ruby's REXML document parser is vulnerable to entity expansion attacks
        (both quadratic and exponential) but it doesn't do external entity
        expansion by default. In order to counteract entity expansion you have to
        disable the feature::
        
          REXML::Document.entity_expansion_limit = 0
        
        libxml-ruby and hpricot don't expand entities in their default configuration.
        
        
        PHP
        ---
        
        PHP's SimpleXML API is vulnerable to quadratic entity expansion and loads
        entites from local and remote resources. The option ``LIBXML_NONET`` disables
        network access but still allows local file access. ``LIBXML_NOENT`` seems to
        have no effect on entity expansion in PHP 5.4.6.
        
        
        C# / .NET / Mono
        ----------------
        
        Information in `XML DoS and Defenses (MSDN)`_ suggest that .NET is
        vulnerable with its default settings. The article contains code snippets
        how to create a secure XML reader::
        
          XmlReaderSettings settings = new XmlReaderSettings();
          settings.ProhibitDtd = false;
          settings.MaxCharactersFromEntities = 1024;
          settings.XmlResolver = null;
          XmlReader reader = XmlReader.Create(stream, settings);
        
        
        Java
        ----
        
        Untested. The documentation of Xerces and its `Xerces SecurityMananger`_
        sounds like Xerces is also vulnerable to billion laugh attacks with its
        default settings. It also does entity resolving when an
        ``org.xml.sax.EntityResolver`` is configured. I'm not yet sure about the
        default setting here.
        
        Java specialists suggest to have a custom builder factory::
        
          DocumentBuilderFactory builderFactory = DocumentBuilderFactory.newInstance();
          builderFactory.setXIncludeAware(False);
          builderFactory.setExpandEntityReferences(False);
          builderFactory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, True);
          # either
          builderFactory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", True);
          # or if you need DTDs
          builderFactory.setFeature("http://xml.org/sax/features/external-general-entities", False);
          builderFactory.setFeature("http://xml.org/sax/features/external-parameter-entities", False);
          builderFactory.setFeature("http://apache.org/xml/features/nonvalidating/load-external-dtd", False);
          builderFactory.setFeature("http://apache.org/xml/features/nonvalidating/load-dtd-grammar", False);
        
        
        TODO
        ====
        
        * DOM: Use xml.dom.xmlbuilder options for entity handling
        * SAX: take feature_external_ges and feature_external_pes (?) into account
        * test experimental monkey patching of stdlib modules
        * improve documentation
        
        
        License
        =======
        
        Copyright (c) 2013 by Christian Heimes <christian@python.org>
        
        Licensed to PSF under a Contributor Agreement.
        
        See http://www.python.org/psf/license for licensing details.
        
        
        Acknowledgements
        ================
        
        Brett Cannon (Python Core developer)
          review and code cleanup
        
        Antoine Pitrou (Python Core developer)
          code review
        
        Aaron Patterson, Ben Murphy and Michael Koziarski (Ruby community)
          Many thanks to Aaron, Ben and Michael from the Ruby community for their
          report and assistance.
        
        Thierry Carrez (OpenStack)
          Many thanks to Thierry for his report to the Python Security Response
          Team on behalf of the OpenStack security team.
        
        Carl Meyer (Django)
          Many thanks to Carl for his report to PSRT on behalf of the Django security
          team.
        
        Daniel Veillard (libxml2)
          Many thanks to Daniel for his insight and assistance with libxml2.
        
        semantics GmbH (http://www.semantics.de/)
          Many thanks to my employer semantics for letting me work on the issue
          during working hours as part of semantics's open source initiative.
        
        
        References
        ==========
        
        * `XML DoS and Defenses (MSDN)`_
        * `Billion Laughs`_ on Wikipedia
        * `ZIP bomb`_ on Wikipedia
        * `Configure SAX parsers for secure processing`_
        * `Testing for XML Injection`_
        
        .. _defusedxml package: https://bitbucket.org/tiran/defusedxml
        .. _defusedxml on PyPI: https://pypi.python.org/pypi/defusedxml
        .. _defusedexpat package: https://bitbucket.org/tiran/defusedexpat
        .. _defusedexpat on PyPI: https://pypi.python.org/pypi/defusedexpat
        .. _modified expat: https://bitbucket.org/tiran/expat
        .. _expat parser: http://expat.sourceforge.net/
        .. _Attacking XML Security: https://www.isecpartners.com/media/12976/iSEC-HILL-Attacking-XML-Security-bh07.pdf
        .. _Billion Laughs: http://en.wikipedia.org/wiki/Billion_laughs
        .. _XML DoS and Defenses (MSDN): http://msdn.microsoft.com/en-us/magazine/ee335713.aspx
        .. _ZIP bomb: http://en.wikipedia.org/wiki/Zip_bomb
        .. _DTD: http://en.wikipedia.org/wiki/Document_Type_Definition
        .. _PI: https://en.wikipedia.org/wiki/Processing_Instruction
        .. _Avoid the dangers of XPath injection: http://www.ibm.com/developerworks/xml/library/x-xpathinjection/index.html
        .. _Configure SAX parsers for secure processing: http://www.ibm.com/developerworks/xml/library/x-tipcfsx/index.html
        .. _Testing for XML Injection: https://www.owasp.org/index.php/Testing_for_XML_Injection_(OWASP-DV-008)
        .. _Xerces SecurityMananger: http://xerces.apache.org/xerces2-j/javadocs/xerces2/org/apache/xerces/util/SecurityManager.html
        .. _XML Inclusion: http://www.w3.org/TR/xinclude/#include_element
        
        Changelog
        =========
        
        defusedxml 0.4.1
        ----------------
        
        *Release date: 28-Mar-2013*
        
        - Add more demo exploits, e.g. python_external.py and Xalan XSLT demos.
        - Improved documentation.
        
        
        defusedxml 0.4
        --------------
        
        *Release date: 25-Feb-2013*
        
        - As per http://seclists.org/oss-sec/2013/q1/340 please REJECT
          CVE-2013-0278, CVE-2013-0279 and CVE-2013-0280 and use CVE-2013-1664,
          CVE-2013-1665 for OpenStack/etc.
        - Add missing parser_list argument to sax.make_parser(). The argument is
          ignored, though. (thanks to Florian Apolloner)
        - Add demo exploit for external entity attack on Python's SAX parser, XML-RPC
          and WebDAV.
        
        
        defusedxml 0.3
        --------------
        
        *Release date: 19-Feb-2013*
        
        - Improve documentation
        
        
        defusedxml 0.2
        --------------
        
        *Release date: 15-Feb-2013*
        
        - Rename ExternalEntitiesForbidden to ExternalReferenceForbidden
        - Rename defusedxml.lxml.check_dtd() to check_docinfo()
        - Unify argument names in callbacks
        - Add arguments and formatted representation to exceptions
        - Add forbid_external argument to all functions and classs
        - More tests
        - LOTS of documentation
        - Add example code for other languages (Ruby, Perl, PHP) and parsers (Genshi)
        - Add protection against XML and gzip attacks to xmlrpclib
        
        defusedxml 0.1
        --------------
        
        *Release date: 08-Feb-2013*
        
        - Initial and internal release for PSRT review
        
Keywords: xml bomb DoS
Platform: all
Classifier: Development Status :: 5 - Production/Stable
Classifier: Intended Audience :: Developers
Classifier: License :: OSI Approved :: Python Software Foundation License
Classifier: Natural Language :: English
Classifier: Programming Language :: Python
Classifier: Programming Language :: Python :: 2
Classifier: Programming Language :: Python :: 2.6
Classifier: Programming Language :: Python :: 2.7
Classifier: Programming Language :: Python :: 3
Classifier: Programming Language :: Python :: 3.1
Classifier: Programming Language :: Python :: 3.2
Classifier: Programming Language :: Python :: 3.3
Classifier: Topic :: Text Processing :: Markup :: XML