All articles in
Network Security
AWS WAF Demo: Protecting Against SSRF Attacks
Welcome, everyone! This article explores how AWS Web Application Firewall (WAF) can effectively prevent application vulnerabilities. Through a demonstration, we’ll illustrate how AWS WAF could be used for mitigating SSRF (Server-side Request Forgery). SSRF is a security vulnerability where an attacker tricks a web server like AWS EC2 into performing unwanted actions, such as sending HTTP requests to access sensitive AWS credentials stored in the IMDS server or accessing internal systems on AWS. This can lead to unauthorized data exposure or compromise of AWS resources.
Follow the 13 steps mentioned in this article to create your own demo for testing SSRF vulnerability and remediating with WAF on AWS.
Architecture Blueprint
Let’s start with a quick blueprint of how this demo would work:
In the blueprint, the first thing to notice is the AWS EC2 instance hosting the demo web application. This EC2 instance has been deliberately made vulnerable in two main ways:
- By deploying an intentionally vulnerable open-source web application called bWAPP (provide link).
- By using IMDS v1 (provide AWS link).
IMDS v2 is more secure against SSRF attacks because it uses tokens to access AWS credentials.
From an attacker’s perspective, they send a specially formatted HTTP request to trick the web application into reaching out to the IMDS server, grabbing the AWS credentials, and returning them in the HTTP response body.
To defend against this, we need to set up some AWS infrastructure:
- First, we need to place an Application Load Balancer (ALB) in front of the EC2 instance. This is necessary because WAF can only be associated with global resources like CloudFront, or regional resources like API Gateway, AppSync, App Runner, and ALB.
- Next, we need to create a WAF WebACL rule to detect and block the malicious HTTP requests from attackers.
Part 1 – Creating SSRF-vulnerable demo app on AWS
Let’s dive into the technical steps needed to create a SSRF-vulnerable demo app on AWS.
☞ Prefer a video lab instead? Take a look at our detailed video on how to do create a SSRF vulnerable demo app on AWS:
♦ 1 ♦ Create a VPC to host EC2 with 2 public Subnets in 2 different Availability Zones (AZs)
Why public subnets? We need public subnets to access the EC2 instance from our personal laptops for remote desktop access and sending HTTP requests. This setup is just for the demo. For a real application, you should use a Bastion host with the EC2 instance only accessible privately.
Why 2 subnets? We need 2 subnets in 2 different Availability Zones (AZs) in this VPC because it’s a requirement for deploying an ALB in the VPC.
To learn more about AWS VPCs ☞
♦ 2 ♦ Create a Security Group and allow ingress on port 80 and port 3389 from 10.0.0.0/8 and your laptop’s IP address
Why port 80 and 3389? We need port 80 to simulate an attacker accessing the web app from a browser to exploit SSRF. Port 3389 is necessary for Remote Desktop Protocol (RDP) access to the Windows machine for installing the web application contents. In this demo, our EC2 instance would be a Windows server.
Why 10.0.0.0/8? We need incoming access from 10.0.0.0/8 for ALB to access the EC2
♦ 3 ♦ Create an IAM role that can be assumed from “ec2.amazonaws.com”. Then create an Instance profile and add the IAM role to the instance profile.
Why create an Instance profile? An Instance profile is necessary because it allows a role to be attached to the EC2 instance.
To learn more about AWS Roles ☞
♦ 4 ♦ Create a Key Pair to Remote Desktop into the EC2 instance
♦ 5 ♦ Deploy a Windows Server 2022 on an EC2 instance, and make sure it’s attached to the VPC, subnets, security group, IAM instance profile, and key pair created in the previous step. Additionally, ensure to select “HttpTokens=optional” for metadata options.
Why choose HttpTokens=optional? This allows the EC2 instance to use V1 for accessing the IMDS metadata server. While V1 is vulnerable to SSRF, V2 provides protection against SSRF by using tokens.
♦ 6 ♦RDP into the EC2 using the Key Pair, and install the buggy web application.
What is a buggy web application? bWAPP, or a buggy web application, is a free and open source deliberately insecure web application. It helps security enthusiasts, developers and students to discover and to prevent web vulnerabilities. bWAPP prepares one to conduct successful penetration testing and ethical hacking projects.
♦ 7 ♦Test for SSRF attack on the vulnerable page of the website – bwapp/rlfi.php. Trick the EC2 into reaching out to the IMDS server to get AWS credentials of the IAM Role attached to EC2, and display them in the browser.
You have now conducted a successful SSRF attack on an AWS EC2 instance! Congrats!
Part 2 – Create defense mechanisms against SSRF using AWS WAF
With the vulnerable application now setup for us to test SSRF vulnerability, let’s start with our defense against SSRF using AWS WAF.
☞ Prefer a video lab instead? Take a look at our detailed video on how to prevent SSRF attack using AWS WAF –
What is WAF? WAF is a managed firewall service designed to protect web applications from common web exploits, such as SQL injection and cross-site scripting (XSS) attacks. WAF uses rules and conditions to inspect incoming HTTP/HTTPS requests and block malicious traffic. You can protect a wide range of AWS resources like Amazon CloudFront distribution, Amazon API Gateway REST API, Application Load Balancer, etc.
Unlike Security Groups and Network Access Control Lists (NACLs), which filter traffic at the L3/L4 layer of OSI, WAF works at L7 and thus is able to filter traffic based on the actual content/payload of the packet.
To learn more about AWS Firewalls ☞
♦ 8 ♦ Create a Target Group for HTTP/80 and EC2 instance type traffic. Provide the same VPC ID which is attached to the EC2.
Why use a Target Group? A Target Group is a collection of network settings for the targets of Load Balancer traffic. You need it to set up a Load Balancer.
Why HTTP/80? The demo vulnerable web application is listening on this protocol/port
♦ 9 ♦ Register the EC2 instance as a target for the above Target Group
♦ 10 ♦ Create Application Load Balancer attached to the two Subnets within the VPC. Also, attach the Security Group of the EC2 to the Load balancer.
Why we have used the same Security Group for EC2 and Load Balancer? Ideally the load balancer only needs ingress over port 80 from your laptop ip address. But since this is a demo, and I didn’t want to create extra resources for this ALB, I am using the same security group.
♦ 11 ♦ Create Listener for the ALB over HTTP/80 and forward traffic to the Target Group
Now, we are ready to create the final piece in our defense puzzle – WAF WebACL rule.
♦ 12 ♦ Create a WAF WebACL rule for Regional resources in the same AWS region as the EC2, and associate it to the ALB created earlier. Use the Rule Builder option to create a custom rule with the following logic –
If a request matches the statement – “Inspect All query parameters for a match with the Regular Expression : ^(http|https)://\S+ “. If a match is detected, then block the request with 403 and a custom response body.
What does “^(http|https)://\S+” regular expression mean? It is used to match URLs that start with “http://” or “https://”
♦ 13 ♦ Test again for SSRF attack on the vulnerable page of the website – bwapp/rlfi.php
There you go! WAF has successfully detected that we are supplying http/https url as part of the input, and has blocked the request, thus preventing SSRF attack.
Thanks for reading! For more such fun articles and videos, follow us on our Youtube channel.
Follow us on:
Follow us on: