>> Vulnerability Risk Mitigation part 1.
The learning objectives for this lesson are;
to differentiate between types
of web application vulnerabilities,
to define web application components,
and to implement protection strategies
for web applications.
Let's get started. Web application components.
Before we can go into any of
the vulnerabilities and the ways
we can help remedy those,
we're going to discuss the different parts
of web technology
to help us understand
the different parts that can become vulnerable.
The first part we're going to discuss is
client-side processing versus server-side processing.
This is a description of where
the work is being performed.
Is it being performed on
the client's machine or
is it being performed at the server?
Web apps have begun to shift
the work away from server-side,
more towards client-side lately.
JSON Representational State Transfer or REST.
This is a text format that's
used to store and transmit data.
It's similar to XML, although it's simpler.
It is a data exchange based on web technologies.
Simple Object Access Protocol or SOAP.
This is an interface communication mechanism.
SOAP is a protocol instead
of being an architecture like REST.
SOAP APIs can be exploited by SQL injection.
Browser Extensions.
These are adding additional
functionality to our browsers.
It's not accessible by the code launched by the browser,
and plugins can be called by website code.
These are the add-ons that we add onto
Chrome or to Firefox that allow us to say,
HTTPS everywhere forces every website
that we visit to use HTTPS.
It may be U-block origin,
which helps us to block
malicious content or scripts on websites.
But all of these add
additional functionality to our browsers.
Hypertext Markup Language 5, or HTML5,
and Asynchronous JavaScript and XML or AJAX.
These are designed to replace
the flawed functionality of plugins,
but they also bring with them their own new problems.
HTML5 features that you're going to want to
consider when you're looking to
secure a web application would be web messaging,
cross-origin resource sharing,
WebSockets, server-sent events, local,
offline or web storage, client-side databases,
geo-location requests, WebWorders,
Tabnapping, and Sandboxed Frames.
Machine code versus bytecode.
Bytecode represents the intermediary state of
source code that is created by
a high-level language when it's compiled.
It's designed to be
processed by an interpreter on the target system.
The interpreter translate the bytecode into machine code.
Now, machine code is the lowest level of source code
that the devices on the machine can understand.
Software composition analysis.
This is the process where the software will be
analyzed to see if it
contains any open source components,
and that they are themselves secure because
these open source components that we're including
with our own software programs,
they can contain their own vulnerabilities.
This can be performed manually,
but it's usually performed with automation tools.
A good example of one of these tools is
the OWASP dependency check tool.
This will scan source code and it will identify
any publicly known vulnerabilities in
the code and also the libraries that it's using.
Web application vulnerabilities.
The first one we're going to discuss is a race condition.
This occurs when several processes
are needed to complete a task.
The apps can be manipulated by altering
the assumptions that are made on
the processes and their outcomes.
The next is a buffer overflow.
This is when we fill the temporary memory space up.
By doing this, a well-designed attack can add
information to the end of
the buffer in hopes that it will be executed.
You could do this to access other parts of
the system memory and
also for code insertion and execution.
The defenses for this would
include patching, secure coding,
address space layout randomization or ASLR,
and data execution protection or DEP.
Broken authentication.
This is when an app
doesn't protect authentication mechanisms,
it will allow an attacker to
compromise user sessions or passwords.
An example would be session identifiers in a URL.
You've logged onto a website,
and in the URL, if you look,
you've got a session ID.
If we modify that session ID,
we might be able to take over someone else's session.
Defenses against this would
include slowing down failed login attempts,
server-side session management that creates
a random session identifier rather than
one that's easily guessed or follows a pattern,
and not using session IDs and URLs or session timeouts.
Insecure references.
This is a class of vulnerabilities that is
related to weak access controls.
An app takes user-supplied input and then uses that to
give access to areas that
normally shouldn't be accessible to that user.
An example of this is having a user ID in the URL,
similar to the one we just discussed.
But if you see a customer ID
or something that uniquely
identifies that user in the URL,
chances are you can change that to
another number and be able to look into
someone else's profile because
you're using their user ID now in the URL.
Weak ciphers and cipher suites.
Weak ciphers are the individual encryption ciphers
that are not considered safe for modern use.
Examples would be DES,
SHA-1, and MD5.
Now cipher suites, on the other hand,
are all the parts together that deliver a total function.
TLS is an example of
this because it contains key exchange,
digital signature, encryption, and hashing capabilities.
Web application vulnerabilities.
Improper headers.
HTTPS response headers control how
web servers operate to increase their overall security.
Properly configured headers can prevent
cross-site request forgeries, cross-site scripting,
downgrade attacks, cookie hijacking,
user impersonation, click jacking,
and many other attacks.
Certificate errors. This is when
a certificate is improperly set up on a web server.
We use certificates because it's
a critical part of our entire SSL infrastructure.
Servers have a certificate,
clients have a certificate,
and they authenticate with each other.
But if we don't set up a certificate
properly on a server,
it will display an error or to users.
What this does is it trains users to click
past the error so they can access the website.
If users are trained to do that,
and they received a phishing link that leads them to
a cloned Microsoft website with a certificate
that doesn't match Microsoft
and they just click past it,
that now they've fallen for it and the error should be
a warning that this site is not valid.
So we have to do our part to make sure we set up
our certificates properly so that we
don't present users these errors. Let's summarize.
We went over web application vulnerabilities.
We discussed race conditions and buffer overflows.
We also went over web application components
and software composition analysis.
Let's do some example questions.
Question 1, this vulnerability can
occur when several processes
are needed to complete a task.
Race condition. Question 2,
this occurs when temporary memory space
is overflowed with the purpose
of executing additional code or
reading different areas of system memory.
Buffer overflow. Question 3, DES, MD5,
and SHA-1 are examples of this. Weak ciphers.
Finally question 4, this vulnerability is described by
weak access controls that allow
user-supplied input to access areas
that are normally not accessible.
Insecure references.
I hope this lesson was useful for you,
and I'll see you in the next one.