Part 2 Explanations
Video Activity
This lesson starts out with a definition of how application functions related to authentication and session management are often not implemented correctly, which allow attackers to access other's information and assume their identity. Participants in this lesson learn about threat agents, attack vectors as well as security weaknesses. The instructo...
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or
Already have an account? Sign In »
Video Description
This lesson starts out with a definition of how application functions related to authentication and session management are often not implemented correctly, which allow attackers to access other's information and assume their identity. Participants in this lesson learn about threat agents, attack vectors as well as security weaknesses. The instructor also discusses types of attacks such as: • The session fixation attack (cookie security) • Brute Force Attacks (password management) Participants also learn about A2-Broken authentication and session management samples and session fixation vulnerabilities. Finally, participants learn about the gmail cookie stealing and hijacking which occurred in 2011 as well as some sample code that is Java non-compliant as well as an example that is Java compliant.
Video Transcription
00:04
Hello and welcome to the Cyber Eri secure coding course. My name is anywhere, and this is a WASP top 10 for 2013
00:15
a two broken authentication and session management.
00:20
Now first, let's start with our definition for this particular category
00:26
application functions related to authentication and session management are often not implemented correctly.
00:36
This allows Attackers to compromise passwords, keys, session tokens or exploit other implementation flaws for the main goal of assuming other users identities. Now, if we take a look at the old lost charts
00:55
that contained the threat agents attack vectors,
00:58
security weakness, description and then the impacts,
01:02
we can see that the attack factors in this area
01:07
haven't exploit ability of average.
01:10
The technical impacts are severe
01:14
now. If we look at the security weakness itself,
01:17
it's described as the following. Developers frequently build custom authentication and session management schemes,
01:26
but building these correctly is hard to do. As a result, these customs schemes frequently have flaws in areas such as long out password management
01:38
timeouts. Remember me secret question account updates, etcetera.
01:45
Finding such flaws can sometimes be difficult
01:49
as each implementation is unique, and furthermore, I'd like to add that finding these flaws can sometimes on Lee, be done
02:00
through a manual security code review
02:04
done with more senior level developers. Let's take a look at some of the possible attacks in this area.
02:13
Session fixation is certainly one of them. Now. Session fixation
02:19
is where an attacker is fixated on a a particular session token or cookie.
02:28
It's usually revolving around cookie security, and I have some examples in the bullets of session fixations.
02:38
So the first example is where
02:43
the cookie setting actually remains the same after log in.
02:47
So initially, when you go to a website,
02:51
more than likely, there will be some sort of initial cookie
02:54
before you actually authenticated on the website.
02:59
Sometimes this is done to keep track of things that you've looked at. Or maybe there's a cart that is available a shopping cart.
03:07
And so
03:09
once you log in, however, that the J session idea that session I D or that cookie is supposed to change. Otherwise you can
03:21
fall prey to session fixation.
03:23
If the cookie were to remain the same, an attacker could get that cookie and then assume your identity.
03:32
Now, another example of where session fixation could occur
03:38
is if the cookie value is very predictable.
03:42
So if a KN attacker is able to determine what the next numeric number is going to be,
03:50
then that that's a very easy attack or session I D to create on their own.
03:58
Another example is where the cookie value is unencrypted, and so the user name and password is just shown in clear text. Now this is usually a result of
04:11
not setting the secure flag,
04:14
which generally is something can't that can be done either programmatically or through the Web server setting.
04:20
Now, also in this category, there's a lot about password management.
04:27
One of the attacks around password management is brute force attacks.
04:33
Now, brute force attacks generally can start with some sort of user name in new Marais shin.
04:42
So this enumeration is basically going to be a listing of all valid accounts.
04:47
Why start with random account names if you can go ahead and enumerated those accounts that are valid? Saves theater Acker. A lot of time
05:00
now, as you're going to see in the demo.
05:01
The way that username and admiration could possibly be done is through the use of some verbose error messages. So if an error message gives too much information, or even if it's not an air message, say it's a success message of some type.
05:19
If it gives too much information, that could be a clue
05:25
that the attacker could possibly a numerator information that
05:30
should not be available to them,
05:32
information that would be stored in the database and should not be available to them.
05:39
Another way that brute force attacks can occur is if there's a very weak
05:46
password policy or no password policy enforcement at all.
05:51
Now, password policies are generally those things where a website will state
05:57
well, you have to have a minimum of eight characters in numbers. You have to have two special characters,
06:04
uh, in things like that.
06:08
Included in that password policy should be
06:12
things like no dictionary. Words are allowed,
06:15
and there should be some password aging set up.
06:18
Or you're not allowed to use
06:21
previous passwords, you know, up to the last 10 times.
06:27
And, of course, the main
06:28
than the main issue with real time
06:31
brute force attacks is that there's no account lockout, So generally
06:38
on a lot of websites now we see there's usually a three or four attempt threshold and then once you reach that, the account is locked out,
06:49
and yet another area for brute force attacks would be insecure password storage.
06:56
So in general, passwords must be hashed. Now, hash, hashing or hashing functions are irreversible. So in other words, they don't actually ever get decrypted,
07:10
and so they should be encrypted or hashed inside of the database at all times.
07:18
Now, when passwords air not hashed when they're in clear text, then they can be easily susceptible to dictionary attacks,
07:28
provided all the other things remain as well that we've just discussed.
07:33
In addition,
07:35
sometimes companies will hash passwords. However, they will not use what's called salt. Now. Assault actually is a piece of randomness that is placed into the hashing function algorithm to provide strength
07:55
two
07:56
to the hashed password.
07:59
Passwords that air hashed but do not have a salt are susceptible to rainbow table attacks, which essentially are
08:07
dictionary words but computed with hashing functions that don't use assault.
08:16
So let's take a look at our first example where we have some sort of broken authentication session management design flaw.
08:26
So in this example, you can see that I have burps. We actually capturing a cookie at the log in page. Now, this particular session I d that's being used is a PHP session. I d.
08:41
So all I did was I made sure that I was not logged into the application. I went to the log in page and I actually did a refresh. I captured the cookie that is set on on the response. And then I went ahead and logged in
09:00
and after the log. And you can take a look at the cookie again
09:03
Now when that cookie has the same exact value
09:09
even after log in,
09:11
this is going to be a session fixation. Vulnerability. So basically, that means that an attacker could get hold of that cookie
09:22
and obviously used that same cookie to masquerade as the legitimate authenticated user.
09:31
Now, the case study we're going to take a look at is G mail cookie stealing and session hijacking.
09:37
It actually corresponds very well to the slide that we just looked at.
09:43
This is a case where Gmail basically had encryption on Lee on the log in screen. This goat takes us back to 2011.
09:56
So what used to happen is when you come to the log in screen. Gmail would switch from http to http s, but after you'd log in
10:07
all of your mail and your cookie would be exposed in clear text again and be placed back over. Http. Now, the only way that you could undo this is to go into the advanced settings at the time and turn on https yourself. Which, of course,
10:28
most users
10:28
you know, probably would it know to do. And so this article basically goes through a lot of the
10:37
session hijacking, session, fixation, type, vulnerabilities and exploitations that occurred because of that flaw.
10:45
Now four are certain secure coding standard example. This is in the job of programming language. But of course, the same principle can be applied to any programming language.
10:58
So the rule states never hard code sensitive information.
11:03
Now, in this particular example, we have the user name and password, actually,
11:09
of the account that's used by the application to connect to the database.
11:16
And that information is actually hard coded right into strings within the code itself.
11:24
Now, there are a lot of reasons why
11:26
this is problematic. First of all,
11:28
it means that you're using the same username and password in every single environment,
11:33
which is the first problem.
11:37
The second problem is that it becomes part of your binary, which means that this information is going to be more easily seen should your binaries b
11:50
be lifted by Attackers and d compiled
11:54
or even run three d buggers to be read in memory.
11:58
Another problem is that
12:01
when it comes to external cloud storage areas, this has become something that is commonly done.
12:11
The main reason why is because there's sort of this destroy nted
12:16
relationship where you have this external vendor, this third party that provides this cloud storage and so getting an account to that just seems sort of distant from the particular custom code that you're working on.
12:31
And so even more so. We're finding that this is being exploited that basically have developers connecting out into the cloud from their private data centers.
12:43
Now the compliant version of this is to, of course, externalized
12:48
that applications database account information. Now, when I say externalize, I mean
12:54
either put it in a configuration file or put it in a database, ensuring that either one of those options also provides encryption of that password. So
13:09
if you're using Java. You can use, for example, that Jason Library offers a very good utility for name value pairs that could be encrypted. And if you're going to store it in the database, you need to ensure that
13:26
it is encrypted inside of the database. And if it's Oracle, there are
13:31
de BMS crypto libraries and settings that can be done in order to ensure that when when the information is read in memory in transit.
13:43
Yes, it's going to be decrypted,
13:46
but it obviously has to be in order to in order to make that connection.
13:52
But at least your transient time of decryption should be minimized, as opposed to heart coating it inside of your source code.
14:03
So now we're going to move forward into the demo section of our module.
Up Next
Instructed By
Similar Content
