Hello and welcome to the cyber very secure coding course.
My name is anywhere, and this is a WASP top 10 for 2013 a two broken authentication and session management medications, countermeasures and defenses. Now an overview of our defenses. We've basically talked about two different areas
broken authentication and session management.
Now, in terms of mitigations, countermeasures and defenses in broken authentication. We learned particularly from the demo that we cannot have our air messages or even our success messages
give Attackers any type of clue as to what may have changed between requests. So when we saw the failed attempt and we saw one message and then we saw a success when we saw a different message,
we were actually able to key off of the success message in the demo case
and the numerator, all of the user names in the
Another thing that we looked at is Theseus. Ample code where we never want a hard code, any credentials into our code for several reasons. We do not want to have this as part of the binary. It also means that you're using the same credentials in every single environment
from development. All the way to production.
So instead, what we want to do is we want to externalize thes credentials, either placing them in a property's file, a configuration file or database. And even when we do that, we want to make sure that the password itself is being protected through encryption.
We also talked about password policy enforcement. Now, this is where we make sure our users air not using dictionary words for their passwords.
We also want to enforce aging, which means passwords expire after a certain number of days, it must be reset.
Strength, of course, has to do with the length of passwords
and what could be contained in them. And then finally, we talked about good password. Management means that all passwords are hashed in the database and they include salts.
Now, in the area of session management,
we've learned that we need to make sure our tokens, our session I D. S are unpredictable. Now, unpredictability is not going to come from a homegrown way of creating our randomness. We cannot use time stamps and things like that
as these are very easy to pick up on
by various attacker tools. And so we need to make sure unpredictability is done through secure randomness.
Also, we need to have expiration policies on our sessions, make sure that they time out after a reasonable amount of time. We also need to make sure that any kind of events like a log in or along out actually reset our session I. D. S.
We also need to protect our information, whether it's the communication, the traffic going back and forth between the browser and the server or the cookie. And we need to make sure that this protection comes over encryption T l s, of course, being what it is
preferred at this time.
We did speak about cookie security. The demo showed us some cookie manipulation with a very predictable cookie number that was being used for user I. D.
And we also know that the cookie needs to be protected with the HDP Onley and secure flags from manipulation.
Now let's take a look at the sample code that could be used to actually fix session fixation problem that we saw earlier.
So in the problem, we saw that the HDP response showed the cookie before log in and after log in. And in both cases, that session I d stored in the cookie remained the same.
So in order to address that particular problem, the first thing that we would need to do is actually go ahead and grab our current session. You're usually able to get this through the request object.
Then what you need to do is upon log and go ahead and invalidate that session,
and then you're going to go ahead and generate a new session. Now there might be attributes associated with the
original unauthenticated session that you want to retain. That's not a problem. You should be able to get those
attributes from that original session,
save them off and then assigned them to your new generated session.
So this concludes our
countermeasures in defenses. Let's move now into our labs.