Part 5 - OWASP 1 through 5

Video Activity

This lesson covers vulnerability databases and resources. • Open Web Application Security Project Top 10 (OWASP) • Common Vulnerabilities and Exposures (CVE) • Common Weakness Enumeration (CWE) • National Vulnerability Database (NVD) • Computer Emergency Response Team Vulnerability Database (US CERT) Specifically, this lesson focuses on the OWASP T...

Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *

Already have an account? Sign In »

5 hours 54 minutes
Video Description

This lesson covers vulnerability databases and resources. • Open Web Application Security Project Top 10 (OWASP) • Common Vulnerabilities and Exposures (CVE) • Common Weakness Enumeration (CWE) • National Vulnerability Database (NVD) • Computer Emergency Response Team Vulnerability Database (US CERT) Specifically, this lesson focuses on the OWASP Top 10 and offers an overview of the following: • Injection (A1) • Broken Authentication and Session Management (A2) • Cross Site Scripting (A3) • Insecure Direct Object Reference (A4) • Security Misconfiguration (A5)

Video Transcription
okay, so that we've agreed that software today is as a general rule unsecure. It's not written to be secure, it's written to function, and then often security is handled after the fact, if it's handled it all. So let's look at some of the resource is that we have so that we can address this problem.
You know, sometimes we don't have the power to go back and rewrite the software securely.
So what can we do? Well, we can monitor. We can make ourselves aware off the vulnerabilities and do the best that we can to mitigate those. Also, in moving forward with the software that we do develop, we can be conscious of thes vulnerabilities of these threats so that we can write better code.
So when we talk about being aware of what's out there, you know, where are the dangers?
A WASP for Web application Security really is one of the best organizational groups that you can work with. It's the open Web Applications security project and on their Web page on their Web site. They have just a wealth of information about vulnerabilities directed at Web applications.
They also publish a top 10
vulnerabilities list, and it's really worth taking a look at which will do in a few minutes because it walks through some of the more common mistakes that are made by developers in some of the more common exploits that we see from an attack perspective. So a wasp it's really good to look at.
Ah, there's also the C V E common vulnerabilities and exploit database.
There's a seat W E, which is common weakness. Enumeration, which again it's just a list. Enumeration just means listing ah, listing of some of the common weaknesses that are out there. There's also ah, National Vulnerability database. There's us cert
you know, if you're looking for elements more involved with government computers, but these are just a handful of resource. Is there many that are out there?
But these were very, very good. Now, as I mentioned, a WASP is really one of the best places to go. If you're gonna be working with Web applications to really make sure that we understand the vulnerabilities and how we can limit the damage through these vulnerabilities, a lost this international
and it's a non profit organization again. Open Web Applications Security Project
and one of the best things that they do Force is published that top 10 list
Excuse me. The top 10 list that gives us a man overview off the most commonly orchestrated security attacks on web applications.
So here is our A WASP Top 10. Now tell you for a test taking perspective, they will not ask you, you know, based on oh, Wasps 2013 top 10. And by the way, that is the most current that's out. Now what is number five? You know, you don't have to know these in order,
but I would very much be able to explain at a relatively high level
what each of these types of attacks are. So an injection attack, a cross site scripting attack, Miss configuration and so on. So let's go ahead and look at each of thes. And let's talk about mitigating strategies as much as we can.
So the very most common, um, attack on whether applications is code injection, whether its sequel injection L dap injection, whatever the protocol that's being exploited is code injection is really code injection. You know, it's really the same thing.
The bottom line is
often toe add additional functionality to a user's Web experience. We allow them to input information. We might query the user's for their input, their information there, their preferences. You know, we might ask them we might you ask a user for their name
so that the second Web page can read. Welcome, Kelly.
Um, so any of these elements, anything that's input goes to the back end database. So if we've all heard the phrase garbage in garbage out, So if instead, when it says Please enter your name. If I enter a command that revolves around the idea of dropping the table
in a sequel database, well, that's gonna have a ferry, obviously very negative effect on the backend.
So we refer to that as code injection, where I'm injecting code into user forms and the user forms are asking for, you know, very basic, straightforward, legitimate information. But if there's no form of input validation, I can enter code
into those entry points and have that code run in Lebak in database. So that's a big deal.
So some ways that we can mitigate and really the easy answer on the test is you mitigate code injection through input validation. But just like anything else. It really has to be a balanced in a layered approach to limit the damage with code injection. One of the things that will use his data typing.
So we very strictly will data type are entries, airfields.
Ah, within our form. So, for instance, if I ask you for the date ah, you shouldn't be entering the alphabet into a date field. We should date a type that is date time.
another thing that we can do is we can limit that length of input. So for your last name, I'm not gonna give you 500 characters. I'll give you 10 characters. And if your last name is longer than 10 characters, it'll be truncated,
for state name. I'm not gonna give you 100 characters to type out the name of your state. I'm gonna give you two characters.
And if I'm really smart rather than giving you two characters, I'm just gonna have you pulled the name of your state from a drop down menu because that gives you less chance to input hostile data or any sort of code. So
with all of that happening, that's part of input validation. But then we also before taking what's in these forms and passing them along to the backend database. There should be additional inspection, and that usually comes from our CG I script are common gateway interface.
And if you remember throughout class, we've talked about
untrusted should never access trusted except through an interface. And it's the job of that interface to make sure that Onley proper information's being passed along to the back in database. So one of the biggest threats today against databases is code injection. It takes lots of extra work
to do the input validation,
but it's certainly worth it
now, the next one broken authentication in session management. This isn't a specific type of attack in that there are lots of ways this can happen. Really. What this is saying is poor authentication and poor session management,
for instance, when does a session expire? And if a session, uh, doesn't expire after two minutes off of no use or in activity, would it be possible for me? Is an attacker
to pick up on that session that's already been created
and kind of step in? Ah, sort of like a man in the middle attack. I don't know. You know, it makes me think about land lines. You know, if somebody's on the phone and goes toe, hang up. If I can pick up that other phone line before they hang up, I'm now on the call, and I can start and impersonate the original user.
So that's kind of an exploit that had happened with session management. If that doesn't work properly,
we gotta make sure that tokens aren't stored in plain text session I d. S. Um, we want to make sure that passwords heir protected. We're not sending cast words across the network in plain text. We have to make sure that when we are authenticating
that we all communicate well and that we have good information implementation
so that these identities and this authentication information is not compromised.
All right, Number three cross site scripting, and you'll notice a lot of thes attacks go together because cross site scripting really takes advantage of websites that don't do input validation.
So once again, we go to that idea off. The website's gonna ask you So you go to visit, Um
ah, you know the
banking, your banking page or doesn't even have to be a secure website. Let's say that you go to visit. Uh, you've got an account with your local news organization on their website and you log in and they show you the news that you've selected. That's of interest to you.
So when you go to this website, it asks you to enter your name.
if I can inner code
into that space where it says enter your name, if I can enter some sort of malicious code, what's gonna happen is the second page that's going to see if I can explain this better. Um,
so what's input on the first page is going to be played back on the second page. So basically the first website, the first page that I visit with the website, says, Please enter your name and I enter my name Kelly Hander hand. Then that takes me to a second Web page that says, Welcome Kelly Hander Hand.
So on the first site, where it says enter your name.
If instead of the name, I could enter a script, a malicious Java script that's called in that runs some sort of malicious activity, um, then you could be sent to that Web page on knowing, and that second side, or that second page
could wrap around in the script, could run in your browser.
So, for instance, I send you a phishing email that takes you to a site that's been compromised and that malicious code has already been entered. And because of the way cross site scripting works and because the fact that that website doesn't do input validation that malicious script, it's actually called and run within your browser.
I hope that makes sense because cross site scripting is a really, really common type of attack.
So basically, what it does is for applications that are for Web APS that don't do proper input. Validation can redirect you to a malicious site that runs a script or some other malicious activity to wrap around and run in your browser. And a lot of times, your phishing emails
take advantage of cross site scripting. Or
that's their purpose. Click on this link in order to change your password or click on this link in order to visit such and such sight. And when you click on that link, that takes you to the compromise page where the script runs. Ah, and you know, the way our Web sites run is our Web browsers process
the source code of the website. So if that source code calls a malicious script that's automatically running their browser, so cross site scripting is a big deal. It's something that
is very difficult from a client standpoint to resolve because it really takes advantage of websites that air poorly written. So if I goto a poorly written and designed website, I don't have a lot of control over that cross site scripting. So we have to be very careful about which websites we do go to.
And we have to have that degree of trust that the websites are well written.
If a website does not perform input validation than cross site scripting can very readily happening could be very, very effective.
All right, our next, um number four for common attacks insecure direct object references. So to give you an example, let's say that I pull a query of sales figures
and let's say that I was authorized as an individual toe access sales figures from January to March.
I'm not authorized to access make April forward, but I am authorized to access January through March. So I go to view the sales figures for January, and I type in my credentials. It allows me to access January now up in the u. R L. I can see where it says,
Um, response equals Jan.
So that tells me it's showing me a response from January.
Well, if I changed Jan
Toe April a p R orga September some other element. What I'm doing is I'm referencing an object that maybe I don't have access for. But if the parameters air not verified by the website, then I may still be able to access an object
for which I really shouldn't have access
just by manipulating the parameters in the Earl. And we refer to that as insecure direct object reference. Now, if you're thinking what I am, some of these things would be really easy.
Um, toe limit. And that's true. But once again, we're not asking our developers to write secure code. We're not asking our developers to think off the vulnerabilities and the expected threats. We're asking them to write ah, Web page, a website that will sell our product, and that's where
our focus has been.
So when we talk about manipulating these parameters, we may be able to manipulate the parameters in the URL to gain access to other sites or perhaps escalator privileges. Access resource is for which we shouldn't be allowed. And we refer to that as direct object references
because we're directly manipulating the U. R L toe access thes object references
rather than going through the more legitimate path of clicking on links or navigating through the website
and then the fifth most common vulnerability associate with Web applications security, Miss Configurations. And that's a very broad topic. There are a 1,000,000 ways that we can miss configure our database application.
You know, we can leave default settings. You know Default settings for websites
usually allow anonymous access because usually for a Web server, when we set up a website, we want people to be able to access that website and buy our product or learn about our company without having to provide a whole lot of credentials or jump through a lot of hoops. Well, that's a default configuration setting.
We need to think about changing those default configuration settings.
We need to think about getting away from default settings of any type you know we need to think about requiring for more secure environments, user name and password, or integrating authentication with certificates. We need to think about,
um, making sure that default settings were removed, that we don't have that administrator account
with the password of password. Just those security basic miss configurations that we make without thinking about defensive coating. So there's a very general topic in a very general term, but just the basics of not following good security principles. That's issue number five.
Up Next