Okay, Coming in at number six on the WASP. Top 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 HCPs 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,
uh, whatever that is. But data exposure sensitive 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,
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. Dad 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 u. R l so that, um, I am ableto access something that I shouldn't be like. The normal user interface
may restrict me from going to sales figures
April, but if I could 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 a 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 men?
Don't use the Remember me options and websites Now again, Maybe not all websites. It depends on the security of the website.
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,
we'll 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 capture and and you've all seen these words has inner the text in this box, you know, and and its upper lower case. And a lot of times the values are hard to read because of where they're placed. Whatever.
Um, 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 using 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 an 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, unveiling, dated, read erections and forwards so off. Then 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
So what we want to make sure is that redirection is validated and that it's trusted
redirection s O 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 are 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 the 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.
Oh, watch what it does is an organization and its benefit. Its place in the Web application community, I think, also would be testable.