An attacker can take advantage of legitimate cross-site requests and turn them into a malicious exploit. In this video, you’ll learn about cross-site request forgeries and server-side request forgeries.
<< Previous Video: Replay Attacks Next: Driver Manipulation >>
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.