In this video, we'll look at the next three OWASP Risks number 2, 3 and 4. So number 2 is broken authentication, number 3, sensitive data exposure and number 4 is lack of resources and rate limiting. Now that's the one add ball in the collection, it's from the OWASP API risk list and not from the web app risk list. Number 4 from the risk list got combined with risk number 8, so we'll talk about it later. We're not skipping it entirely. Okay, so risk number 2, broken authentication. Authentication has a bunch of weak points. There's the process itself of trying to identify or associate a bunch of data coming across the network with human authors. And then there's the session integrity problem, which is you have a user, you've been talking to them and you get yet another message. How do you know it applies to the user you previously authenticated? So major authentication attacks and failures can be if somebody collects a bunch of credentials and then start stuffing them as an attack. Brute force, trial-and-error is a big deal. And then of course bypass techniques like SQL injection Now session integrity failures tend to be things like an unprotected session variable. This was huge back and say about 10 years ago, 10, 12 years ago, you could sit down in a public cafe. And if you had the right software, you could listen on the network and pick up people's Facebook cookies and insert it into your Facebook app, and you would be able to see all their friends and all their communications. Now that everybody uses SSL on those sorts of connections, things are a lot safer than they used to be. Other problems is you might fail to invalidate a session. And the third one, and I've seen this more than once in badly implemented stores online is you visit the store and you find yourself sitting in somebody else's session. So the previous person didn't actually get logged out completely. And their session is still there and so is their credit card and their address and their email and everything else. I haven't seen those as quite as often recently, but I think saw one a year or so ago. Credential stuffing attacks, okay, there was one in 2019 against State Farm Insurance. Essentially somebody took a bunch of previously collected credentials from an unrelated attack. Allegedly they didn't come from State Farm Insurance. But they deployed this credential stuffing attack against State Farm. Now, State Farm reported this as they're supposed to and apparently the credential attacks were not particularly successful in that no personally identifiable information was disclosed. Okay, here's another one Presbyterian Health Services also 2019. Employees fell for a phishing email, and a quarter of a million user records were compromised. Of course once you have the login for the correct employee, you have access. Okay, here's number 3, sensitive data exposure. I mean just hearing the word well yeah, that's a danger. So what can we do about it? Before, we talked about the different categories of data we protect and various issues that arise from those. And those categories still apply. Now exposures often happen just because people don't restrict data access. And this is especially common in the cloud environment. Every so often, someone will build an application that will scan a particular cloud vendor and see what kind of data buckets and whatever are open and accessible to anyone. And one of the other ways exposures can occur is there's weak or nonexistent crypto either when they're transferring data between different parts of the system or when the data stored. So here are some examples of failures to restrict access, Wyze in 2019, also Novaestrat. Now it says there 20 million Ecuadorians that's counting them in a rather broad sense because the actual country's population is smaller than that. But apparently one of the people whose information was leaked was Julian Assange who was essentially taking refuge in the Ecuadorian embassy and thus had his information in these databases. 2020, Virgin Media 900,000 users records were leaked. OneClass, 1 million users, BlueKai, 2 billion visit records. The last one is a company that collects advertising click information. There's a lot of that out there. Okay, here's the fourth, lack of resources and rate limiting. As I said this comes from the OWASP API list, not the web applications list but the whole availability risk is something worth talking about so we'll talk about it here. Okay, so what kinds of things happen? An attacker sends to many requests, sends them too fast, or another popular thing is when they send a partial request. So you'll have resources like, well, the classic example was the half open connection attack where somebody starts to open a TCP connection and then that's it. They don't finish opening the connection and so the half of a connection sits there waiting forever for the person to finish. Well, they have their countermeasures but you have to put them in. Smurf attacks are kind of creepy because the way they work is kind of the opposite and that that's an attack where you send a small message and, get a whole bunch of messages in response. And then try to use that as a way to amplify an attack against somebody else. Okay, resources to exhaust, execution time, storage of course, connections, outbound queries. And essentially you can think of these sorts of exhaustion things as a failure of graceful degradation. Yes you're going to get hammered by traffic or at least if you are successful, you will be hammered by traffic from potential or actual customers. So you have to have mechanisms in there to gracefully degrade as your resources start to exhaust. Now here are some examples, there is a node.js attack in 2020, nobody has actually seen a real exploit of it but it was reported. And so what happens is the attacker sends HTTP headers without bodies. And this uses up webpage resources within a node JS implementation so that eventually the server rejects new connections. Kind of a new play on the old open a connection but don't really finish it. [MUSIC]
