Web Attack Investigation Part 2

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

Already have an account? Sign In »

17 hours 41 minutes
Video Transcription
Hey, everyone, welcome back to the course. So in the last video, we talked about Web application forensics
in this video, where to start our discussion on the old lost top 10.
So the whole list top 10 we have injection, broken authentication, sensitive data exposure, XML, external entities or X X e Broken access, control, security, Miss Configuration, cross site scripting, insecurity serialization using components with known vulnerabilities. And then, of course, it's insufficient logging in monitoring.
So injection flaws. So things like, you know, your sequel l dap injections, etcetera, etcetera. Basically, this is when an untrusted data sent is gonna be untrusted. Data is sent to the interpreter assed part of a commander query. So, for example, I'm trying to log into a web page with the user name and password. An attacker then uses those fields instead
to run a sequel injection attack.
So they put a sequel command string in the like user name field, for example, and they try to pass that to the actual database.
So the goal is is to again try toe trick. So to speak the interpreter into executing that command on down from there, you know, potentially giving information back to the attacker about, you know, tables or even everything in the database, for that matter. Um, so it just kind of depends on how
ah, how vulnerable the Web application is to that type of attack.
So some prevention methods, they're just, you know, number one using a safe A p I right, which, which, excuse me, avoids the use of the interpreter entirely, or, you know, provides, you know, some kind of parameters that you know the command has to fall into for the interpreters, actually, you know, executed.
Why? Listing on the server side, you know, for input validation. So you know, again, just making sure that the attacker can't use whatever input they want. We we kind of white list things and say, OK, we'll only these types of things are allowed through.
And then using a sequel control scene also, for example, like the limit command to prevent the mass disclosure of records again, that's one of the goals of Attackers is to get all the data
broken. Authentication. So here the application functions are related to authentication. Session management are often implemented incorrectly. Right? So, uh, you know, generally, maybe a *** miss configuration type thing just kind of depends.
So this allows Attackers to compromise things like passwords, session tokens, you know, or even other implementation flaws, too. That way they can assume you know, someone else's identity, you know, either on a temporary basis or permanently, right. So they can either steal my banking website information and they pretend they're me and just keep accessing my account.
Or maybe just a temporary thing for that particular session.
Prevention here is gonna be things like multi factor authentication. So instead of just using, like, a user name and password, you know also like, for example, your bank might send you a code to your your cellphone. So things like that
not using default credentials. So that's kind of an obvious one, right? If you gotta set up their worth and admin panel on your website sees me on your Web server, then you're not gonna use the default user name and password. At least Please don't didn't do that. Um, checking for weak passwords, right. We want to make sure our passwords or complex. So that way, if the attacker is just using a password cracker,
you know, through, like, brute force or something like that.
Then you know, we would just want to make sure that they can't actually
having easy time, so to speak, of getting our password.
Ah, and under that, aligning with that, you know, just follow like mist 863 regarding password guidelines or some other areas as well. Like PC Idea says would have good information there
hardening against the enumeration of accounts and then also limiting the number of filled log in attempts, Obvious reasons They're right, the Attackers doing a brute force than if we limit them. After three attempts, it locks out the account, then they can't do anything right.
Sensitive data exposure. Eso This could lead identity theft. So basically
a lot of different Web applications and and even AP, eyes don't properly protect sensitive data. So things like your financial, you know, data or, you know, even like in a healthcare situation like you're protected information. So essentially the Attackers, my stealer, modify
that protected data to conduct things like, you know, identity theft, credit card car fraud,
you know, even other crimes. So, you know, the main thing here is maybe using, like, encryption at restaurant transit. You know, we wanna make sure we protect that data. So if they do get the data, they really can't do anything with it.
And then also, you know, we can classify the data, you know, again, you know, based on how it's being processed, stored and transmitted, we could say, Hey, this is really sensitive, you know? Go ahead and encrypt it. But again, we generally want encrypt all that type of information, anything sensitive and then applying appropriate controls as well,
XXI or XML. External entity.
So here, you know, some older or poorly configured XML processors evaluate external entity references within the XML documents, so this could be used to disclose internal files that are using the file. Your eye handler, maternal file shares port scanning internally remote code execution
on the NASA could be used in denial of service attacks as well.
So, you know, essentially here the goal was to try to get, you know, either either to to run a dollar store de dos or also to get data extraction
so we could prevent this by using, you know, less complex formats. You know, some things like your Jason, Um, you know, also patching and upgrading so again, that kind of you know, reverts back to the old school like a patch. Everything. You know, Patrick systems, patchouli applications, etcetera, etcetera. You know. So, for example, like updating soap, you know, the latest version of so
and the disabling XML External entity processing in the partners of the application eso eso if you go ah to the OS top 10. You know, they've got some different cheat sheets for these types of attacks on, so that in these types of ah, excuse me, vulnerabilities and weaknesses. So, um,
you'll find some different cheapseats preventing these as well as some good information. So definitely visit the old lost website
Broken access control pretty much as the name implies restrictions on what authenticated users were allowed to do. Um, and that's not properly enforced generally. So that way, Attackers can then exploit those flaws to gain unauthorized access, you know, to data or different functionality,
you know? So, for example, just accessing like someone else's account, right? Do you know? So,
um, the attacker comes in, they get one account, and then they you know, basically, it's the admin account, and now they can do terrible things to our servers,
and that allows them to also view, like, sensitive files, you know, modified data so they can change passwords, even change, like, you know, access rights for the user account.
So how can we prevent against this stuff? Well, you know, of course we can. Ah, you know, with exception of like, you know, resource is that we're leaving out there publicly we can deny by default, Right? So that way, all our private resource is internally are, you know, denied from access from an external account.
We could also disabled the Web server directory listing so that we the attacker, compromises something they can't see all the listing there,
implementing access control mechanisms, you know, and ah, basically Ah, you know, again going back to that, you know, multi factor authentication aspect of making sure that it's actually you know, you are I and not the attacker accessing things.
We could also log access control failures, you know, and and with that, you know, alerting administrators that Hey, there's, you know, x number of attempts here
and then also, you know, rate limit. The ap, I and controller access. So basically that with there's an automated attacking a tool that will help minimize the harm found from that
security. Miss Configuration s O. This is probably one of the most common things here. So think about it. You know, like when you when you see on the news like, hey, they miss configured in a W s bucket. And now, you know, classified information is lost Remotely sensitive information is lost. That's what we're talking about here.
So again, you know, this this is related to, you know, insecure defaults configurations, you know, are incomplete configurations. Or, you know, you kind of just rigged it up, so to speak. Um, also, Ah, you know, Miss Configured 83 headers, you know, air messages that are, you know, pretty ver boasts, you know? So if you're
if you're given, like, all sorts of data, back about the particular error, you know, like, Hey, it's in, You know, these different database tables.
Ah, we're not finding that that information, you know, we want to limit the information back to say, you know, like, air like, Oh, it didn't work or something like that, right? Obviously different Burbage. But, you know, you get the idea.
We just don't want the attacker to know basically what we've got going on. We want them the half kind of general error that they don't really understand what the information back is.
You know, it's so again here, you know, one of the main things is ah, you know, patching a ce faras prevention. We we just want to make sure we patch as well as you know, hardening the system,
you know, And with that, with that Harding, we want to make sure we have some type of key way process in place to make sure that we're continuously checking to make sure the system is still hard against threats,
making sure the platform doesn't have any unnecessary features turned on. So just making sure it's a minimalistic approach there.
And the segmenting our application architecture, right? So we just want to make sure that we separate between different components and different tenants, you know, So containers using containers are, you know, our cloud security groups.
And then finally, we have a cross site scripting, at least in this video, and then we'll cover the last few in the next video. So cross site scripting or excess s a CZ. You'll probably see it on the exam itself.
This is basically when the application includes untrusted data in a new Web page without proper proper validation of that data. So that could lead to things like remote code execution on the victim's browser. You know, stealing of credentials, deliver malware to victim, etcetera. Etcetera basically allows that attacker to execute the scripts, right?
and so different ways we can prevent against it s so we can use. You know, we could separate untrusted data from the active browser content. We can, you know, escape interested. Http. Request data. We could enable CSP or content security policy.
You know? So, uh, as I mentioned, you know, using frameworks that automatically escape cross site scripting. So things like, you know, the latest version of Ruby on rails react JavaScript, you know, things like that. But basically, we're just trying to limit the ability of the attacker to actually execute the code on the system.
So in this video, we cover the first portion of the lost top tens. We've covered the 1st 7 aspect. So injection, broken authentication, sensitive data exposure, XXI or XML, External entities, broken access control, security, Miss Configurations, cross site scripting.
So the next video, We'll cover the last tree. So insecurity serialization,
using components and with known vulnerabilities and then insufficient logging and monitory.
Up Next