WEBVTT

1
00:00:00.000 --> 00:00:01.200
In this lesson,

2
00:00:01.200 --> 00:00:04.800
we will learn about Validation Mitigations.

3
00:00:04.800 --> 00:00:08.220
Validation mitigations are security measures

4
00:00:08.220 --> 00:00:11.940
that ensure data entering or leaving a system

5
00:00:11.940 --> 00:00:15.270
is properly validated and encoded.

6
00:00:15.270 --> 00:00:17.580
Validation mitigation concepts

7
00:00:17.580 --> 00:00:22.320
include input validation and output encoding.

8
00:00:22.320 --> 00:00:26.430
Input validation is checking and sanitizing data

9
00:00:26.430 --> 00:00:29.790
provided by users or external sources

10
00:00:29.790 --> 00:00:32.700
to ensure it meets expected formats

11
00:00:32.700 --> 00:00:36.180
and does not contain harmful content.

12
00:00:36.180 --> 00:00:39.960
Output encoding on the other hand, on the backend,

13
00:00:39.960 --> 00:00:42.780
converts data into a secure format

14
00:00:42.780 --> 00:00:45.570
before it's processed or displayed,

15
00:00:45.570 --> 00:00:50.400
ensuring that it cannot be interpreted as executable code.

16
00:00:50.400 --> 00:00:55.080
Let's learn more about input validation and output encoding.

17
00:00:55.080 --> 00:00:58.260
First, we have input validation.

18
00:00:58.260 --> 00:01:01.710
Input validation is the process of verifying

19
00:01:01.710 --> 00:01:05.880
and cleaning user-provided or external data

20
00:01:05.880 --> 00:01:08.970
before it is processed by a server.

21
00:01:08.970 --> 00:01:12.360
This technique ensures that the data received

22
00:01:12.360 --> 00:01:17.280
adheres to expected patterns, formats, and data types.

23
00:01:17.280 --> 00:01:19.500
When data isn't validated,

24
00:01:19.500 --> 00:01:23.010
malicious actors can exploit vulnerabilities

25
00:01:23.010 --> 00:01:25.620
by inputting harmful content,

26
00:01:25.620 --> 00:01:27.930
which can lead to various attacks,

27
00:01:27.930 --> 00:01:31.080
such as structured query language injection,

28
00:01:31.080 --> 00:01:34.560
cross-site scripting, and buffer overflows.

29
00:01:34.560 --> 00:01:39.540
In practice, input validation is the first line of defense

30
00:01:39.540 --> 00:01:42.180
in filtering out potentially dangerous

31
00:01:42.180 --> 00:01:45.030
or unexpected data from users,

32
00:01:45.030 --> 00:01:49.590
keeping applications and systems resilient against attack.

33
00:01:49.590 --> 00:01:52.860
To better understand input validation,

34
00:01:52.860 --> 00:01:56.160
let's think about airport security checks.

35
00:01:56.160 --> 00:01:59.610
Just as passengers and their luggage are screened

36
00:01:59.610 --> 00:02:02.400
for restricted items before boarding,

37
00:02:02.400 --> 00:02:07.140
input validation checks data for any disallowed characters,

38
00:02:07.140 --> 00:02:10.470
unexpected formats, or malicious patterns

39
00:02:10.470 --> 00:02:13.680
before passing information to the server.

40
00:02:13.680 --> 00:02:18.680
For example, if a form on a website expects a username,

41
00:02:18.780 --> 00:02:20.760
input validation will ensure

42
00:02:20.760 --> 00:02:24.150
that it only contains alphanumeric characters

43
00:02:24.150 --> 00:02:26.070
without any symbols.

44
00:02:26.070 --> 00:02:29.730
By identifying and blocking any attempts to include,

45
00:02:29.730 --> 00:02:33.480
say, HTML or structured query language code

46
00:02:33.480 --> 00:02:35.640
into that username field,

47
00:02:35.640 --> 00:02:39.510
input validation acts as a security filter,

48
00:02:39.510 --> 00:02:42.480
allowing only safe, expected data

49
00:02:42.480 --> 00:02:46.590
to proceed further into the application and server.

50
00:02:46.590 --> 00:02:50.190
So, to effectively prevent or mitigate threats

51
00:02:50.190 --> 00:02:52.410
through input validation,

52
00:02:52.410 --> 00:02:55.200
developers should adopt both client-side

53
00:02:55.200 --> 00:02:58.020
and server-side Validation measures.

54
00:02:58.020 --> 00:03:02.640
Client-side validation ensures a smoother user experience

55
00:03:02.640 --> 00:03:05.580
by catching invalid data early,

56
00:03:05.580 --> 00:03:09.030
but it's difficult to fully enforce this on

57
00:03:09.030 --> 00:03:11.850
and fully trust a client.

58
00:03:11.850 --> 00:03:14.700
So it's the server-side validation

59
00:03:14.700 --> 00:03:17.220
that provides robust security,

60
00:03:17.220 --> 00:03:21.420
Since the client-side code check can be bypassed.

61
00:03:21.420 --> 00:03:24.570
This doesn't mean we shouldn't be doing both client-side

62
00:03:24.570 --> 00:03:29.370
and server-side input validation, we definitely should.

63
00:03:29.370 --> 00:03:32.790
Overall, input validation techniques

64
00:03:32.790 --> 00:03:36.180
include allowlisting acceptable inputs,

65
00:03:36.180 --> 00:03:38.040
which is generally more secure

66
00:03:38.040 --> 00:03:40.650
than denylisting forbidden ones.

67
00:03:40.650 --> 00:03:44.790
The Open Web Application Security Project, or OWASP,

68
00:03:44.790 --> 00:03:48.480
validation resources, regular expressions,

69
00:03:48.480 --> 00:03:52.320
validation libraries, data type constraints,

70
00:03:52.320 --> 00:03:56.700
and length checks are tools used to set clear boundaries

71
00:03:56.700 --> 00:04:00.060
on what constitutes acceptable input.

72
00:04:00.060 --> 00:04:02.790
Applying these tools and rules

73
00:04:02.790 --> 00:04:06.030
at every point where data enters a system

74
00:04:06.030 --> 00:04:08.250
helps prevent malicious content

75
00:04:08.250 --> 00:04:11.040
from exploiting vulnerabilities.

76
00:04:11.040 --> 00:04:14.130
Second, we have output encoding.

77
00:04:14.130 --> 00:04:18.480
Output encoding is a security measure applied to data

78
00:04:18.480 --> 00:04:23.480
before it is sent from a server or displayed back to a user.

79
00:04:23.790 --> 00:04:27.000
This ensures the data cannot be interpreted

80
00:04:27.000 --> 00:04:29.340
as executable code.

81
00:04:29.340 --> 00:04:31.860
Output encoding is especially crucial

82
00:04:31.860 --> 00:04:34.740
when user-provided data is involved,

83
00:04:34.740 --> 00:04:37.710
as it safeguards against malicious scripts

84
00:04:37.710 --> 00:04:40.980
or content that could modify system behavior

85
00:04:40.980 --> 00:04:43.170
or steal information.

86
00:04:43.170 --> 00:04:46.830
Output encoding is typically applied on the backend

87
00:04:46.830 --> 00:04:50.250
and serves as an additional layer of protection,

88
00:04:50.250 --> 00:04:53.490
assuming input validation may not have caught

89
00:04:53.490 --> 00:04:55.560
all the harmful content.

90
00:04:55.560 --> 00:04:57.210
When applied correctly,

91
00:04:57.210 --> 00:05:01.230
output encoding converts potentially dangerous characters,

92
00:05:01.230 --> 00:05:04.260
like a less than and greater than sign,

93
00:05:04.260 --> 00:05:06.930
which are special characters in code,

94
00:05:06.930 --> 00:05:09.870
into harmless text representations,

95
00:05:09.870 --> 00:05:12.150
rendering them as plain text

96
00:05:12.150 --> 00:05:16.650
rather than special characters in executable code.

97
00:05:16.650 --> 00:05:20.880
By encoding output as it moves through backend layers,

98
00:05:20.880 --> 00:05:23.940
applications can ensure safe display

99
00:05:23.940 --> 00:05:27.450
and interaction with user-generated content,

100
00:05:27.450 --> 00:05:30.840
even in cases where input validation alone

101
00:05:30.840 --> 00:05:32.850
may not be sufficient.

102
00:05:32.850 --> 00:05:35.760
To better understand output encoding,

103
00:05:35.760 --> 00:05:38.820
imagine a website's comment section,

104
00:05:38.820 --> 00:05:41.730
where users can leave feedback and reviews

105
00:05:41.730 --> 00:05:44.550
that can be seen by future users.

106
00:05:44.550 --> 00:05:46.680
Without output encoding,

107
00:05:46.680 --> 00:05:50.340
a malicious user might attempt to enter a script

108
00:05:50.340 --> 00:05:53.100
that when viewed by another user

109
00:05:53.100 --> 00:05:56.250
could perform actions like stealing cookies

110
00:05:56.250 --> 00:05:59.370
or redirecting to a malicious page.

111
00:05:59.370 --> 00:06:01.140
By encoding the output,

112
00:06:01.140 --> 00:06:05.310
the system converts any special characters in the comment,

113
00:06:05.310 --> 00:06:08.970
such as that less than and greater than sign,

114
00:06:08.970 --> 00:06:12.630
into their HTML-safe representations,

115
00:06:12.630 --> 00:06:15.030
ensuring they will appear as text

116
00:06:15.030 --> 00:06:20.030
instead of executable code in the feedback or review.

117
00:06:20.190 --> 00:06:23.280
This way, even if the input validation

118
00:06:23.280 --> 00:06:25.410
missed suspicious characters,

119
00:06:25.410 --> 00:06:28.020
the output encoding will catch it,

120
00:06:28.020 --> 00:06:31.260
providing a second layer of protection.

121
00:06:31.260 --> 00:06:36.260
So, to prevent and mitigate issues with unencoded output,

122
00:06:36.300 --> 00:06:39.150
developers should always encode data

123
00:06:39.150 --> 00:06:43.590
as close to the point of display or use as possible.

124
00:06:43.590 --> 00:06:47.580
And while the assumption is that this catches failures

125
00:06:47.580 --> 00:06:49.410
in input validation,

126
00:06:49.410 --> 00:06:52.860
it doesn't mean that we shouldn't have input validation,

127
00:06:52.860 --> 00:06:54.780
we definitely should.

128
00:06:54.780 --> 00:06:58.170
In fact, we should employ both input validation

129
00:06:58.170 --> 00:07:00.330
and output encoding.

130
00:07:00.330 --> 00:07:04.260
Additionally, using security libraries or frameworks

131
00:07:04.260 --> 00:07:07.050
that offer built-in encoding functions

132
00:07:07.050 --> 00:07:09.480
can help simplify the process

133
00:07:09.480 --> 00:07:12.150
and ensure best practices.

134
00:07:12.150 --> 00:07:14.790
Together with input validation,

135
00:07:14.790 --> 00:07:18.180
output encoding helps safeguard applications

136
00:07:18.180 --> 00:07:20.490
from a wide array of attacks

137
00:07:20.490 --> 00:07:22.950
by neutralizing potential threats

138
00:07:22.950 --> 00:07:25.110
before they can execute.

139
00:07:25.110 --> 00:07:29.160
So, remember, validation mitigations

140
00:07:29.160 --> 00:07:31.980
are essential security practices

141
00:07:31.980 --> 00:07:36.060
that make sure any data entering or leaving a system

142
00:07:36.060 --> 00:07:38.490
is safe and trustworthy.

143
00:07:38.490 --> 00:07:40.920
They involve two key methods,

144
00:07:40.920 --> 00:07:44.610
input validation and output encoding.

145
00:07:44.610 --> 00:07:49.140
Input validation checks and sanitizes incoming data

146
00:07:49.140 --> 00:07:51.960
to ensure it fits expected patterns

147
00:07:51.960 --> 00:07:54.690
and is free from harmful content.

148
00:07:54.690 --> 00:07:57.090
Output encoding, on the other hand,

149
00:07:57.090 --> 00:08:01.080
is applied on the backend to format data securely

150
00:08:01.080 --> 00:08:03.810
before it's displayed or processed,

151
00:08:03.810 --> 00:08:08.460
ensuring it can't be interpreted as executable code.

152
00:08:08.460 --> 00:08:12.690
Together, these techniques provide layers of defense,

153
00:08:12.690 --> 00:08:16.200
keeping applications safe from vulnerabilities

154
00:08:16.200 --> 00:08:20.373
caused by potentially dangerous inputs or output.