1
00:00:01,040 --> 00:00:02,870
Many applications today still make use of

2
00:00:02,870 --> 00:00:05,540
XML, and if you're consuming XML as input,

3
00:00:05,540 --> 00:00:07,880
which almost everyone is, you need to be

4
00:00:07,880 --> 00:00:10,170
aware of what an XML External Entities

5
00:00:10,170 --> 00:00:13,163
attack is. This attack comes in at number

6
00:00:13,163 --> 00:00:17,160
4 on the OWASP Top 10 list for 2017. The

7
00:00:17,160 --> 00:00:18,610
root of this attack is in the document

8
00:00:18,610 --> 00:00:21,410
type description, or DTD, capability built

9
00:00:21,410 --> 00:00:25,340
into XML documents and parsers. On your

10
00:00:25,340 --> 00:00:27,690
screen, you see a sample XML payload that

11
00:00:27,690 --> 00:00:29,390
includes a document type definition

12
00:00:29,390 --> 00:00:31,890
section. The idea of the document type

13
00:00:31,890 --> 00:00:33,770
definition was that you could include

14
00:00:33,770 --> 00:00:35,600
structured information with the XML

15
00:00:35,600 --> 00:00:38,060
document itself, which would allow the XML

16
00:00:38,060 --> 00:00:40,670
parser on the receiving end to validate

17
00:00:40,670 --> 00:00:43,640
that it was receiving a valid document.

18
00:00:43,640 --> 00:00:45,760
However, there is a serious security flaw

19
00:00:45,760 --> 00:00:47,680
with the way that most XML parsers

20
00:00:47,680 --> 00:00:50,690
implement document type definitions. The

21
00:00:50,690 --> 00:00:53,010
DTD specification contains the capability

22
00:00:53,010 --> 00:00:54,940
to import the document type definition

23
00:00:54,940 --> 00:00:56,650
from another file using the ENTITY

24
00:00:56,650 --> 00:00:59,880
element, as you see here. The security

25
00:00:59,880 --> 00:01:02,470
flaw is typically the parser will allow

26
00:01:02,470 --> 00:01:04,710
this element to go and read any file that

27
00:01:04,710 --> 00:01:07,450
the application has access to, and then

28
00:01:07,450 --> 00:01:10,020
via a reference, insert that information

29
00:01:10,020 --> 00:01:12,380
into the XML document itself to be

30
00:01:12,380 --> 00:01:15,280
uploaded into the application. So think

31
00:01:15,280 --> 00:01:17,550
about that for a moment. Imagine you have

32
00:01:17,550 --> 00:01:20,190
an application that accepts some XML. If

33
00:01:20,190 --> 00:01:21,660
an attacker can guess the name of an

34
00:01:21,660 --> 00:01:23,910
important file on your system, say a

35
00:01:23,910 --> 00:01:26,470
web.config file or some other file that

36
00:01:26,470 --> 00:01:28,750
maybe had some credential data in it, they

37
00:01:28,750 --> 00:01:31,080
can read that file and place the contents

38
00:01:31,080 --> 00:01:33,180
of that file into the body of the XML

39
00:01:33,180 --> 00:01:36,160
document. At some point, that XML is

40
00:01:36,160 --> 00:01:37,160
probably going to get turned into an

41
00:01:37,160 --> 00:01:39,540
object and saved into a database

42
00:01:39,540 --> 00:01:41,270
somewhere, but now in one of those fields

43
00:01:41,270 --> 00:01:42,940
is going to be the sensitive data from the

44
00:01:42,940 --> 00:01:46,280
file. So now, if an attacker can figure

45
00:01:46,280 --> 00:01:48,410
out in your application where the data for

46
00:01:48,410 --> 00:01:50,290
the object created from the XML is

47
00:01:50,290 --> 00:01:52,880
displayed, they can bring up that page and

48
00:01:52,880 --> 00:01:55,170
very likely view the sensitive information

49
00:01:55,170 --> 00:01:58,000
from the file as part of the page, thereby

50
00:01:58,000 --> 00:02:01,140
exfiltrating that data from your system.

51
00:02:01,140 --> 00:02:03,720
Furthermore, many XML parsers will read

52
00:02:03,720 --> 00:02:06,220
not just a local file, but also a file

53
00:02:06,220 --> 00:02:08,450
provided by a URL from somewhere on your

54
00:02:08,450 --> 00:02:10,980
network or on the internet. So by

55
00:02:10,980 --> 00:02:13,370
specifying a URL, now an attacker can

56
00:02:13,370 --> 00:02:15,270
probe around your network, maybe seeing

57
00:02:15,270 --> 00:02:18,040
what IP addresses respond, or maybe seeing

58
00:02:18,040 --> 00:02:20,040
if there are any other unsecured files on

59
00:02:20,040 --> 00:02:22,940
other servers and these sorts of things.

60
00:02:22,940 --> 00:02:25,300
Clearly, this is a real security issue to

61
00:02:25,300 --> 00:02:28,240
have an attacker probing around like this.

62
00:02:28,240 --> 00:02:29,830
So when do we have to be aware of this

63
00:02:29,830 --> 00:02:33,240
attack in .NET? Your first thought is

64
00:02:33,240 --> 00:02:36,840
probably about Web APIs and WCF Services.

65
00:02:36,840 --> 00:02:38,590
These applications are generally not

66
00:02:38,590 --> 00:02:40,510
vulnerable to this attack because they use

67
00:02:40,510 --> 00:02:43,430
the DataContractSerializer by default, and

68
00:02:43,430 --> 00:02:45,520
the DataContractSerializer does not

69
00:02:45,520 --> 00:02:49,660
process DTDs, so it is not vulnerable. If

70
00:02:49,660 --> 00:02:51,350
somewhere in your code, though, you are

71
00:02:51,350 --> 00:02:54,450
using the XmlDocument, XmlTextReader, or

72
00:02:54,450 --> 00:02:57,480
XPathNavigator classes to parse XML, you

73
00:02:57,480 --> 00:02:59,340
could potentially be vulnerable,

74
00:02:59,340 --> 00:03:00,780
especially if you're running a version of

75
00:03:00,780 --> 00:03:04,880
.NET prior to 4.5.2.. Some instances where

76
00:03:04,880 --> 00:03:06,800
you might be doing this are if you have

77
00:03:06,800 --> 00:03:09,410
any plain old XML endpoints to take in raw

78
00:03:09,410 --> 00:03:11,820
XML and then manually deserialize it in

79
00:03:11,820 --> 00:03:14,450
code. Or maybe you have a model class that

80
00:03:14,450 --> 00:03:17,090
has a field that takes in raw XML and you

81
00:03:17,090 --> 00:03:19,730
deserialize the data later in code, or

82
00:03:19,730 --> 00:03:21,370
anywhere else you might be spinning up one

83
00:03:21,370 --> 00:03:22,780
of these classes and manually

84
00:03:22,780 --> 00:03:27,400
deserializing XML data. If you're doing

85
00:03:27,400 --> 00:03:28,990
any of these things anywhere and you're

86
00:03:28,990 --> 00:03:32,900
running a version of .NET prior to 4.5.2,

87
00:03:32,900 --> 00:03:35,255
then your code is vulnerable because in

88
00:03:35,255 --> 00:03:38,930
versions of .NET before 4.5.2, parsing and

89
00:03:38,930 --> 00:03:41,070
processing the document type definition of

90
00:03:41,070 --> 00:03:43,670
an XML document was turned on by default,

91
00:03:43,670 --> 00:03:46,470
which makes your code vulnerable. From

92
00:03:46,470 --> 00:03:50,250
.NET 4.5.2 and onward, including .NET

93
00:03:50,250 --> 00:03:52,690
Core, the default setting in all of these

94
00:03:52,690 --> 00:03:55,330
parsers has been set to prohibit. So if a

95
00:03:55,330 --> 00:03:57,980
DTD is encountered, an exception will be

96
00:03:57,980 --> 00:04:00,220
thrown, but your application will not be

97
00:04:00,220 --> 00:04:03,240
vulnerable. So the big takeaway from all

98
00:04:03,240 --> 00:04:04,880
of this is to make sure that all of your

99
00:04:04,880 --> 00:04:07,450
applications are on up‑to‑date versions of

100
00:04:07,450 --> 00:04:09,255
.NET. Just like you need to keep an

101
00:04:09,255 --> 00:04:11,405
operating system patch to keep it secure,

102
00:04:11,405 --> 00:04:13,820
the same thing is true of .NET. If you

103
00:04:13,820 --> 00:04:17,480
have applications on 4.5.1 or older, get

104
00:04:17,480 --> 00:04:20,060
those applications updated and do it today

105
00:04:20,060 --> 00:04:21,910
because that goes a long way in preventing

106
00:04:21,910 --> 00:04:25,050
this vulnerability. If for some reason you

107
00:04:25,050 --> 00:04:27,370
have to accept XML with document type

108
00:04:27,370 --> 00:04:29,320
definitions, and there's just no way to

109
00:04:29,320 --> 00:04:31,360
get away from it, perhaps because you have

110
00:04:31,360 --> 00:04:33,120
a legacy process somewhere that generates

111
00:04:33,120 --> 00:04:35,830
some XML that you can't change, then there

112
00:04:35,830 --> 00:04:37,630
are steps that you can take to secure the

113
00:04:37,630 --> 00:04:40,670
parsing process. First, you could set the

114
00:04:40,670 --> 00:04:43,820
DtdProcessing flag to Ignore, which tells

115
00:04:43,820 --> 00:04:46,510
the parser simply to ignore the DTD, but

116
00:04:46,510 --> 00:04:48,940
otherwise parse the rest of the document.

117
00:04:48,940 --> 00:04:50,760
If someone does try an External Entities

118
00:04:50,760 --> 00:04:52,870
attack in this situation, an exception

119
00:04:52,870 --> 00:04:54,620
will get thrown because there's a missing

120
00:04:54,620 --> 00:04:56,780
entity reference in the document, but your

121
00:04:56,780 --> 00:04:59,640
application will be safe from the attack.

122
00:04:59,640 --> 00:05:01,570
The second thing you can do, if you have

123
00:05:01,570 --> 00:05:04,280
to process the document type definition,

124
00:05:04,280 --> 00:05:06,430
you could either leave the XmlResolver

125
00:05:06,430 --> 00:05:08,760
property set to null, which disallows

126
00:05:08,760 --> 00:05:11,740
external file references, or write a

127
00:05:11,740 --> 00:05:15,630
custom class that extends XmlUrlResolver

128
00:05:15,630 --> 00:05:18,530
and specifies the valid safe locations

129
00:05:18,530 --> 00:05:21,760
that external DTDs can be read from, like

130
00:05:21,760 --> 00:05:23,570
you see here in this code and in the

131
00:05:23,570 --> 00:05:26,455
sample downloads. Under no circumstances

132
00:05:26,455 --> 00:05:28,500
do you want to set this property equal to

133
00:05:28,500 --> 00:05:31,850
a new instance of the XmlUrlResolver class

134
00:05:31,850 --> 00:05:33,590
because then the parser will be able to

135
00:05:33,590 --> 00:05:36,140
read any file or URI the application has

136
00:05:36,140 --> 00:05:39,050
access to and you'll be vulnerable again.

137
00:05:39,050 --> 00:05:41,710
If you keep your applications up to date,

138
00:05:41,710 --> 00:05:43,160
this is an attack you're probably not

139
00:05:43,160 --> 00:05:45,140
going to have to worry very much about.

140
00:05:45,140 --> 00:05:46,790
But now that you know about this attack,

141
00:05:46,790 --> 00:05:48,450
you can make sure that you don't have this

142
00:05:48,450 --> 00:05:50,490
behavior lurking in any of your existing

143
00:05:50,490 --> 00:05:52,830
applications or unintentionally turn on

144
00:05:52,830 --> 00:05:57,000
some insecure behavior when you're writing code.

