Part 6 - OWASP 6 through 10

Video Activity

This lesson focuses on the OWASP numbers 6-10 and offers an overview of the following: • Sensitive data exposure (A6) • Missing function level access control (A7) • Cross-site request forgery (CSRF) (A8) • Using known vulnerable components (A9) • Unvalidated redirects and forwards (A10) The unit also covers mitigation strategies as well as develope...

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 focuses on the OWASP numbers 6-10 and offers an overview of the following: • Sensitive data exposure (A6) • Missing function level access control (A7) • Cross-site request forgery (CSRF) (A8) • Using known vulnerable components (A9) • Unvalidated redirects and forwards (A10) The unit also covers mitigation strategies as well as developer strategies to keep information safe and lessen the probability of an attack.

Video Transcription
Okay, Coming in at number six on the awas cop. 10 sensitive data exposure. And again, this is a very broad term. There are a 1,000,000 ways that sensitive data can be exposed. You know, um, maybe our Web server is using, um,
Http instead of eight Shea ps to transmit
data. So we're not properly protecting that data that's in transit. Maybe the data isn't properly protected when it's at rest on. Our server maybe were subjected to Elektronik social engineering, like fishing requests.
Ah, whatever that is. But data exposure since that that exposure
is a huge vulnerability. So whether it's credit card numbers, health care, information of individuals, authentication credentials and we see these attacks happen week after week, year after year, linked in lost five million, I believe. Don't quote me on that. But somewhere in the neighborhood of five million passwords,
uh, eBay lost millions of passwords.
Target, we said, was compromised for credit card accounts, as was Home Depot. And so we see the sensitive that exposure happening again and again and again. Is it being ex fil traded off the network? Is it just being compromised? Is it an encryption problem where that is captured in transit.
But whatever the cause is sensitive data exposure. So what do we do?
We protect her dad. At rest, we protect our data in transit. We implement data loss prevention systems that will monitor whether or not information's being ex feel traded from our network will train our people against phishing attacks and other types of social engineering.
All right, Number seven missing function level access control. Now this is very, very comparable toe earlier when we talk about insecure, direct object access and what it has to do is modifying the parameters in the URL so that, um,
I am able to access something that I shouldn't be like. The normal user interface
may restrict me from going to sales figures April, but if I can modify the parameters in the IRL, it may allow me to go. That's indirect object access that's insecure,
but also it very well may be tied into function level access control because usually when we talk about restricting access to certain sites and certain activities, it's based on perhaps my role or my authorization to access this information.
So what could happen is I might be able to access something that only an administrator can access, and therefore I might have administrative privileges over that location. So where, as when we talk about insecure, direct object access,
eyes being a threat, that's more about getting access to confidential information I shouldn't have. But function level access control would essentially be more about actions and being more about being authorized to perform some sort of functionality that I shouldn't have. They
both are based on the same idea of modifying parameters in the U. R L.
But this is more about what type of function I can perform.
All right, cross site request, forgery, see surf attacks and these air becoming more and more popular. So ultimately, what this does is when I
set up ah connection to my banking server, and I established a session. Well, that session has an I. D. And I essentially have a token that authenticates this session.
If in attacker can, um can compromise that information, then they can send requests to the banking server on my behalf, and that's called a forged request. So essentially, the way that happens is that happens through things that we do to make our lives easier,
like saving user names and passwords in the browser
that shouldn't be saved in the browser, because basically what that means is it's gonna be saved. Is it cookie, perhaps, or in some other unsecure manner?
Don't use the Remember me options and websites Now again, Maybe not all websites. It depends on the security of the website.
I don't have the same browser surfing the Internet and viewing email or visiting a chat site or any other website. Keep those totally separate. So when you lose, when you're done with your banking, close out the browser. Don't leave that session open and go about surfing other websites.
Read your e mails in plain text.
Don't implement or don't follow hyperlinks in your email. Make sure when you're done with your bank session. Like I mentioned you, log off you close out that set that session and many clients side browser extensions. Now do mitigate See surf attacks.
The more recent browsers will do what they can to mitigate that, not store that information
in plain text. Limit some of the options and some of the ways our session ideas air stored. But again, we really have to be very careful with what we do in some of these time saving tips and techniques that we use, like saving passwords and usernames. Those could be used against us in a cross site. Request forgery.
Now, what can the developer do? Um, one of the first things implement the software to use a unique session specific token. So for each session, there's a unique token that's generated in a random, non predictable manner. So it shouldn't be
1234 It should be something that an attacker that's eavesdropping couldn't guess,
but that that session would be agreed upon and would be unique. That way it would make it harder for request forgery. You know, if I've got session 123 well, then the attacker would say, Well, the next session needs to be five.
So using a random, non predictable value is gonna help. Something else that we're seeing a lot of is the capture sessions, you know. And for a long time we were using the captured and and you've all seen these where it says enter the text in this box, you know, and
and its upper lower case. And a lot of times the values er
hard to read because of where they're placed. Whatever the capture can be used to establish specific token, identify IRS per session. So that's a way of getting a random, non predictable um, session I D. Is use it based off of a capture session.
Ah, session tokens must be validated, and it must be validated that their unique that we're not replaying
old session information. So when it comes to mitigating, see surf attacks there things that eyes and end user can do, and certainly there things that a developer can do and that usually revolves around uniqueness. Information for the session to mitigate these attacks.
All right, Number nine known vulnerability. Component usage. You know, many times we have access to libraries frameworks code that has been deprecating.
You know, many times when you're writing HTML, you'll find two ways of creating the same appearance on a Web page. But one of those types of languages or one of those references would be deprecating. So many times a developer will use older, outdated or deprecate ID code. And
the reason those those types of codes
have been deprecating is often because of security vulnerabilities or exploits. So what we want to make sure off as developers is, we're not using these deprecating, thes unsecure in band AP eyes. They may be what we're used to using. They maybe what we've used in the past.
We may see this and reusable code where I'm copying and pasting code that's already been initiated already been
created, so I don't have to recreate the code myself, but they present a security vulnerability. So any time I'm using these AP eyes or or anything that is older, that's outdated. That's been deprecate ID. I opened myself up to a security vulnerability,
all right, and then the last number 10 on a Wasps top 10 redirection unveil it dated, read erections and forwards so often I'll type out the site of a website on a dress that I want to go to, and that site will redirect me. So, for instance, if I type out both of b o f A,
I will be redirected to bank of America
dot com.
So what we want to make sure is that redirection is validated and that it's trusted
redirection s so that I'm not redirected to a fishing website or some sort of malware site. So what we want is we want to make sure that we're being redirected in a valid manner in a manner that can be trusted and that we can be assured of his reasonable redirection.
All right, so those air the top 10 security issues from the world of a WASP and this comes from their 2013 top 10 list, which is the most current right now, I would certainly recommend being familiar with the vulnerabilities that we've gone through enlisted here. You don't need to know their place on a wasps list,
but you need to have a sense of what the problem is.
And what are some ways that we can mitigate these threats? Um oh, what's what it does is an organization and its benefit. Its place in the Web application community, I think, also would be testable
Up Next