[MUSIC]

Welcome back, over the next few videos we'll be looking into how developers fail

to protect the basic gateways to their application and its users.

From authentication methods,

to user authorization, developers tend to mess up in this area far too often.

It's our goal in this stage to explore ways to prevent these slots

from happening.

First we're going to look at the number two vulnerability on the OS top ten.

Broken authentication and session management.

Sessions and web apps are used to manage the information that identifies a user.

They are usually created when a user logs into the web application,

whether on the web or on mobile.

Sessions make user's lives easy.

They don't require users that are logged in or

recently logged in to enter passwords on every new click.

Before a session is created, when the user logs in they typically pass through some

kind of authentication mechanism, which is often handled by a username password

combination, a third party like Facebook or Google, or two factor authentication.

After a user is successfully authenticated, a session is created with

information that identifies that user for the current use of the application.

Usually via tokens or codes stored within the applications cookies.

With this knowledge an attacker can use flies in the session authentication or

session management functions to impersonate other users.

These attackers can be an external attacker, a normal user with an account

that is attempting to steal data from other users, or someone on the inside of

the company or group that wants to disguise their actions.

The functions used in session management are often not implemented correctly.

Which can allow attackers to see your passwords, secret keys, and

tokens used to authenticate sessions.

By compromising this data, attackers can take over users and accounts

which can lead to severe consequences about the user and for the developer.

When building session workloads,

developers need to implement many pieces of functionality.

By building custom authentication and session management methods,

developers often leave flaws in a variety of functions.

Finding flaws in these functions can be difficult since implementations

are often unique.

Though session management is a very diverse topic,

there are three common flaws here which every developer should know.

First, application timeouts were often set improperly.

If an application token is compromised or

leaked, properly set timeouts prevent an attacker

from using a token to impersonate the user if the token was generated too long ago.

However, tokens are often left valid for days or even weeks.

Second, attackers can acquire a user's session ID or

token from network traffic by getting in between a user and

the application on an unsecured network connection.

If the session ID is in the URL or unencrypted in the request body,

then the attacker can capture it from network traffic and use it as they wish.

Third, an internal attacker or

a remote attacker can gain access to the user database via a variety of methods.

If passwords are not hashed,

then these passwords can be directly used to log in as the user.

Good news for us, though.

Preventing session management issues is easily prevented in most cases.

First, user authentication credentials should always be hashed when stored and

sent over encrypted connection.

Session tokens should never be exposed in the URL,

since this is sent in the clear in most cases.

Session tokens should also timeout after a short time, and be invalidated at logout.

THis prevents attackers from stealing a session token and using it over and

over again to access a user's account.

In addition to invalidating tokens at logout,

they should always be recreated on logins.

Finally, these credentials should always,

always, always be sent over HEPS, with no exceptions.

By following these simple rules,

the majority of session management flaws can be prevented.

Remember, using well known authentication methods such as OAuth 2.0 can

prevent many of these issues.

These topics are covered as well in several other Treehouse courses.

In particular, the introduction to application security course.

To really explore how session management issues arise in an app,

let's look back in our app from the first stage.

In our application, user passwords are start without hashing them first,

which we can see by looking at the user model in userdao.js.

To fix this issue, we can use the bcrypt algorithm, the currently most trusted

password hashing algorithm, with implementations in nearly every language.

With bcrypt, we first generate a salt for the password.

A salt essentially adds more difficulty to breaking the password.

In practice, a salt is a random,

unique, per-user complex string added to every password before hashing.

By doing this, developers can prevent attackers from calculating

the corresponding hashes for common passwords ahead of time.

Where those common passwords can come from data breaches that other users

can be exposed in or they could come from common password combinations in lists.

These precomputed passwords make up something called a rainbow table, and

using a salt with a strong algorithm such as B-grip.

We can prevent our hash passwords from being translated

back to the actual password in nearly all cases,

even if the attacker has the fastest modern super computer.

With the salt calculated pick up library, we hash the user's password with the salt.

By hashing the password and storing the password hash,

when a user attempts to login with a plain text non-hashed password, we can then

proceed to hash the entered password and check it against the stored hash password.

If this two match, we know the user can be authenticated and

proceed to the application.

Another issue with our application is the no time out is forced in the user session.

Which means the session will say active until the user explicitly logs out,

even if the browser window is closed.

Even worse,

the application does not prevent cookies from being accessed via JavaScript,

which leaves the site vulnerable to XSS attacks as we discussed in the last stage.

Not only are cookies able to be accessed via JavaScript, queries also be sent over

unsecured connects, meaning the sessions lack encryption.

When the session lack encryption, the attacker can steal the session ID if they

able to intercept user's traffic, which can be easily done if you and the attacker

are sitting together in a coffee shop on a public unsecured WiFi connect.

In order to address these issues we need to close the session when the browser

closes and when the user logs out.

And we also need to add headers to the HTTP request to ensure that cookies can be

accessed via JavaScript.

And the cookies can't be sent over non-secure, or non-HTTPS connections.

In a video later in the stage, we will make the application speak over HTTPS.

But for now, let's deal with the cookie issues.

Within our application,

we need to make sure that the max age setting is on cookies.

Which means express with these session cookies will be invalidated on browser

close analogue out.

Now, let's add this in the main server file.

First we will set the maximum age to one day.

Then we will ensure the cookies are invalidated when the browser closes.

In other languages, this same kind of thing can be done, so

refer to the documentation for your particular web framework.

Next, you must ensure that cookies are only sent over https and

not accessible via Java Script.

To do this, we can set the http only and

secure http headers in the main server file as well.

We could also use JavaScript libraries to set specific http headers

to add more security.

The best known library for this is Helmet,

which we'll discuss in the video on security misconfiguration.

Regardless of language, these features are available nearly anywhere, so look for

them when you implement authentication in your applications.

Before we move on to broken access controls in the next video,

let's wrap up session management by discussing password handling issues.

When developers don't require strong passwords, attackers can more easily

guess passwords and break into user accounts via brute force methods.

Unfortunately for developers, there are many security tools for

guessing passwords as efficient as possible and

with the ability to try many common password combinations.

To prevent password brute-force attacks,

developers must ensure passwords are long and complex.,

preferably more than eight characters, and requiring both letters and numbers.

And if possible, special characters like punctuation.

Another flaw in apps occurs when apps divulge more information than necessary

on an unsuccessful log in attempt.

Authentication responses should never indicate which part of the data

was incorrect.

For example, instead of saying invalid username or invalid password,

simply use invalid username and or password or just log in error.

Even though this may be frustrating for

innocent users, this simple fix prevents attackers from

easily knowing whether their brute force attempts are working effectively.

Beyond simply requiring complex passwords,

developers can disable accounts after too many failed login attempts.

This prevents attackers from trying to log in too many times,

while allowing normal users who simply forget their password

to just have to wait some time before logging back in again.

As we've discussed, session management flaws can arise in many, many ways.

Most of these flaws can be prevented.

In the next video we'll look beyond authentication towards how a developer

can apply permission to users for preventing security flaws