1
00:00:00,000 --> 00:00:05,076
[MUSIC]

2
00:00:05,076 --> 00:00:09,320
Welcome back, over the next few videos
we'll be looking into how developers fail

3
00:00:09,320 --> 00:00:13,610
to protect the basic gateways to
their application and its users.

4
00:00:13,610 --> 00:00:14,980
From authentication methods,

5
00:00:14,980 --> 00:00:19,510
to user authorization, developers tend
to mess up in this area far too often.

6
00:00:19,510 --> 00:00:22,410
It's our goal in this stage to
explore ways to prevent these slots

7
00:00:22,410 --> 00:00:23,600
from happening.

8
00:00:23,600 --> 00:00:27,500
First we're going to look at the number
two vulnerability on the OS top ten.

9
00:00:27,500 --> 00:00:30,140
Broken authentication and
session management.

10
00:00:30,140 --> 00:00:34,450
Sessions and web apps are used to manage
the information that identifies a user.

11
00:00:34,450 --> 00:00:37,950
They are usually created when a user
logs into the web application,

12
00:00:37,950 --> 00:00:40,620
whether on the web or on mobile.

13
00:00:40,620 --> 00:00:42,670
Sessions make user's lives easy.

14
00:00:42,670 --> 00:00:44,900
They don't require users
that are logged in or

15
00:00:44,900 --> 00:00:47,640
recently logged in to enter
passwords on every new click.

16
00:00:48,720 --> 00:00:53,400
Before a session is created, when the user
logs in they typically pass through some

17
00:00:53,400 --> 00:00:57,160
kind of authentication mechanism, which
is often handled by a username password

18
00:00:57,160 --> 00:01:02,750
combination, a third party like Facebook
or Google, or two factor authentication.

19
00:01:02,750 --> 00:01:06,720
After a user is successfully
authenticated, a session is created with

20
00:01:06,720 --> 00:01:10,900
information that identifies that user for
the current use of the application.

21
00:01:10,900 --> 00:01:15,140
Usually via tokens or codes stored
within the applications cookies.

22
00:01:15,140 --> 00:01:19,580
With this knowledge an attacker can use
flies in the session authentication or

23
00:01:19,580 --> 00:01:23,350
session management functions
to impersonate other users.

24
00:01:23,350 --> 00:01:27,540
These attackers can be an external
attacker, a normal user with an account

25
00:01:27,540 --> 00:01:31,330
that is attempting to steal data from
other users, or someone on the inside of

26
00:01:31,330 --> 00:01:34,520
the company or group that wants
to disguise their actions.

27
00:01:34,520 --> 00:01:38,610
The functions used in session management
are often not implemented correctly.

28
00:01:38,610 --> 00:01:42,500
Which can allow attackers to see
your passwords, secret keys, and

29
00:01:42,500 --> 00:01:44,830
tokens used to authenticate sessions.

30
00:01:44,830 --> 00:01:48,680
By compromising this data,
attackers can take over users and accounts

31
00:01:48,680 --> 00:01:52,610
which can lead to severe consequences
about the user and for the developer.

32
00:01:53,880 --> 00:01:55,640
When building session workloads,

33
00:01:55,640 --> 00:01:58,990
developers need to implement
many pieces of functionality.

34
00:01:58,990 --> 00:02:02,430
By building custom authentication and
session management methods,

35
00:02:02,430 --> 00:02:06,320
developers often leave flaws
in a variety of functions.

36
00:02:06,320 --> 00:02:10,119
Finding flaws in these functions can
be difficult since implementations

37
00:02:10,119 --> 00:02:11,107
are often unique.

38
00:02:11,107 --> 00:02:13,835
Though session management
is a very diverse topic,

39
00:02:13,835 --> 00:02:17,499
there are three common flaws here
which every developer should know.

40
00:02:17,499 --> 00:02:21,430
First, application timeouts
were often set improperly.

41
00:02:21,430 --> 00:02:23,580
If an application token is compromised or

42
00:02:23,580 --> 00:02:26,980
leaked, properly set
timeouts prevent an attacker

43
00:02:26,980 --> 00:02:31,930
from using a token to impersonate the user
if the token was generated too long ago.

44
00:02:31,930 --> 00:02:36,040
However, tokens are often left valid for
days or even weeks.

45
00:02:36,040 --> 00:02:39,530
Second, attackers can acquire
a user's session ID or

46
00:02:39,530 --> 00:02:43,020
token from network traffic by
getting in between a user and

47
00:02:43,020 --> 00:02:45,630
the application on an unsecured
network connection.

48
00:02:45,630 --> 00:02:49,700
If the session ID is in the URL or
unencrypted in the request body,

49
00:02:49,700 --> 00:02:53,680
then the attacker can capture it from
network traffic and use it as they wish.

50
00:02:53,680 --> 00:02:55,650
Third, an internal attacker or

51
00:02:55,650 --> 00:03:00,400
a remote attacker can gain access to the
user database via a variety of methods.

52
00:03:00,400 --> 00:03:02,100
If passwords are not hashed,

53
00:03:02,100 --> 00:03:05,780
then these passwords can be directly
used to log in as the user.

54
00:03:05,780 --> 00:03:07,060
Good news for us, though.

55
00:03:07,060 --> 00:03:11,350
Preventing session management issues
is easily prevented in most cases.

56
00:03:11,350 --> 00:03:15,530
First, user authentication credentials
should always be hashed when stored and

57
00:03:15,530 --> 00:03:17,570
sent over encrypted connection.

58
00:03:17,570 --> 00:03:20,610
Session tokens should never
be exposed in the URL,

59
00:03:20,610 --> 00:03:23,670
since this is sent in
the clear in most cases.

60
00:03:23,670 --> 00:03:28,480
Session tokens should also timeout after a
short time, and be invalidated at logout.

61
00:03:28,480 --> 00:03:31,790
THis prevents attackers from stealing
a session token and using it over and

62
00:03:31,790 --> 00:03:34,460
over again to access a user's account.

63
00:03:34,460 --> 00:03:36,880
In addition to invalidating
tokens at logout,

64
00:03:36,880 --> 00:03:39,740
they should always be recreated on logins.

65
00:03:39,740 --> 00:03:41,810
Finally, these credentials should always,

66
00:03:41,810 --> 00:03:46,960
always, always be sent over HEPS,
with no exceptions.

67
00:03:46,960 --> 00:03:48,450
By following these simple rules,

68
00:03:48,450 --> 00:03:51,780
the majority of session management
flaws can be prevented.

69
00:03:51,780 --> 00:03:56,580
Remember, using well known authentication
methods such as OAuth 2.0 can

70
00:03:56,580 --> 00:03:58,670
prevent many of these issues.

71
00:03:58,670 --> 00:04:02,210
These topics are covered as well in
several other Treehouse courses.

72
00:04:02,210 --> 00:04:05,700
In particular, the introduction
to application security course.

73
00:04:06,730 --> 00:04:09,980
To really explore how session
management issues arise in an app,

74
00:04:09,980 --> 00:04:12,470
let's look back in our
app from the first stage.

75
00:04:12,470 --> 00:04:16,410
In our application, user passwords
are start without hashing them first,

76
00:04:16,410 --> 00:04:23,370
which we can see by looking at
the user model in userdao.js.

77
00:04:23,370 --> 00:04:27,890
To fix this issue, we can use the bcrypt
algorithm, the currently most trusted

78
00:04:27,890 --> 00:04:32,170
password hashing algorithm, with
implementations in nearly every language.

79
00:04:32,170 --> 00:04:35,920
With bcrypt, we first generate a salt for
the password.

80
00:04:35,920 --> 00:04:39,260
A salt essentially adds more
difficulty to breaking the password.

81
00:04:39,260 --> 00:04:41,480
In practice, a salt is a random,

82
00:04:41,480 --> 00:04:45,548
unique, per-user complex string added
to every password before hashing.

83
00:04:45,548 --> 00:04:48,720
By doing this, developers can
prevent attackers from calculating

84
00:04:48,720 --> 00:04:52,490
the corresponding hashes for
common passwords ahead of time.

85
00:04:52,490 --> 00:04:55,390
Where those common passwords can come
from data breaches that other users

86
00:04:55,390 --> 00:04:59,890
can be exposed in or they could come from
common password combinations in lists.

87
00:04:59,890 --> 00:05:04,110
These precomputed passwords make up
something called a rainbow table, and

88
00:05:04,110 --> 00:05:07,000
using a salt with a strong
algorithm such as B-grip.

89
00:05:07,000 --> 00:05:09,920
We can prevent our hash
passwords from being translated

90
00:05:09,920 --> 00:05:12,610
back to the actual password
in nearly all cases,

91
00:05:12,610 --> 00:05:15,980
even if the attacker has
the fastest modern super computer.

92
00:05:15,980 --> 00:05:20,870
With the salt calculated pick up library,
we hash the user's password with the salt.

93
00:05:32,336 --> 00:05:35,228
By hashing the password and
storing the password hash,

94
00:05:35,228 --> 00:05:39,412
when a user attempts to login with a plain
text non-hashed password, we can then

95
00:05:39,412 --> 00:05:44,200
proceed to hash the entered password and
check it against the stored hash password.

96
00:05:44,200 --> 00:05:47,070
If this two match,
we know the user can be authenticated and

97
00:05:47,070 --> 00:05:48,250
proceed to the application.

98
00:05:54,441 --> 00:05:58,940
Another issue with our application is the
no time out is forced in the user session.

99
00:05:58,940 --> 00:06:03,490
Which means the session will say active
until the user explicitly logs out,

100
00:06:03,490 --> 00:06:05,620
even if the browser window is closed.

101
00:06:05,620 --> 00:06:06,570
Even worse,

102
00:06:06,570 --> 00:06:10,290
the application does not prevent cookies
from being accessed via JavaScript,

103
00:06:10,290 --> 00:06:14,790
which leaves the site vulnerable to XSS
attacks as we discussed in the last stage.

104
00:06:14,790 --> 00:06:19,410
Not only are cookies able to be accessed
via JavaScript, queries also be sent over

105
00:06:19,410 --> 00:06:22,830
unsecured connects,
meaning the sessions lack encryption.

106
00:06:22,830 --> 00:06:27,124
When the session lack encryption, the
attacker can steal the session ID if they

107
00:06:27,124 --> 00:06:31,610
able to intercept user's traffic, which
can be easily done if you and the attacker

108
00:06:31,610 --> 00:06:35,608
are sitting together in a coffee shop
on a public unsecured WiFi connect.

109
00:06:35,608 --> 00:06:39,881
In order to address these issues we need
to close the session when the browser

110
00:06:39,881 --> 00:06:41,829
closes and when the user logs out.

111
00:06:41,829 --> 00:06:46,037
And we also need to add headers to the
HTTP request to ensure that cookies can be

112
00:06:46,037 --> 00:06:47,545
accessed via JavaScript.

113
00:06:47,545 --> 00:06:52,380
And the cookies can't be sent over
non-secure, or non-HTTPS connections.

114
00:06:52,380 --> 00:06:55,644
In a video later in the stage, we will
make the application speak over HTTPS.

115
00:06:55,644 --> 00:06:59,400
But for now,
let's deal with the cookie issues.

116
00:06:59,400 --> 00:07:00,500
Within our application,

117
00:07:00,500 --> 00:07:03,620
we need to make sure that the max
age setting is on cookies.

118
00:07:03,620 --> 00:07:07,700
Which means express with these session
cookies will be invalidated on browser

119
00:07:07,700 --> 00:07:08,827
close analogue out.

120
00:07:08,827 --> 00:07:11,330
Now, let's add this in
the main server file.

121
00:07:13,367 --> 00:07:16,990
First we will set
the maximum age to one day.

122
00:07:16,990 --> 00:07:20,869
Then we will ensure the cookies
are invalidated when the browser closes.

123
00:07:33,759 --> 00:07:36,710
In other languages,
this same kind of thing can be done, so

124
00:07:36,710 --> 00:07:40,320
refer to the documentation for
your particular web framework.

125
00:07:40,320 --> 00:07:43,930
Next, you must ensure that cookies
are only sent over https and

126
00:07:43,930 --> 00:07:45,850
not accessible via Java Script.

127
00:07:45,850 --> 00:07:48,820
To do this, we can set the http only and

128
00:07:48,820 --> 00:07:52,100
secure http headers in
the main server file as well.

129
00:07:59,090 --> 00:08:03,580
We could also use JavaScript libraries
to set specific http headers

130
00:08:03,580 --> 00:08:04,980
to add more security.

131
00:08:04,980 --> 00:08:07,002
The best known library for this is Helmet,

132
00:08:07,002 --> 00:08:10,159
which we'll discuss in the video
on security misconfiguration.

133
00:08:10,159 --> 00:08:14,060
Regardless of language, these features
are available nearly anywhere, so look for

134
00:08:14,060 --> 00:08:17,910
them when you implement
authentication in your applications.

135
00:08:17,910 --> 00:08:21,360
Before we move on to broken access
controls in the next video,

136
00:08:21,360 --> 00:08:25,840
let's wrap up session management by
discussing password handling issues.

137
00:08:25,840 --> 00:08:29,720
When developers don't require strong
passwords, attackers can more easily

138
00:08:29,720 --> 00:08:33,700
guess passwords and break into user
accounts via brute force methods.

139
00:08:33,700 --> 00:08:36,680
Unfortunately for developers,
there are many security tools for

140
00:08:36,680 --> 00:08:39,570
guessing passwords as
efficient as possible and

141
00:08:39,570 --> 00:08:43,340
with the ability to try many
common password combinations.

142
00:08:43,340 --> 00:08:45,170
To prevent password brute-force attacks,

143
00:08:45,170 --> 00:08:48,560
developers must ensure passwords
are long and complex.,

144
00:08:48,560 --> 00:08:53,040
preferably more than eight characters,
and requiring both letters and numbers.

145
00:08:53,040 --> 00:08:56,340
And if possible,
special characters like punctuation.

146
00:08:56,340 --> 00:09:00,410
Another flaw in apps occurs when apps
divulge more information than necessary

147
00:09:00,410 --> 00:09:02,590
on an unsuccessful log in attempt.

148
00:09:02,590 --> 00:09:05,580
Authentication responses should never
indicate which part of the data

149
00:09:05,580 --> 00:09:06,890
was incorrect.

150
00:09:06,890 --> 00:09:11,000
For example, instead of saying
invalid username or invalid password,

151
00:09:11,000 --> 00:09:14,890
simply use invalid username and
or password or just log in error.

152
00:09:15,950 --> 00:09:17,540
Even though this may be frustrating for

153
00:09:17,540 --> 00:09:20,510
innocent users,
this simple fix prevents attackers from

154
00:09:20,510 --> 00:09:24,290
easily knowing whether their brute
force attempts are working effectively.

155
00:09:24,290 --> 00:09:27,160
Beyond simply requiring complex passwords,

156
00:09:27,160 --> 00:09:30,900
developers can disable accounts after
too many failed login attempts.

157
00:09:30,900 --> 00:09:34,050
This prevents attackers from
trying to log in too many times,

158
00:09:34,050 --> 00:09:37,010
while allowing normal users who
simply forget their password

159
00:09:37,010 --> 00:09:40,000
to just have to wait some time
before logging back in again.

160
00:09:40,000 --> 00:09:44,060
As we've discussed, session management
flaws can arise in many, many ways.

161
00:09:44,060 --> 00:09:45,690
Most of these flaws can be prevented.

162
00:09:45,690 --> 00:09:49,770
In the next video we'll look beyond
authentication towards how a developer

163
00:09:49,770 --> 00:09:52,780
can apply permission to users for
preventing security flaws