In this lesson, I'll talk about web application threats and risks. So by the end of the lesson, you should tell me what those are as well and be able to explain some of the OWASP Top 10 access controls. Let's talk about the OWASP Top 10. OWASP stands for Open Web Application Security Project, started back in 2001 and officially really began in 2004. It was designed to educate about secure software and it still does that today. Every few years, there's a top 10 list that comes out. This represents the top 10 most critical risks to web applications on the Internet. It's released every few years to help developers and the community pay attention to these risks. The latest Top 10 came out in 2013. However, in 2017 in July or August, there should be a release of the content. We're going to talk about the 2017 release candidate today. And what we're going to do in these next few minutes is discuss only about the top six or seven. And then the other ones, they're not so much a concern, they're protection layers, okay? So the first one, it's injection. Injection have been at the top of the list as risks for years. This covers SQL injection, command injection, and LDAP injection. The attacker sends untrusted data to a system and it interprets the data. The attacker can do almost anything depending on what the software is, and what the software is running for the interpreter. So for example, if we wanted to have a little form and you wanted to calculate a value. Well if you're trying to use that form and execution as using a calculator as a system command in the background, you may have inadvertently opened up command injection. Because we could actually escape those characters and utilize other parts of the operating system. So this is, again, web applications, so you have to be careful that you're programming web applications out on the Internet correctly. The second access control is broken authentication and session management. User sessions can be hijacked. And many companies out there, once you log in, they either set a cookie or they set a session ID. Information can be stolen if they're not secured properly. So session IDs, usernames, passwords, account information, and cookies are all something that if not properly handled by the Web application, an attacker could steal that information and use it. So, for example, a cookie ID. If we sniffed that out of the air like on an open wireless connection for example, we can replay that cookie and gain access to that account. Poor authentication coding methods allow attackers to gain access because the session management is poorly secured. The third access control method is cross-site scripting, this is still very widespread. It can either be executed on the server or executed on the client and can be stored or reflected attacks. What happens in a cross-site scripting scenario is that an application uses untrusted data in the construction of the following. So on your screen you should see actually a payload that we can enter into a web form and what that's doing is it's escaping certain characters and actually displaying something back to the user. What happens is in this scenario I can display other information, so I can take what's displayed in that web form, display it back out to the user. However, if it's not properly controlled, we can do other things with it. We can inject viruses or we can steal people's information. The attack causes a victim's session ID, in the example here, to be sent to the attacker's website and allows the attacker to hijack the user's current session. The fourth access control is broken access control. The attackers use insufficient security measures to bypass authentication mechanisms. For example, this happens in parameters. So whenever I'm doing penetration testing on a web application, the very first thing I'm going to do is, in the example that you see on your screen, I'm going to go to http://example.com/app/accountinfo. And then the question mark equals or account equals and then I'm going to put in nothing. I'm going to start listing off values, and if I get information back, that is what we call broken access control. It doesn't properly sanitize information when there's a login form. In a previous lesson, we talked about access control risk number five, which is security misconfiguration. So if you want to learn more about that, rewatch the video. The sixth risk is sensitive data exposure. This is really just data exposure. Can happen any number of different ways. Most data breaches occur because someone did not encrypt the data properly. It can be used in conjunction with any of the other methods. It could be used on cross-site scripting. It could be used with command injection to obtain data on the server that is not encrypted. If we encrypt our data this problem wouldn't occur. However, most web applications do not securely encrypt our data, especially user names, passwords, and sensitive other data like credit card information. In A7 through A10, those access control risks dive into protection. A7 is going to be insufficient attack protection, such as antivirus, such as firewalls. A8 is going to be cross-site request forgery. While this isn't protection, it still acts as the same way as cross-site scripting. A9 uses the components from known vulnerabilities. So if we have to have a web application up, and we know there's a vulnerability in that application, we use it anyway. What about using LDAP, for example, for Microsoft access when we know that using plain old LDAP without security behind it is a vulnerability. Or using a piece of software that has a buffer overflow in it. And then the last one, A10, is going to be underprotected APIs, okay? APIs allow us to have great functionality into the SAS providers that we use on a day-to-day basis. However, some of those APIs are not secured and they allow us to gather more information than we have access to or that we need access to. So these are all issues that the organization has come up with to really show us that there's a lot of risks out there with running web applications. So here's the threats. I encourage you to go, actually look at the OWASP Top 10, and look at the threats and vulnerabilities out there and see how you can protect your organization. Or at least your security office can handle that kind of protection.
