Oktane18: OWASP Top 10 and Okta Mitigate Identity Risks in Your Web Applications

Payal Pan: Welcome. Thank you for coming. Last breakout session of Oktane. How has it been so far? Awesome! So you guys are not hung over here. That's good. So today's topic is OWASP Top 10 and Okta and how do you go about mitigating identity risks for web applications. How many of you guys are familiar with OWASP? Wow, that's a good room. How many of you guys are actually using OWASP standards in your organization? Sure, okay, that's a decent number. For the rest of you folks who are not familiar with OWASP, OWASP stands for Open Web Application Security Project, and their focus is to help security and developer communities with their security development life cycle and their security programs. So today every company is basically rushing to get their features out in the market, and we talked about need for speed this morning during the keynote as well. So what's happening is companies are developing at a very crazy-fast pace and security, unfortunately, is always the afterthought for these stressed-out developers and the business folks who are pushing them to get their features out. And so what's happening is, because of that there are a lot of not-so-good consequences with the breaches that are happening. And this is exactly why OWASP is out there to help educate these developers and security folks to mitigate these types of risks, prevent these types of issues. And what they do is they provide the application security verification standards and they also release a Top 10 list of vulnerabilities. They do that every two or three years and they release a Top 10 risks and let me show you what that looks like.

And so those are the Top 10 risks that they have released and basically what they do is that's more around for education. They provide tools around how do you go about mitigating them, detection tools, all of those. So one thing they do is they don't recommend specific commercial solutions. They are vendor-neutral. They may say that hey, for this type of risk it's better to use a commercial solution, but they will never recommend any specific ones. So they have a lot of open source solutions out there and then they try to stay away from vendors as much as possible. So let's look at the Top 10 list here. Oh, I should show you guys the real one here. So if you go to the OWASP.org, you will see the Top 10 list there and you will see all the standard ones out here. You have the injection, broken authentication, XSS. These are all in the Top 10 list and I think the last one they released was in 2013 and a few of those have changed since then. Most of them have still been in the same list. And the way these are sorted is by the likelihood of these risks, as well as the impact of these risks. And there's some other factors that they consider when they have put out these lists as well. So let's look at each of them quickly. We'll be focusing on identity-based risk today, but I'm going to go over each of them quickly, so you guys know what those are. So injection. Injection stands for a basic ... this is a type of an attack and could be a SQL injection or and LDAP injection where the attacker is trying to execute a query, like a malicious query, to steal your information. So in this example that we see, this is a SQL injection example where this query tries to select account number and balance from accounts with owner_id equals 1000. Now if your web application is taking that owner_id as an input and it's not protected for SQL injections, the attacker can insert ... they can inject zero or one equals one in the input field and your query will execute behind the scenes. And this leads to ... this is equals true and it'll basically leak out all the account number and balance information from a database.

And so to mitigate this type of a risk, you have to use parametrized queries. And what that does is the database basically pre-compiles the query before it gets executed, and it binds the variable that's expected to the query. And so, once it's compiled, it cannot change. And so now the attacker, when he's trying to enter zero or one equals one, that query fails because it's expecting one user ID field out there. Broken authentication sits number two in the list and this is a type of attack that basically attackers are trying to steal your credentials and get access to your account. This is an identity-based risk that we will try to get into more detail, so I'll talk about that later on. Sensitive data exposure. This is a type of attack where your web application is not securing your customer's sensitive information, be it at rest or in transit. And to mitigate this type of risk, you have to implement TLS and you have to secure and encrypt information, sensitive information about the customer everywhere in the web application.

XML External Entities, and this is a type of an attack where your application is taking in XML inputs that can have external entities references. So this could be used where you want to have some value passed into the XML like an hostname. And what this does is this basically, the parser reads that information and it substitutes that value for your application. And the attacker can take advantage of that and they can pass the password file location for the Unix systems there. And when your parser reads this input, in that case all the password information is leaked. And to mitigate this type of risks you have to make sure that the libraries that you're using that have the XML parsers, they are up to date and they're not using external entities for references. Broken Access Control. This is related to unauthorized access. We'll dive into this deeper as well, This is, again, an identity-based risk, so we'll talk more about that. Security Misconfiguration. This could be anything around security misconfiguration. So think of that as some of the HTTP headers that are not secured properly or it could be where you're storing API keys on GitHub. It could be where you're logging too much information or inappropriate information. And to mitigate this type of a risk, you pretty much have to use the detection tools and write libraries making sure that you don't have misconfiguration in place. If you look at the Equifax hack report, it lists out all of these different types of misconfigurations that were identified when they were doing the research on what went wrong there.

Cross-Site Scripting. This is another type of an injection attack, similar to the SQL injection. But here, instead, the attacker is injecting a malicious JavaScript code into the victim's browser. So an example here is an attacker ... I can inject this JavaScript and this is trying to steal the cookie from the victim's browser to steal session information. So this cookie could have session data. And once I have your session ID, I can hijack your session. And to mitigate this type of risks, you have to make sure you have escaping in place. You need to have HTML sanitization. And there are a lot of other things you can do here as well. Insecure Deserialization. This is one of the big reasons for the Equifax hack. This is where the application framework is reading inputs from ... it's basically deserializing inputs from untrusted sources. And what happens is the attacker can actually send a malicious code and your deserialization framework will read that and execute the malicious code and that will lead to remote code execution. So with Equifax hack, what happened was the Apache Stuts had this issue and although it was patched and found two months before the hack happened, Equifax didn't apply this patch on time and that led to this issue. The number nine in the list is Using Components with Known Vulnerabilities. And this is where we developers tend to use third party libraries day to day for our development. And while those are awesome libraries, never trust them because again, they could have risks like the one we talked about with number eight and that can cause issues with your code as well. So make sure that you're always pen testing the third party libraries that you're using even though they are known to be really good out there.

Number 10 in the list is Insufficient Logging and Monitoring and this is related to lack of monitoring, lack of logging within your applications. It could be lack of setting up appropriate alerts and also the response times. And this is really ... the way this impacts is it basically really worsens the impact of the breach.

So today we will be looking at kind of three and a half but mainly broken authentication, broken access control, and insufficient logging and monitoring. I'll be briefly touching sensitive data exposure from an identity standpoint. This is more around PII. There's a lot more information about sensitive data exposure that Okta can help, so I'll be focusing on the PII information. So let's look at broken authentication. Broken authentication sits number two in the Top 10 list. Do you guys know why? It's because the attackers are trying to attack the human weakness instead of the technology weaknesses. So here, let's look at the different types of attacks.  Credential Stuffing. This is like a brute force attack where the attacker takes advantage of us humans using the same password across multiple accounts. I mean, we have hundreds of accounts now. It's hard to have individual passwords for all of these accounts. I mean, if you're using some password management tool, that's awesome. But I can say 90 percent of the folks don't do that and they end up using the same password across different applications. So if I'm using a password in my social media account that doesn't really care to save all my information or they don't care about my information being leaked, then if I'm using that same password in my financial application, that's a problem if the social media account gets leaked. And then it doesn't matter how much your application is secured. Because the password is leaked in the other place, your application is breached as well.

Broad-based and Spear phishing campaigns. This is the type of phishing attack where they'll target a group of users or individual high profile users. And this is where they will send a legitimate-looking email and it'll have a link to a fake site. So I'll pick on LinkedIn as an example. I get a request saying, "Hey, So-and-So wants to add you as a connection. You want to approve or deny?" And I'll go click approve and that'll take me to a LinkedIn-looking site and it'll ask me for my credentials and the domain and everything will look very similar. It may not be exactly the same, but as a user I may not notice it. I will provide my credentials and the attacker behind the scenes will capture the credentials, route me to the LinkedIn web site and I won't even know I got phished. And this is the most common type of attack that's happening on a day-to-day basis.

Password spraying. This is another type of brute force attack where the attacker takes advantage of us using commonly known passwords on a day-to-day basis. It could be where somebody is using password123 and what happens is the way they go about doing this attack is they'll take the password and try across multiple different accounts instead of taking all the kinds of passwords that are commonly used, and trying for one user, because this helps them go undetected.

Man-in-the-middle attacks. One of the examples I have here is session hijacking. There are other ways to do the man-in-the-middle as well. But this is where, I showed you an example with XSS, where I can steal your cookies and be able to get that information. There was in fact another recent one that somebody else did as well, where they were able to not only steal the credentials, but they were also able to steal the MFA factors while the user was going through the login process. And this was, I think this guy released this evil-genius, basically last month or so. And I'll talk a little bit more about that. Session fixation. This is where, if your web application is using the same session ID for anonymous login and for once the user has logged in, then the attacker can fix that session ID in the user's browser, and you'll be leveraging the same one, so now he has the session ID. I don't know if people still do that, but that's one of the issues. And then there's others, like application session timeout's aren't set properly, so attacker has a long time to mess around with your session.

Let's look at some of the examples.

Deloitte was breached, was last September, where some of the emails of the clients, and also plans, were exposed by the hackers who got into, I think it was the Office 365 hack. Where they got into the admin account, which was not set up for multi-factor authentication. Uber was another one where it was indirectly attacked through multi-factor authentication. What happened here was the attackers got hold of the API keys, or credentials, on the ... Not API keys, sorry, it was actually credentials for the AWS bucket on the GitHub code, and this could have totally been avoided if there was multi-factor authentication set up for the GitHub accounts.

So how do you go about preventing broken authentication? Number one, you have to implement multi-factor authentication to prevent these brute force types of attacks. And when you're thinking about multi-factor authentication, you have to have a lot of different criteria in mind to set this up. So, there's some requirements. Like, for multi-factor authentication you need to have a something you know, it could be a password or, it could be something you have. There needs to be something you have, and this could be your phone, where you'll receive and SMS code or an OTP or a push notification, or something like a YubiKey or a Fido U2F. And, to be honest, we ask customers to move away from SMS and OTP. And like I talked about earlier, right, with man-in-the-middle attacks, not only am I going to be giving my credentials away, I can also give my OTP away. Or, even though regular phishing, stopping me from entering my SMS if the user has my phone number. So, minimum, at least use a push notification or U2F, if possible, for at least admin type of accounts.

Then you have a something you are. And this is your biometrics type of information. So you have, it's your thumbprint, or your face ID on your phone. So even if your credentials get stolen, the attackers can't really get your finger or your phone, for face ID, or your face for that matter. And if they have that, that's another problem that you guys have.

Speaker 1: Biometrics should never leave the device.

Payal Pan: What's that?

Speaker 1: Biometrics should never leave the device.

Payal Pan: Yes. Or leave you.

And then the other thing you need to consider is beyond this you need to also consider contextual information about the user. So the user's contexts. Where are they coming from? Their geolocation. What time of the day are they logging in? Their IP address. All of this needs to be considered when you're evaluating if you want to allow the user to come into your application or not. You also need to align password length, complexity, all the policies according to the NIST 800-63b guidelines. And basically, there's a whole laundry list here of things that you need to do for password management. But they talk about, "Hey, don't use password hints. Don't use password questions. Don't expire passwords just for the heck of it." Right? You're putting the burden on the user. Instead, put the burden on your application, and you do the verification and authenticate the user without having to go through all of this stuff. Like here, they also say, "migrate away from SMS for multi-factor authentication, use something like a Fido or a dedicated app." You need to check for weak and commonly used passwords, and you also need to check for already breached password checks. So there are services like, Have I Been Pwned Yet by Troy Hunt that was released. And that, you can actually go check for your user ID and it'll tell you that your user ID or password was breached or not. And we're actually, we just announced that we're using this service as well. So you can actually leverage that as APIs and behind the scenes with Okta too. You want to be able to figure out what's the best password hashing scheme you want to use. So the password base key derivation functions. We recommend anything bcrypt and beyond. The most commonly used ones are bcrypt and scrypt, although Argon2 is the strongest. But since bcrypt and scrypt have been around for the longest time, that's what the most recommended is.

Then you want to apply credential-specific random and unique salt. So the way password hashing works is you have the password from the user in plaintext, and then you basically apply a password hashing algorithm. Go through some iterations and work factors for delays, and then you have a hashed password. Now, say there are two users who end up using the same password. The hash is going to be exactly the same for both of them. So, what you want to do is you want to apply credential-specific salt to basically de-duplicate that issue. And it also helps from rainbow table types of attacks, because that doesn't take salt into consideration. Then you want to go through the whole session and cookie management best practice things as well. For session management you want to make sure you're using TLS to prevent sniffing and session hijacking. You want to use long, random, unique IDs for your session to avoid brute force type of attack, where I can't just try all different types of IDs. You want to regenerate your session ID once the user has logged in, to avoid session fixation that I talked about earlier. And you want to do absolute log out when the user is logging in. And this is where you want to invalidate the session ID, and if you're using token-based authentication with job tokens, then you want to revoke those as well.

For cookie management, and this is not a comprehensive list, there's a lot of stuff that's involved here. For cookie management, you want to make sure you're not hat storing any sensitive information in the cookie. And even so, just encrypt the cookie every time. And you can use these headers for your cookies, like HTTP only. What that will do is that will make sure that JavaScript cannot use the cookie for any XSS type of attacks. And you can also set up flags like 'secure' that'll make sure that the cookie is not passed unless you're using HTTPS.

Some other things to consider. You want to be able to add rate limiting to your authentication, to prevent modern brute force attacks. You want to harden self-service password resets with step-up authentication. And you want to implement single sign on to prevent password proliferation. So let's look at this example. This is a Spotify login page. This is the very standard login page that every website has, right? Or mobile app has. So this has my login functionality, where I can login with my username and password. Remember me functionality. If I don't have an account yet I can sign up. Or I can log in with a social account, just for an easy entry point so I don't have to go through registration. And there's also the forgot username and password for my self-service password reset. So it looks fairly simple, right? As a developer I'd be like, "Oh yeah, I can build this in no time." But it's not that easy. It's extremely complex to build this. So developers typically underestimate the work involved here. Let's see what you need to build up for your application. And this is again, not a comprehensive list, because I couldn't fit everything in one page.

But here you need to do user registration, and you need to do input validations. You need to have the whole password management that I just went through. You need to go build all of that yourself. And you need security expertise for something like that. You can't just go pick libraries from somewhere and then start just plugging in. You need to have multi-factor authentication. You need to be able to give options to your user for different types of factors that they would be able to use, instead of just SMS, like most of the applications do today. And, to make this adaptive, that's another level of complexity you need to add for your application.

You need to be able to have self-service password reset, session management, social options, single sign on, I can just go on with the list. Re-authentication, this is where you would want users to re-authenticate if they are trying to change something that's crucial in the application. It could be your email addresses, your address in general, or your credit card information. An example, Amazon, any time you go change an address they'll ask you to re-enter the credit card. And this is how they basically tie the two together always. To make sure that if an attacker got into your account, they can't just go change the address and get everything shipped to themselves, cause now they also have to enter your credit card information. You need to have access controls in place, that's the authorization piece. If you mobile-enable your app, that's another whole level of security aspects you need to keep in mind as well. And then, API security, scalability, reliability. All of this needs to be built on there. I can just go on and on with this whole list. So really, building authentication and authorization by yourself is extremely complex.

I was in a training six months ago, and this was again around OWASP Top 10 by this guy names Jim Manico. He's a part of the OWASP community. And super awesome guy, by the way, if you get a chance, attend his training. But we spent more than three hours for this broken authentication conversation just talking about what are they types of risk, how do you go about mitigating it? And because that whole environment is vendor neutral, I had to really keep this in my stomach, like, "Hey guys, why are you doing all of this? Just use a service like Okta to simplify the whole thing rather than go building yourself."

So basically, that's the message that I have for you here, because I'm not at the OWASP Conference here. I'm at Oktane. I can very comfortably say that. But, basically, you don't need to build any of that stuff, right? Let Okta do this for you. So this is where Okta can help. You never have to build Auth again. All of that laundry list that I went through, Okta provides that out of the box for you, so you don't have to do it. You can add authentication, authorization. You can manage your users within Okta's Universal Directory. We provide you with sign in widgets, SDKs, APIs. And we take care of all the password management and password policies behind the scenes. In fact, we just announces Passwordless. So you don't have to deal with a lot of different types of attacks that comes with credentials in place. So our next topic is broken access control, and this is about the authorization of your application. So, when you're building a web application, now you've taken care of your authentication, now you want to make sure that, you want to check, what is the type of user who's trying to access your web application. And what resources you want to present to them. So it could be you have a user, you have an admin. And what developers tend to do is they tend to hard code this role-based access control within their code. So they'll say, "Okay, if user=admin, then so and so." Or, "If user=manager, so and so." I mean, to start with, it's simple to start with, but then as your web application gets complex, there are more users involved. Does this methodology doesn't help. And how do you go about even changing something like that once it's grown into this whole if-then-else rules and policies inside your code? How do you go about auditing something like that, right? So that's the biggest challenge with broken access control. So broken access control sits number five in the list.

And let's see what different types of attacks that can happen. So this is where the attacker can find a feature that is open in your application, and once they find a feature that's open, it could be any, right? See, I find some feature that's open where it lets me elevate my privileges from a user to an administrator. That's another gray common type of attack. Forced browsing: this is when missing appropriate authorization of restricted URLs. This is very common as well, where you're not securing every page that you have within your web application. And even though I'm not supposed to go, I can just change the URL and I can just get to the pages I'm not supposed to cause it's not allowed. Metadata manipulation, and this is where I can tamper JSON tokens. JSON web tokens or a cookie, and change my scopes there. CORS misconfiguration is another one where it allows unauthorized access. API access, missing access controls. And this is the issue that was there with Panera Bread. The hack that happened recently. You guys saw the foundation API for Panera Bread was wide open. There were no access controls, so anybody could get information about every user, including their first name, last name, the last four digits of credit card, addresses, their food preferences, all that was leaked out. So that was tied to the API access controls.

And then you also have issues around JOT tokens. Once the user logs out, the key may  still be valid, and you'll be able to get in. And then insider threats. That's another big one. You have privileged users within your organization, and they could abuse the system as well. I mean, I was reading an article where there was a guy, a healthcare person, and he had access to information about the patients prescriptions. And he abused the system to get the substance abuse, basically. So, that was the issue there. Ex-employee privileged access: That's another where you may have an employee that's left the company, but he still has lingering access just because you have access controls all over the place.

So how do you go about mitigating these types of risks, right? How do you go about preventing broken access control? The number one rule: Apply principle of least privilege. That means that without the exception of public resources, deny by default. Give them just enough access to get the job done, and just for the amount of time needed. Other than that, just don't give them access. The other thing you need to consider is, instead of role-based access controls, consider attributes or claim-based access controls. This is where you're enforcing access controls by user attributes and the attributes of the objects that they're trying to access. So it's by feature rather than by roles. And this will basically also allow you to add new users into applications very easily, where you just have to make sure that these users have attributes in place rather than going and checking for every different type of roles that you can have within your code.

You want to be able to secure your API access. You don't want it to be a get-post-put-delete. All the metas need to be secure and access controls need to be put in place. And what resources they can access, for APIs and microservices. When your API is receiving JOT tokens, you need to do validations. You need to check for the right scopes. Who the [issuer 00:30:12] is. Are you the intended audience? You need to check for all of those when you're securing your APIs as well. And a few other things you need to consider is, you need to centralize access control across your applications. And that's extremely important. That's number one. You don't want to have all of your access controls all over the place because that could be somewhere where you have privileged ex-employee off boarding.

Say if an ex-employee leaves, and you do deactivate the employee, and their access is taken away. But if you do have access controls all over the place, you may have missed some place where he still has access, and that can cause problems. You want to be able to centralize access and controls to make your security guy's life very easy. The other thing you want to do is you want to prevent forced browsing, so you want to secure every page of your web application as well.

So how does Okta prevent broken access control? So this is basically highlighting how, with Okta, you can go about doing that in your webs application. So you can set up authentication for your web application with Okta, with OpenID Connect, and what that would do is that would give you a token back. It will be an ID token and an access token. And that access token will have fine grained access controls on what exact permissions the user has once he or she has authenticated. And that's based on the user attributes or what type of backend resources that they're trying to access.

Once you have that token in place, you're going to take that token. That will be leverage for your backend resources for authorization purposes. So that's where you can get that fine grained access control. You can also apply granular based access controls with group rules into Okta, where you can do it by specific user attributes and gain that as well. And then I just added this other thing about sensitive data exposure. I tacked it along with access controls, but basically I want highlight how Okta prevents sensitive data exposure, mainly your customer's PII information when you're using Okta's universal directory. So we encrypt ever sensitive customer data within your orgs, be it at rest or in transit. And we use highly secure key management system to protect org sensitive data. And we take pride in achieving compliance and certifications in working with customers like you to achieve SOC 2, HIPAA, GDPR, PCIDSS. All of those we have in place.

And the last one I want to touch on is insufficient logging and monitoring. And this is number ten in the list. And this is, again, like I talked about. It's related to insufficient logging or monitoring in place. Let's just look at the attacks that are possible. So, the different types of attacks. Here the attackers rely on lack of monitoring and timely response to take advantage of the system, right? Look at the dwell time here. And I'll just kind of load this all up. But, basically, if you look at the average dwell time. And dwell time is basically where the attacker breached your system. And the time when it was actually identified. And if you look at the average global dwell time, it's 99 days, and that's a long time for the attacker to basically mess around with your system.

And the different types of attacks that are possible here are where you're not logging high-value transactions, like your authentication. Or failed logins or suspicious activities are not logged in your application. Logs of applications and APIs are not monitored for suspicious activities. And you also have lack of appropriate alerting in place, where administrators to even look at those, if there even is suspicious activity. The application typically is unable to detect or escalate or even respond in time, in real time. That's where you want people to reduce your dwell time. You want to do that in real time to mitigate these types of attacks.

So, if you look at the Equifax hack report again, you can see that Equifax allowed hackers to continuously access sensitive data for over 75 days. That's a long time. And that's because the company didn't have any effective controls for logging in, logging techniques, and alerting. Twitter was another one where they identified a recent bug. This is not where there was insufficient logging, it was more inappropriate logging, where they were logging passwords in the logs before they were hashed. But they were nice enough to find that and let us know early on to change our passwords right away.

So how do you go about preventing insufficient login monitoring? You want to ensure all your [auth-related 00:35:21] validation can be logged with sufficient user identity. You want to make sure you have all the information about the user and where the user's coming from. Location, again, going back to the different context, right? Location, IP addresses, what time of the day, or device information. All of that needs to be in place as well. You want to ensure that the logs that are generated are consumable by other user systems, like you SimTools or your security incident response tools, where you can set up proper alerting and monitoring as well.

You need to log repeated failures, alert admins when necessary. You want to establish effective monitoring and alerting. Oops, and I went back. And you want to be able to establish proper incident response and recovery plan. And all this needs to happen quickly rather than taking forever. So how does Okta help? So Okta gives you the real time user logs for every user activity that goes on within the Okta environment, be it for suspicious login, if they're going through MFA. All the details, along with the user context as logged, and that can be fed into your SimTool in real time. And then you can take your application logs, you can take the Okta logs, you can take the network logs. Combine all of them and set up proper alerts and monitoring in place and be able to take response in near real time.

So really, I just want to talk about in closing, I want to say just don't build your own [op 00:37:04]. It's just too easy to get things wrong. And this is exactly what Olas will tell you as well, where, you know, you have to make your web applications perfect, while the attacker has to just find one tiny flaw to be able to breach your system. And that's a huge risk. Companies like Okta have already gone and done this. We've already contemplated all these risks for you. And we've been doing this for nine years. This is our core business. So don't reinvent the wheel. Basically, yeah, again, don't build your own op. You know, when I go to conferences, people look at me like, "Oh, you're from Okta. We use you for SSO." I mean, yeah SSO, they look at it more as a convenience factor. What you don't realize is while we provide that seamless experience, we're also securing your perimeter behind the scenes without impacting the user experience. We're providing the most secure and reliable way to secure your customers' data.

And then this is just a last slide talking about all the other risks. So I highly recommend you check out the os.org for all the other different types of risks. This is not something where Okta can directly help you, but they have a lot of different mitigation solutions out there. In fact, they also released the OWASP Top Ten Proactive controls. And this is where you check how do you go about controlling these types of attacks. So I would highly recommend all the architects, developers, security folks in this room to check this out.

That's all I have for today.