Hello and welcome to the Cyber Eri secure coding course. My name is anywhere, and this is a WASP top 10 for 2013
a two broken authentication and session management.
Now first, let's start with our definition for this particular category
application functions related to authentication and session management are often not implemented correctly.
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
that contained the threat agents attack vectors,
security weakness, description and then the impacts,
we can see that the attack factors in this area
haven't exploit ability of average.
The technical impacts are severe
now. If we look at the security weakness itself,
it's described as the following. Developers frequently build custom authentication and session management schemes,
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
timeouts. Remember me secret question account updates, etcetera.
Finding such flaws can sometimes be difficult
as each implementation is unique, and furthermore, I'd like to add that finding these flaws can sometimes on Lee, be done
through a manual security code review
done with more senior level developers. Let's take a look at some of the possible attacks in this area.
Session fixation is certainly one of them. Now. Session fixation
is where an attacker is fixated on a a particular session token or cookie.
It's usually revolving around cookie security, and I have some examples in the bullets of session fixations.
So the first example is where
the cookie setting actually remains the same after log in.
So initially, when you go to a website,
more than likely, there will be some sort of initial cookie
before you actually authenticated on the website.
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.
once you log in, however, that the J session idea that session I D or that cookie is supposed to change. Otherwise you can
fall prey to session fixation.
If the cookie were to remain the same, an attacker could get that cookie and then assume your identity.
Now, another example of where session fixation could occur
is if the cookie value is very predictable.
So if a KN attacker is able to determine what the next numeric number is going to be,
then that that's a very easy attack or session I D to create on their own.
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
not setting the secure flag,
which generally is something can't that can be done either programmatically or through the Web server setting.
Now, also in this category, there's a lot about password management.
One of the attacks around password management is brute force attacks.
Now, brute force attacks generally can start with some sort of user name in new Marais shin.
So this enumeration is basically going to be a listing of all valid accounts.
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
now, as you're going to see in the demo.
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.
If it gives too much information, that could be a clue
that the attacker could possibly a numerator information that
should not be available to them,
information that would be stored in the database and should not be available to them.
Another way that brute force attacks can occur is if there's a very weak
password policy or no password policy enforcement at all.
Now, password policies are generally those things where a website will state
well, you have to have a minimum of eight characters in numbers. You have to have two special characters,
uh, in things like that.
Included in that password policy should be
things like no dictionary. Words are allowed,
and there should be some password aging set up.
Or you're not allowed to use
previous passwords, you know, up to the last 10 times.
And, of course, the main
than the main issue with real time
brute force attacks is that there's no account lockout, So generally
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,
and yet another area for brute force attacks would be insecure password storage.
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,
and so they should be encrypted or hashed inside of the database at all times.
Now, when passwords air not hashed when they're in clear text, then they can be easily susceptible to dictionary attacks,
provided all the other things remain as well that we've just discussed.
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
to the hashed password.
Passwords that air hashed but do not have a salt are susceptible to rainbow table attacks, which essentially are
dictionary words but computed with hashing functions that don't use assault.
So let's take a look at our first example where we have some sort of broken authentication session management design flaw.
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.
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
and after the log. And you can take a look at the cookie again
Now when that cookie has the same exact value
this is going to be a session fixation. Vulnerability. So basically, that means that an attacker could get hold of that cookie
and obviously used that same cookie to masquerade as the legitimate authenticated user.
Now, the case study we're going to take a look at is G mail cookie stealing and session hijacking.
It actually corresponds very well to the slide that we just looked at.
This is a case where Gmail basically had encryption on Lee on the log in screen. This goat takes us back to 2011.
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
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,
you know, probably would it know to do. And so this article basically goes through a lot of the
session hijacking, session, fixation, type, vulnerabilities and exploitations that occurred because of that flaw.
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.
So the rule states never hard code sensitive information.
Now, in this particular example, we have the user name and password, actually,
of the account that's used by the application to connect to the database.
And that information is actually hard coded right into strings within the code itself.
Now, there are a lot of reasons why
this is problematic. First of all,
it means that you're using the same username and password in every single environment,
which is the first problem.
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
be lifted by Attackers and d compiled
or even run three d buggers to be read in memory.
Another problem is that
when it comes to external cloud storage areas, this has become something that is commonly done.
The main reason why is because there's sort of this destroy nted
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.
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.
Now the compliant version of this is to, of course, externalized
that applications database account information. Now, when I say externalize, I mean
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
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
it is encrypted inside of the database. And if it's Oracle, there are
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.
Yes, it's going to be decrypted,
but it obviously has to be in order to in order to make that connection.
But at least your transient time of decryption should be minimized, as opposed to heart coating it inside of your source code.
So now we're going to move forward into the demo section of our module.