>> Hey, everyone. Welcome back to the course.
In the last video, we talked
about web application forensics.
In this video, we're going to start
our discussion on the OWASP Top 10.
The OWASP Top 10, we have
Injection, Broken Authentication,
Sensitive Data Exposure,
XML External Entities or XXE,
Broken Access Control,
Security Misconfiguration, Cross-Site Scripting,
Insecurity Deserialization,
Using Components with Known Vulnerabilities,
then of course, Insufficient Logging and Monitoring.
Injection flaws, things like your SQL,
LDAP injections, et cetera.
Basically, this is one, and untrusted dataset,
is going to be untrusted data,
is sent to the interpreter as part of
>> a commander query.
>> For example, I'm trying to log into
web page with the username, and password
an attacker then uses those fields
instead to run a SQL injection attack.
They put a SQL command string in the username field,
for example, and they try
to pass that to the actual database.
The goal is to, again, try to trick,
so to speak, the interpreter into
>> executing that command.
>> Then from there, potentially giving information back to
the attacker about tables
or even everything in the database for that matter.
This depends on how
vulnerable the web application is to
>> that type of attack.
>> Some prevention methods there,
just see our number 1, using a safe API, right?
Which avoids the use
of the interpreter entirely, or provides
some parameters that the command has to
fall into for the interpreter to actually execute it.
Whitelisting on the server-side for input validation.
Again, just making sure that
the attacker can't use whatever input they want.
We whitelist things and say, "Well,
only these types of things are allowed through."
Then using a SQL controls.
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.
Here are the application functions
related to authentication, and
session management are often implemented incorrectly.
Generally, maybe a misconfiguration
type thing just depends.
This allows attackers to compromise things
like passwords, session tokens,
or even other implementation flaws to that way,
they can then assume
someone else's identity either
on a temporary basis, or permanently.
They can either steal my banking website information
and pretend they're me, and just
keep accessing my account or
maybe just a temporary thing for
>> that particular session.
>> Prevention here is going to be
things like Multifactor authentication.
Instead of just using a username or password,
also like for example,
your bank might send you a code to your cell phone.
Things like that. Not using your default credentials.
That's an obvious one.
If you've got a set up there
with an admin panel on your web server,
then you're not going to use
the default username, or password,
or at least please don't do that.
Checking for weak passwords, right?
We want to make sure our passwords are complex.
That way if the attacker is using
a password cracker through
brute force, or something like that.
Then we would just want to make sure
that they can't actually have an easy time,
so to speak of getting our password.
Under that, aligning with that,
just follow NIST 800-63 regarding password guidelines,
or some other areas as well like PCI,
DSS would have good information there.
Hardening against the enumeration of accounts,
and then also limiting
the number of failed login attempts.
Obvious reasons there, right?
The attackers doing a brute force,
then if we limit them after three attempts,
it locks out the account, then they can't do anything,
right? Sensitive data exposure.
This can lead to identity theft.
Basically, a lot of different web applications,
and even APIs don't properly protect sensitive data.
Things like your financial data,
or even in health care situation,
like you're protected information.
Essentially, the attackers might steal, or modify that
protected data to conduct things like identity theft,
credit card fraud, even other crimes.
So the main thing
here is maybe using a encryption at rest,
>> or in transit.
>> We want to make sure we protect that data,
so if they do get the data,
they really can't do anything with it.
Then also, we can classify the data, again,
based on how it's being processed, stored,
and transmitted, we can say, "Hey,
this is really sensitive.
Go ahead and encrypt it."
But again, we generally want to
encrypt all that type of information,
anything sensitive, and then
apply appropriate controls as well.
XXE or XML External Entity.
Here are some older or poorly configured XML processors
evaluate an External Entity references
within the XML documents.
This can be used to disclose internal files
that are using the file URI handler,
maternal file shares,
port scanning internally, remote code execution,
and then that also can be used in
denial-of-service attacks as well.
Essentially, here the goal is to try to get either to
run a DoS or DDoS or also to get data extraction.
We can prevent this by using less complex formats,
things like your JSON,
also patching and upgrading.
Again, that reverts back
to the old school like, hey patch,
everything, patch your systems,
patch your applications, et cetera.
For example, updating soap,
the latest version of soap.
Then disabling XML, External Entity
processing in the parsers of the application.
If you go to the OWASP Top 10,
they've got some different cheat sheets for these types
of vulnerabilities and weaknesses.
You'll find some different cheat sheets
preventing these as well as some good information.
Definitely, visit the OWASP website.
Broken Access Control.
Pretty much as the name implies,
restrictions on what authenticated
users are allowed to do.
That's not properly enforced generally.
That way attackers can then exploit those flaws to gain
unauthorized access to data or different functionality.
For example, just accessing
someone else's account, right?
The attacker comes in, they get one account,
and then they basically the admin account
and now they can do terrible things to our servers.
That allows them to also view sensitive files,
modified data so they can change passwords,
even change access rights for the user account.
How can we prevent against this stuff?
Well, of course, with the exception
of resources that we're leaving out there publicly,
we can deny by default.
That way, all our private resources, internally,
are denied from access from an external account.
We can also disable
the web server directory listing so that
the attacker compromises something they
can't see all the listing there.
Implementing access control mechanisms.
Basically, again, going back to
that Multifactor Authentication aspect of making sure
that it's actually UAI
and not the attacker accessing things.
We can also log access control failures,
and with that, alerting administrators that,
"Hey, there's x number of attempts here."
Then also why you don't rate limit
the API and controller axis.
Basically, that way if
there's an automated attacking a tool
that will help minimize the harm found from that.
Security Misconfiguration.
This is probably one of the most common things here.
Think about when you see on the news," Hey,
they misconfigured an AWS bucket,
and now classified information is lost."
You know at least sensitive information is lost.
That's what we're talking about here.
Again, this is related
to insecure default configurations,
incomplete configurations or,
you can have just rigged it up, so to speak.
Also misconfigured HTTP headers,
error messages that are pretty verbose.
If you're given all sorts of
data back about the particular error,
"Hey, it's in these different database tables,
we're not finding that information."
We want to limit the information back to say,
"Oh, it didn't work or something like that, right?"
Obviously different verbiage but you get the idea.
We just don't want the attacker to
know basically what we've got going on.
We want them to have a general error
that they don't really understand
what the information back is.
Again, here, one of the main things is patching,
as far as prevention,
we just want to make sure we
patch as well as hardening the system.
With that hardening,
we want to make sure we have some type of
QA 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.
Just making sure it's a minimalistic approach there.
Then segmenting our application architecture, right?
We just want to make sure that we separate
between different components and different tenants.
Containers, using containers or a Cloud security groups.
Then finally, we have cross-site
scripting and at least in this video,
and then we'll cover the last few in the next video.
Cross-Site Scripting or XSS,
as 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 validation of that data.
That can lead to things like
remote code execution on the victim's browser,
stealing of credentials, delivery of
malware to the victim, et cetera.
Basically, allows an attacker to execute the scripts.
Different ways we can prevent against it.
We can separate untrusted data
from the active browser content.
We can escape untrusted HTTP request data.
We can enable CSP or Content Security Policy.
As I mentioned, using
frameworks that are automatically
escape Cross-Site Scripting.
Things like the latest version of Ruby on Rails,
React JavaScript, things like that.
Basically, we're just trying to limit
the ability of the attacker to
actually execute the code on the system.
In this video, we covered the first portion
of the OWASP Top 10.
We've covered the first seven aspects: Injection,
Broken Authentication, Sensitive Data Exposure,
XXE or XML, External Entities,
Broken Access Control,
Security Misconfigurations, Cross-Site Scripting.
The next video we're going to cover the last three.
Insecurity Deserialization,
Using Components with Known Vulnerabilities,
and then Insufficient Logging and Monitoring.