In the next series of posts I’m going to provide a tutorial on how to write and exploit and SQL Injection vulnerability on a web applications. However, before we can get there we need to setup our database.
We could set it up on our local machine, but that would be too easy, instead we’ll use Amazon’s RDS (relation database service) to setup our database.
I’m not going to walk you through creating an AWS account, it’s pretty straightforward. I’m going to assume you have an account.
1 Navigate to the RDS Service Dashboard
If you don’t know how to get to the RDS Service, you can search for it:
You’ll be presented with following dashboard:
II. Create Database
In the Create Database page, we’ll select the following features:
- Database Creation Method – “Standard Create”
- Database Engine – “MySQL”
- Version – 8.0.27
- Template – “Free Tier”
- DB Settings – Username/Password
- Instance Class – Leave Default
- Storage – Leave Default
- Connectivity – Leave Default
- Database Authentication – “Password”
- Create Database
You’ll be re-directed to the following screen:
It will take a few minutes for the server to get created on AWS’ servers. The server is technically created/built at this point, however, we now have to make it accessible from the Internet, i.e. your home computer.
- Click on the “database-1” hyperlink to configure
III. Make the DB “Publicly Accessible
- Click on “Modify”
- In the “Connectivity Section”, Click on “Additional Cofiguration”:
- Select “Publicly Accessible” option:
- Click on “Continue” at the bottom of the page
- Click on “Modify DB Instance” on the next page
We are not yet complete with our configuration. You’re RDS or EC2 instances inside your VPC (Virtual Private Cloud) have NACLS (Network Access Control Lists) and Security Groups (SGs) applied to them:
IV. Quick Lesson on SG and NACLS
- Security Groups
Think of Security Groups as Host Level Firewalls. All of your instances running in your VPC must have a Security Group applied to them.
With Security Groups, you set the allowable ports/protocols/services and source addresses.
- Network Access Control Lists
NACLs are applied to the subnets in your VPC. Every subnet in your VPC must have NACL associated with it.
All of your instances will belong to a Subnet.
All of your Subnets will have a NACL applied to them.
With NACLS, you can configure based on IP address(es) and Ports
- Quirks
If you have NACLs set to allow “All traffic” through, but your Security Group is “Deny All”, you won’t be able to reach your instance
If you have your NACL set to “Deny All”, but your SG to “Allow All”, you won’t be able to reach your instance
A good strategy with managing NACLs and SG is:
- NACLs: Filter only by IP and allow all ports/protocols
- Security Groups: Filter by Ports/Protocols
V. Configuring the Security Group
- From RDS Dashboard, click on your DB Instances
- Select your DB Instance
- Under the “Connectivity and Security” menu, select the default security group
- Recall that this was left to default when first created the DB
- This Dashboard shows which SGs are applied to our RDS instance and we can just follow the links to edit it.
- Select “Edit inbound rules”
- Add rule to allow “MYSQL/Aurora” traffic type from the drop down
- Select “Save Rules”
VI. Configuring the NACL
- From RDS Dashboard, select “DB Instances”, then select your running RDS instance
- Click on the VPC hyperlink under “VPC”
- Click on the hyperlink under “Main network ACL”
- mine is “acl-f483728f”
- your’s will be different
- Click on the “Inbound Rules” tab, then “Edit Inbound Rules”
- Add a rule to allow all ports and traffic (0.0.0.0/0)