1
00:00:01,190 --> 00:00:02,530
Now that we have seen how these attacks

2
00:00:02,530 --> 00:00:04,325
work, let's summarize the steps involved

3
00:00:04,325 --> 00:00:06,140
and how to make sure our applications are

4
00:00:06,140 --> 00:00:08,770
protected against them. The first step is

5
00:00:08,770 --> 00:00:10,410
to make sure that all of your applications

6
00:00:10,410 --> 00:00:12,805
are using an up‑to‑date version of .NET.

7
00:00:12,805 --> 00:00:15,270
As we have seen, the later versions of

8
00:00:15,270 --> 00:00:17,810
.NET have taken a secure‑by‑default

9
00:00:17,810 --> 00:00:19,870
stance, making sure you are not vulnerable

10
00:00:19,870 --> 00:00:21,790
due to a feature that may not even be

11
00:00:21,790 --> 00:00:24,930
needed by your application. When doing

12
00:00:24,930 --> 00:00:26,440
this, it is important that you keep all of

13
00:00:26,440 --> 00:00:28,520
your applications up to date, even if

14
00:00:28,520 --> 00:00:30,230
these are applications inside of your

15
00:00:30,230 --> 00:00:32,330
firewall or are only used by a handful of

16
00:00:32,330 --> 00:00:35,720
users. In security, there is no such thing

17
00:00:35,720 --> 00:00:38,590
as a low priority system. And in fact,

18
00:00:38,590 --> 00:00:40,640
it's often a low usage or somewhat

19
00:00:40,640 --> 00:00:42,730
forgotten system that could be targeted by

20
00:00:42,730 --> 00:00:44,850
an attacker. So make sure that you're

21
00:00:44,850 --> 00:00:46,530
keeping all of your applications up to

22
00:00:46,530 --> 00:00:49,130
date as this goes a long way in keeping

23
00:00:49,130 --> 00:00:52,750
you secure from these vulnerabilities. If

24
00:00:52,750 --> 00:00:54,120
you have made sure that you were running

25
00:00:54,120 --> 00:00:55,830
all of your applications on supported

26
00:00:55,830 --> 00:00:58,210
recent versions of .NET, there is still

27
00:00:58,210 --> 00:00:59,810
potential for these vulnerabilities to

28
00:00:59,810 --> 00:01:02,740
occur, and that potential is twofold.

29
00:01:02,740 --> 00:01:04,220
First, you could have an existing

30
00:01:04,220 --> 00:01:05,930
application that relies on one of these

31
00:01:05,930 --> 00:01:08,080
insecure features, but at the time that

32
00:01:08,080 --> 00:01:10,290
that code was written, it was not done so

33
00:01:10,290 --> 00:01:12,945
in a secure manner. Of course the problem

34
00:01:12,945 --> 00:01:14,660
is how to scan through all of your

35
00:01:14,660 --> 00:01:17,420
existing lines of code and find out if any

36
00:01:17,420 --> 00:01:20,640
of these vulnerabilities exist somewhere.

37
00:01:20,640 --> 00:01:22,360
The second potential to introduce one of

38
00:01:22,360 --> 00:01:24,270
these vulnerabilities is that an

39
00:01:24,270 --> 00:01:26,370
unsuspecting developer needs to solve a

40
00:01:26,370 --> 00:01:28,390
problem and unknowingly and

41
00:01:28,390 --> 00:01:30,190
unintentionally makes use of one of these

42
00:01:30,190 --> 00:01:32,390
features, not knowing that they've now

43
00:01:32,390 --> 00:01:33,970
created a vulnerability in the

44
00:01:33,970 --> 00:01:37,410
application. After all, these attacks are

45
00:01:37,410 --> 00:01:40,060
pretty obscure to the average developer.

46
00:01:40,060 --> 00:01:42,070
Most of us have heard of SQL Injection or

47
00:01:42,070 --> 00:01:43,860
Cross‑Site Scripting attacks and things

48
00:01:43,860 --> 00:01:45,920
like that, but before you took this

49
00:01:45,920 --> 00:01:48,640
course, ask yourself, how well versed were

50
00:01:48,640 --> 00:01:51,840
you in how a deserialization attack works?

51
00:01:51,840 --> 00:01:54,210
So what do you do, both to find existing

52
00:01:54,210 --> 00:01:55,960
vulnerabilities that might be lurking in

53
00:01:55,960 --> 00:01:57,710
code, or to prevent someone from

54
00:01:57,710 --> 00:02:00,680
accidentally adding a new vulnerability?

55
00:02:00,680 --> 00:02:02,490
This is where code analysis comes into

56
00:02:02,490 --> 00:02:05,340
play and can really help us. Today, there

57
00:02:05,340 --> 00:02:07,760
are a number of tools available for .NET

58
00:02:07,760 --> 00:02:09,420
that scan your code base and help you

59
00:02:09,420 --> 00:02:12,010
detect security vulnerabilities. These

60
00:02:12,010 --> 00:02:13,850
tools can be integrated into your build

61
00:02:13,850 --> 00:02:16,400
pipeline, and in many cases also have an

62
00:02:16,400 --> 00:02:18,460
ability to be integrated directly into

63
00:02:18,460 --> 00:02:21,510
Visual Studio. Two popular commercial

64
00:02:21,510 --> 00:02:23,990
examples of these tools are Sonarqube and

65
00:02:23,990 --> 00:02:26,190
Veracode, but there are many others that

66
00:02:26,190 --> 00:02:29,520
are also available. Another option is this

67
00:02:29,520 --> 00:02:33,060
NuGet package, Security Code Scan. It is

68
00:02:33,060 --> 00:02:35,940
open source and uses Roslyn analyzers to

69
00:02:35,940 --> 00:02:38,500
detect vulnerabilities in your code.

70
00:02:38,500 --> 00:02:41,370
Whichever package you or your company ends

71
00:02:41,370 --> 00:02:44,490
up choosing, the idea is the same. These

72
00:02:44,490 --> 00:02:46,630
tools can scan your code every time it is

73
00:02:46,630 --> 00:02:49,060
built for a wide range of insecure coding

74
00:02:49,060 --> 00:02:51,100
practices, making sure you don't

75
00:02:51,100 --> 00:02:53,010
accidentally introduce vulnerable code

76
00:02:53,010 --> 00:02:55,620
into your application. And they're a big

77
00:02:55,620 --> 00:02:58,070
help to scan existing applications,

78
00:02:58,070 --> 00:02:59,520
especially code bases that have been

79
00:02:59,520 --> 00:03:02,290
around for a long time, saving you a lot

80
00:03:02,290 --> 00:03:04,310
of manual effort in determining if these

81
00:03:04,310 --> 00:03:07,550
applications have vulnerability. In this

82
00:03:07,550 --> 00:03:08,930
course, we've looked at three different

83
00:03:08,930 --> 00:03:10,510
vulnerabilities that are all related to

84
00:03:10,510 --> 00:03:13,250
the theme of deserializing data in our

85
00:03:13,250 --> 00:03:16,030
application, often XML, but also JSON or

86
00:03:16,030 --> 00:03:18,730
binary serialized data. Two of these

87
00:03:18,730 --> 00:03:20,910
attacks, the XML External Entities attack

88
00:03:20,910 --> 00:03:22,950
and the Insecure Deserialization attack,

89
00:03:22,950 --> 00:03:25,730
are on OWASP Top 10 list. And the third,

90
00:03:25,730 --> 00:03:27,800
the XML Bomb, can be used in a denial of

91
00:03:27,800 --> 00:03:30,350
service attack. These attacks are a little

92
00:03:30,350 --> 00:03:32,390
bit more obscure and you're less likely to

93
00:03:32,390 --> 00:03:34,520
encounter them, but of course that doesn't

94
00:03:34,520 --> 00:03:36,690
mean that they can't occur, especially if

95
00:03:36,690 --> 00:03:39,010
you let your guard down. And that is what

96
00:03:39,010 --> 00:03:40,960
this course has really been about, is to

97
00:03:40,960 --> 00:03:43,050
give you an awareness of these attacks and

98
00:03:43,050 --> 00:03:45,330
how they can occur so that if you do run

99
00:03:45,330 --> 00:03:47,090
into one of these situations, you'll be

100
00:03:47,090 --> 00:03:49,300
able to recognize it and take appropriate

101
00:03:49,300 --> 00:03:51,970
steps to secure your code. Just knowing

102
00:03:51,970 --> 00:03:54,280
about an attack and how it works makes it

103
00:03:54,280 --> 00:03:55,650
less likely that you're going to be

104
00:03:55,650 --> 00:03:58,340
vulnerable to the attack. So hopefully,

105
00:03:58,340 --> 00:04:00,400
your only exposure to these attacks will

106
00:04:00,400 --> 00:04:02,590
be in this course and not in any of your

107
00:04:02,590 --> 00:04:05,360
applications. Thank you very much for

108
00:04:05,360 --> 00:04:07,230
watching, and best of luck in building

109
00:04:07,230 --> 00:04:13,000
your applications and continuing to build your skills here on Pluralsight.

