[MUSIC] Hello again. In this final lesson of this module,
we're going to be talking about the OWASP proactive controls that are related to
session management and authentication. We're going to review our OWASP proactive
controls that we had mentioned earlier, and we're going to look at these proactive
controls in light of what we've been talking about in this module, with respect
to session management and authentication. Last, I will be going over
a summary of the mitigations. After this lesson, you'll be able to
discuss OWASP Proactive Controls, and how they will relate to session
management and authentication. So let's go. The first control that we mentioned in the
OWASP proactive controls was to define our security requirements
in our web application. And this is done at
the beginning of the life cycle, the software development life cycle. And you iterate on this when new changes
to the application specification appears. This is fairly fundamental and prevents
a lot of types of vulnerabilities, of which one being session management and
authentication issues. Another control that we want to keep in
mind is to take advantage of existing security frameworks and libraries, and
using existing security frameworks and libraries also prevents many
kinds of vulnerabilities. In light of session management and authentication, existing web application
frameworks have components for session management and
authentication that you can leverage. For example, Apache Wicket, which is
an open source, component oriented, server-side, Java web application
framework, according to their home page. Apache Wicket provides a security
infrastructure for authentication and session management, so
you don't have to make your own. This is already been tried,
tested and debugged, and improved overtime, and you can get
more information about Apache Wicket in this corresponding URL on the slide. Another proactive control that OWASP has
mentioned, which is related to session management, and authentication, is
the idea of implementing digital identity. We want to understand, when we develop our
web application, we want to understand when we can rely on just having passwords
as a form of authentication, or if we need an added layer,
like multi-factor authentication. This goes back to knowing what your
security requirements are, and being able to classify the sensitivity levels for
the data that your application handles. Another proactive control that OWASP has
mentioned, which is related to session management in authentication,
is to protect data everywhere. Encrypting data in transit
is especially important, in light of how sessions can
be created using cookies. And cookies need to be protected when
being transmitted between the client and the server. Another one that I want to call
out is this proactive control of implementing security logging and
monitoring. Now, security logging is especially
important when we want to collect information during intrusion detection and
intrusion analysis. Specifically, when we'd like to know if
there has been authentication attempts by. This information can be used
to get a larger picture when dealing with intrusion analysis,
and of course, intrusion detection. Now, here's a summary of the mitigations
mentioned in module three. By no means is this a complete list,
but this is the most generalized list that I've created for
the mitigations mentioned in module three. So one thing that I had just mentioned
earlier is to take advantage of logging password failures and logging all account lockouts,
in order to help incident response. Another thing that we want to do in
order to mitigate issues is to manage the session lifecycle well. So you want to define this in your
security requirements and of course, use an existing web application
framework to help you build it out. Another thing that we can do is to
explicitly design our access control security policy, and we would want to
define this in our security requirements. Another thing that we would want
to make sure to do is to model or to signify the access rights of
users on the server side, so that we want to make sure that there
aren't any issues with the client side being more in the control or
the hands of an untrusted user. We also want to make sure to create
session IDs that are at least 128 bits in length. We want to also associate session IDs
to their particular TLS connection and we want to have a 1:1 correspondence
with a session ID to one TLS connection to make sure that no hijacking, or rather,
session hijacking, can be possible. We want to double check and ensure that
that the web application framework that we are using helps us to not just
blindly accept any session token, if our web application is
presented with one during log in. We also want to make sure that our web
application framework that we're using, the session tokens that it handles,
are cancelled on the browser side. And a server-side should force the browser
to return to a start page if our web application has been presented with
a session token, any old session token, during login. Last, we want to upon successful log in,
always generate a new session token. That's it for the summary of the
mitigations that we've mentioned in module 3 and a wrap up of the OWASP proactive
controls, in light of what we have been talking about with session management
and authentication in module 3. That's it for now, thanks for listening.