This course will be retired on June 1, 2025.
Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Well done!
You have completed OWASP Top 10 Vulnerabilities!
You have completed OWASP Top 10 Vulnerabilities!
Preview
In this attack, an attacker (who can be anonymous external attacker, a user with own account who may attempt to steal data from accounts, or an insider wanting to disguise his or her actions) uses leaks or flaws in the authentication or session management functions to impersonate other users. Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities.
Related Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign upRelated Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign up
[MUSIC]
0:00
Welcome back, over the next few videos
we'll be looking into how developers fail
0:05
to protect the basic gateways to
their application and its users.
0:09
From authentication methods,
0:13
to user authorization, developers tend
to mess up in this area far too often.
0:14
It's our goal in this stage to
explore ways to prevent these slots
0:19
from happening.
0:22
First we're going to look at the number
two vulnerability on the OS top ten.
0:23
Broken authentication and
session management.
0:27
Sessions and web apps are used to manage
the information that identifies a user.
0:30
They are usually created when a user
logs into the web application,
0:34
whether on the web or on mobile.
0:37
Sessions make user's lives easy.
0:40
They don't require users
that are logged in or
0:42
recently logged in to enter
passwords on every new click.
0:44
Before a session is created, when the user
logs in they typically pass through some
0:48
kind of authentication mechanism, which
is often handled by a username password
0:53
combination, a third party like Facebook
or Google, or two factor authentication.
0:57
After a user is successfully
authenticated, a session is created with
1:02
information that identifies that user for
the current use of the application.
1:06
Usually via tokens or codes stored
within the applications cookies.
1:10
With this knowledge an attacker can use
flies in the session authentication or
1:15
session management functions
to impersonate other users.
1:19
These attackers can be an external
attacker, a normal user with an account
1:23
that is attempting to steal data from
other users, or someone on the inside of
1:27
the company or group that wants
to disguise their actions.
1:31
The functions used in session management
are often not implemented correctly.
1:34
Which can allow attackers to see
your passwords, secret keys, and
1:38
tokens used to authenticate sessions.
1:42
By compromising this data,
attackers can take over users and accounts
1:44
which can lead to severe consequences
about the user and for the developer.
1:48
When building session workloads,
1:53
developers need to implement
many pieces of functionality.
1:55
By building custom authentication and
session management methods,
1:58
developers often leave flaws
in a variety of functions.
2:02
Finding flaws in these functions can
be difficult since implementations
2:06
are often unique.
2:10
Though session management
is a very diverse topic,
2:11
there are three common flaws here
which every developer should know.
2:13
First, application timeouts
were often set improperly.
2:17
If an application token is compromised or
2:21
leaked, properly set
timeouts prevent an attacker
2:23
from using a token to impersonate the user
if the token was generated too long ago.
2:26
However, tokens are often left valid for
days or even weeks.
2:31
Second, attackers can acquire
a user's session ID or
2:36
token from network traffic by
getting in between a user and
2:39
the application on an unsecured
network connection.
2:43
If the session ID is in the URL or
unencrypted in the request body,
2:45
then the attacker can capture it from
network traffic and use it as they wish.
2:49
Third, an internal attacker or
2:53
a remote attacker can gain access to the
user database via a variety of methods.
2:55
If passwords are not hashed,
3:00
then these passwords can be directly
used to log in as the user.
3:02
Good news for us, though.
3:05
Preventing session management issues
is easily prevented in most cases.
3:07
First, user authentication credentials
should always be hashed when stored and
3:11
sent over encrypted connection.
3:15
Session tokens should never
be exposed in the URL,
3:17
since this is sent in
the clear in most cases.
3:20
Session tokens should also timeout after a
short time, and be invalidated at logout.
3:23
THis prevents attackers from stealing
a session token and using it over and
3:28
over again to access a user's account.
3:31
In addition to invalidating
tokens at logout,
3:34
they should always be recreated on logins.
3:36
Finally, these credentials should always,
3:39
always, always be sent over HEPS,
with no exceptions.
3:41
By following these simple rules,
3:46
the majority of session management
flaws can be prevented.
3:48
Remember, using well known authentication
methods such as OAuth 2.0 can
3:51
prevent many of these issues.
3:56
These topics are covered as well in
several other Treehouse courses.
3:58
In particular, the introduction
to application security course.
4:02
To really explore how session
management issues arise in an app,
4:06
let's look back in our
app from the first stage.
4:09
In our application, user passwords
are start without hashing them first,
4:12
which we can see by looking at
the user model in userdao.js.
4:16
To fix this issue, we can use the bcrypt
algorithm, the currently most trusted
4:23
password hashing algorithm, with
implementations in nearly every language.
4:27
With bcrypt, we first generate a salt for
the password.
4:32
A salt essentially adds more
difficulty to breaking the password.
4:35
In practice, a salt is a random,
4:39
unique, per-user complex string added
to every password before hashing.
4:41
By doing this, developers can
prevent attackers from calculating
4:45
the corresponding hashes for
common passwords ahead of time.
4:48
Where those common passwords can come
from data breaches that other users
4:52
can be exposed in or they could come from
common password combinations in lists.
4:55
These precomputed passwords make up
something called a rainbow table, and
4:59
using a salt with a strong
algorithm such as B-grip.
5:04
We can prevent our hash
passwords from being translated
5:07
back to the actual password
in nearly all cases,
5:09
even if the attacker has
the fastest modern super computer.
5:12
With the salt calculated pick up library,
we hash the user's password with the salt.
5:15
By hashing the password and
storing the password hash,
5:32
when a user attempts to login with a plain
text non-hashed password, we can then
5:35
proceed to hash the entered password and
check it against the stored hash password.
5:39
If this two match,
we know the user can be authenticated and
5:44
proceed to the application.
5:47
Another issue with our application is the
no time out is forced in the user session.
5:54
Which means the session will say active
until the user explicitly logs out,
5:58
even if the browser window is closed.
6:03
Even worse,
6:05
the application does not prevent cookies
from being accessed via JavaScript,
6:06
which leaves the site vulnerable to XSS
attacks as we discussed in the last stage.
6:10
Not only are cookies able to be accessed
via JavaScript, queries also be sent over
6:14
unsecured connects,
meaning the sessions lack encryption.
6:19
When the session lack encryption, the
attacker can steal the session ID if they
6:22
able to intercept user's traffic, which
can be easily done if you and the attacker
6:27
are sitting together in a coffee shop
on a public unsecured WiFi connect.
6:31
In order to address these issues we need
to close the session when the browser
6:35
closes and when the user logs out.
6:39
And we also need to add headers to the
HTTP request to ensure that cookies can be
6:41
accessed via JavaScript.
6:46
And the cookies can't be sent over
non-secure, or non-HTTPS connections.
6:47
In a video later in the stage, we will
make the application speak over HTTPS.
6:52
But for now,
let's deal with the cookie issues.
6:55
Within our application,
6:59
we need to make sure that the max
age setting is on cookies.
7:00
Which means express with these session
cookies will be invalidated on browser
7:03
close analogue out.
7:07
Now, let's add this in
the main server file.
7:08
First we will set
the maximum age to one day.
7:13
Then we will ensure the cookies
are invalidated when the browser closes.
7:16
In other languages,
this same kind of thing can be done, so
7:33
refer to the documentation for
your particular web framework.
7:36
Next, you must ensure that cookies
are only sent over https and
7:40
not accessible via Java Script.
7:43
To do this, we can set the http only and
7:45
secure http headers in
the main server file as well.
7:48
We could also use JavaScript libraries
to set specific http headers
7:59
to add more security.
8:03
The best known library for this is Helmet,
8:04
which we'll discuss in the video
on security misconfiguration.
8:07
Regardless of language, these features
are available nearly anywhere, so look for
8:10
them when you implement
authentication in your applications.
8:14
Before we move on to broken access
controls in the next video,
8:17
let's wrap up session management by
discussing password handling issues.
8:21
When developers don't require strong
passwords, attackers can more easily
8:25
guess passwords and break into user
accounts via brute force methods.
8:29
Unfortunately for developers,
there are many security tools for
8:33
guessing passwords as
efficient as possible and
8:36
with the ability to try many
common password combinations.
8:39
To prevent password brute-force attacks,
8:43
developers must ensure passwords
are long and complex.,
8:45
preferably more than eight characters,
and requiring both letters and numbers.
8:48
And if possible,
special characters like punctuation.
8:53
Another flaw in apps occurs when apps
divulge more information than necessary
8:56
on an unsuccessful log in attempt.
9:00
Authentication responses should never
indicate which part of the data
9:02
was incorrect.
9:05
For example, instead of saying
invalid username or invalid password,
9:06
simply use invalid username and
or password or just log in error.
9:11
Even though this may be frustrating for
9:15
innocent users,
this simple fix prevents attackers from
9:17
easily knowing whether their brute
force attempts are working effectively.
9:20
Beyond simply requiring complex passwords,
9:24
developers can disable accounts after
too many failed login attempts.
9:27
This prevents attackers from
trying to log in too many times,
9:30
while allowing normal users who
simply forget their password
9:34
to just have to wait some time
before logging back in again.
9:37
As we've discussed, session management
flaws can arise in many, many ways.
9:40
Most of these flaws can be prevented.
9:44
In the next video we'll look beyond
authentication towards how a developer
9:45
can apply permission to users for
preventing security flaws
9:49
You need to sign up for Treehouse in order to download course files.
Sign upYou need to sign up for Treehouse in order to set up Workspace
Sign up