In this video, we're going to talk
a lot about cross site request.
This is something that you'll normally
see when communicating with a website.
For example, you might visit my website at professormesser.com.
And when you visit the site, there's
going to be text that's loaded directly from my particular web
server.
The browser is also going to load videos if there
happens to be one on a page.
That video is not coming from the professormesser.com server.
That's coming from the YouTube servers.
And it might also involve loading some information that's
from Instagram.
So all of those pictures and images that you're seeing
are coming from the Instagram servers.
It's the HTML that's in your browser that determines where
your browser is going to go to gather the information that's
required to make up that page.
That is a completely normal and expected process.
And it works that way no matter whose website
you happen to be visiting.
What's interesting about a lot of the requests that
are made from the browser when you visit my website is when
you're gathering this information from YouTube
and from Instagram, you're not having to log in
to get that information.
That's information that is simply provided to your browser
without any type of login credentials.
It's this ability to use this trust that's in your browser
to be able to gather information from a third party site,
very often without the victim even
knowing that it's happening.
When you visit a website, there's
usually a combination of code that's running.
Some of the code is running in a browser that's on the client
and some of the code is running on the web server itself.
On the client side, you've got information
that's rendering in the browser to show graphics and text.
And it's usually something presented as HTML or JavaScript
to the browser itself.
There's also code that's executing on the web server
that's often HTML and PHP.
And this is used to perform back end processes.
For example, you might ask your bank to transfer data.
And all that transfer is occurring on the server side.
There are also server side components
used for doing things like posting videos to YouTube.
When you upload the video, there's
an entire re rendering process and posting process
that all takes place behind the scenes on the server
without your client on your computer being involved at all.
Let's first take advantage of the browser that's
on a client computer by using a cross site request forgery.
This is sometimes called a one click
attack or session writing.
You might see it abbreviated as XSRF or CSRF.
We often refer to this as a sea surf.
With this attack, we're taking advantage of the inherent trust
that a site has for your browser.
You might have already logged into Facebook, for example.
So every time you visit facebook.com,
it shows as your credentials whenever
you're visiting that page.
This potentially means that an attacker
could get your computer to create requests
on their behalf using your credentials.
And that's why this is a cross site request forgery and not
an actual cross site request that's done normally.
These types of forgeries obviously
should not be happening.
So the application developers of the web server
need to make sure that they're putting anti forgery techniques
into the code of the service.
Usually there's something like a cryptographic token that's
used so that someone would not be
able to use a forgery to obtain information from that server.
Here's an example of a cross site request
forgery that takes advantage of a client's browser.
We'll start with the attacker that's
going to communicate with a visitor
to a bank site's web server.
And the bank site web server is down here.
The attacker is going to create a request that takes advantage
of this bank site's visitor's browser
and it's going to send them that request in some way.
Maybe this request is a hyperlink inside of an email
and the attacker wants the client
to click on that hyperlink to perform the forgery.
The attacker is hoping when the user clicks on this link
that they will already be logged in to the bank site's server.
When they click that link, it sends the request
sometimes without the user even realizing it
to the bank's web server.
And because this user is logged in properly,
this request is performed as if it's coming directly
from the bank site's visitor.
If this request is a funds transfer,
then the bank web server transfer the funds
to the attacker and pulls it out of the bank site's visitor's
account and the request forgery is complete.
Another type of forgery gets rid of the client completely.
We don't have to worry about trusting
that a browser is logged in.
We'll instead perform the forgery directly
on the server side.
This is a server side request forgery, or SSRF.
This requires that the attacker find
a web application that is susceptible to
this particular kind of attack.
And if we send specially crafted packets to the web server,
we might be able to have the web server do some work for us
on its behalf.
This type of attack needs a vulnerable application
running on a web server.
The attacker will send a request to the web server
and the web server will then perform those requests
on behalf of the attacker.
This allows the attacker to access services that
normally would be inaccessible.
They might be on the inside of a private network
that only the web server might have access to.
But because they're using this server side request forgery,
they can now gain access to those services that
normally would be unavailable.
This is a type of attack that occurs because the web
application is vulnerable.
The developers have to make sure that any of the requests that
are input are not going to be used by the server
to perform additional functions.
The server should always evaluate the input
to the server and evaluate the output
to make sure that none of that information is unexpected.
These are relatively uncommon types of vulnerabilities.
But when one is found, it's very important to close it
before someone's able to take advantage of that forgery.
Here's a visual breakdown of the server side request forgery.
We'll start with an attacker who's
communicating to a web server.
They will send a request that is going
to require that web server to perform some other function
in the background.
For example, they may be sending a request
to the web server that has the web server query information
on a file storage device.
That file storage device sends a file, or some type of response,
to the web server.
And the web server responds back to the attacker
with the information that was requested.
That effectively means the attacker has access now
to the file storage even though there is no direct access
from the outside.
They're having the web server perform that access by using
this forgery vulnerability.
Here's an example of a server side request forgery
that occurred in 2019.
This was one where an attacker was
able to execute commands on the Capital One bank website.
This is an attack type that's normally
prevented if you're using a web application firewall, or a WAF.
In this particular case, they believe that the WAF itself
was misconfigured and the attacker was
able to query that WAF and gather information directly
from that service.
We believe that by using this SSRF attack,
the attacker was able to get security credentials
of the WAF, and by using those security
credentials was able to access a bucket on Amazon's
simple storage service, or S3.
This is a file system that exists in the Amazon cloud.
Those credentials were able to access those S3 buckets.
And inside of those buckets on the Capital One Amazon
account where credit card applications that range
from 2005 through 2019.
That was 106 million names, addresses, phone numbers,
emails, and dates of birth that consisted
of 140,000 social security numbers,
and over 80,000 bank account numbers
all because they were able to perform this forgery that
ultimately gave them access to that bucket.