[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.