Now we cover a wasp risks five, six and seven briefly by being broken access control, which includes API risks number one and five from the API top ten list, and security misconfiguration. Which is a very broad umbrella and cross-site scripting broken Access Control will look at first so in web apps broken access control often involves privilege escalation. So you start out as a non-user and you make your way up to being a user regular user and then from there. An administrator. Another strategy is to somehow get into the metadata and modify the user ID that's stored there. Another way of doing broken access control or breaking it is to browse restricted pages by crafting your own URLs to send to a web application. People like to assume that since our, server has sent the client. All this nice JavaScript to that is controlling that. Clients environment that everything we receive will be mediated by that JavaScript that's nonsense. You really can't assume that whatever you're getting across the network actually comes from your client. Unless you have a way of that client. That's another issue so you have to consider anything you receive in terms of URLs or other user created input what a bad guy might have done with it. So browsing restricted pages. Applying one of the functions in HTTP other than gatt, which is what of us expect. So in the API world, there are a couple the two problems that they like to point out is first object level authorization. And the problem there is you have an object then your passing it through a variety of different environments. You don't want that object pass to an operation that doesn't know how to authorize it, to use properly, so. You have to be sure that all object uses, are within the context of your application and the right stuff gets enforced. Similarly function level application authorization. Once you've written the functions, you need to determine or at least ensure that whenever they're used, they're used within the right authorization context. Make sure that the user is authorized or as an administrator. Those sorts of checks. Okay, so URL bypass. This is a classic example. We saw earlier in the specialization one of the earlier courses and here's what shouldn't happen essentially instead. Pulling out a file that's within the hierarchy of the web service. You've trick the system and to picking up a password file. The generic example of bypassing. Okay, let's look at security misconfiguration. Now a lot of security misconfigurations are in fact covered under other OWASP risks. For example three and five are thing, things having to do with failure to harden the system. We already talked about three earlier and we just talked about five. And then there's failure update number five, number nine. That's these are clearly security misconfigurations. Okay, so failure to harden the system. For example failure to enable SSL TLS my son does. Server development and he had a situation where his development team and put SSL in place for part of their system. And the people who did the client deployment part failed to turn it on. So they had essentially sensitive information personal identifiable information about the end users of their system that was being distributed across the internet without protection. Also, another risk is leaving development tools enabled. Because development tools are designed for development. The people who develop them don't tend to worry as much about malicious users because they assume if you are the developer you've got access to everything. So they're not going to worry about across site scripting vulnerability or SQL injection. So you want to be able, you want to be sure that anything that doesn't absolutely belong in your application has been removed before you deploy it. Also, there's a whole thing of default features and credentials, and error messages that dump the stack. There have been recorded instances where these are serious trouble areas. For example, well, let's talk about default credentials of in 2019 so ghost did a honeypot. Experiment where they ran servers on Amazon Web service for 30 days, collected login attempts and found that most of the attempted logins for this system. That had no authorized users were attempts on route or attempts on admin. So if you have a way of not using those user IDs, that's a good thing. Okay, in 2019 there was an unexploited vulnerability in a system where basically violated the don't disclose advice, there was an error where you would get a stack dump sent to the client. And people looked at those stack dumps and normally the real problem is that for most cases the problem is that it tells a lot about the software architecture of your system. And it's better not to share that kind of information if you don't have to. The other problem is there were actually credentials in those dumps. So for example, the database login parameters for getting for that particular service. Were in the dump. Cross site scripting. We'll talk about this a lot later. But for the moment, let's just talk about the classic elements. There's reflected. Which is actually the more complicated one because essentially you're taking user text that the server really doesn't bother to examine or, review or, sanitize or, anything else. They just take that bare user text. And use it in their website. So for example in reflected make it put into a search function and then that's reflected back to the end user and the end user then their browser will execute whatever script is in there. Similarly with stored cross sites encrypting the attacker. Puts some unreviewed source code with or unreviewed HTML including a script into say a comment or blog entry or something else. And then that output is later read by a user of the classic diagram. The bad guy, puts his script in there, saves it. And then whenever some victim comes along and runs that script, they get hacked. Now in 2020, there was an attack late April early May that hit about 900,000 sites, didn't penetrate that many, but that was the number of people reported being attacked this way. It was an attack that used several exploits that involve cross-site scripting in themes or plug-ins for WordPress. So if you had an obsolete plug-In or you had a plug-in that hadn't been patched recently or your theme hadn't been patched recently. There was a good chance that you had one of these exploits in there. And so as long as you patched you're probably resisting it. So the attack attempts to put a back door in the WordPress system. So not a good thing to succeed. Okay tech support scam. Now this one was kind of interesting starts with social media link gets, you know, distributed across social media. Click here for blah blah blah and it directed to a site in South America that's typically considered benign. I think it was like a local search site or local information site I forgot. But the site included a redirection flaw, so that that link included a script, which would then tell the browser to go to another site, which was actually subverted. And froze the browser and put up a big screen saying. No, your browser is frozen, and your computer has been hacked. Call tech support, here's the number to call Hopefully, we all have enough experience with the Internet to recognize this as a scam [MUSIC]
