Blog

Protect Your Sites from SQL Injection attacks with the Akamai Docker Image

June 2, 2020 · by Javier Garza ·
Categories:

Protecting websites against SQL injections and other security attacks has never been easier. In this blog post, I'll demonstrate a workflow that allows to protect against an SQL injection attack by configuring a firewall at the Edge. See the full demo at the end of this post. 

For the origin, I used a PHP web server called DVWA (available in GitHub) that allows you to easily change the security levels of your site and simulate application layer attacks. 

First, I opened the administrative web interface for DVWA and changed the security setting to low in order to see how easy it is to launch an SQL injection attack and dump all the users in our database.

Next, I opened: http://jgarza2.appsec.astronaut.training/security.php in a new browser tab and logged in with my credentials. In the DVWA site, I entered %'or '0'='0 to view the user data. 

Next, I needed to configure the Akamai web application firewall to protect this site against SQL Injection attacks. I was able to do this with 4 API calls using the Application Security CLI (included in the Akamai Development Environment) and can be easily scripted to protect new sites in a couple of minutes.

I followed these four steps:

  1. Create a new version of the security configuration, so I can protect my website 

  2. Create a new security policy that protects against SQL injection attacks and attach it to the new website

  3. Indicate the scope of the protection by applying it to all URLs

  4. Activate the new version of the security policy

Note that I am storing the values returned by the API calls into shell variables to easily pass it to the next API call, which is something very common when automating tasks. 

I stored the hostname I wanted to protect into an environment variable called my_hostname so I don’t have to enter it later on:

Akamai DevOps [~] >> my_hostname=jgarza2.appsec.astronaut.training

 

Akamai DevOps [~] >> echo $my_hostname

jgarza2.appsec.astronaut.training

Using the application security CLI, I created a new version of the security configuration in the staging network. This API call returns the version number so we will run the command below to store the output of the call into an environment variable called security_version_id.

Akamai DevOps [~] >> security_version_id=`akamai appsec --section security clone --config 47147 --version STAGING`

Next, I created a new security policy by cloning a system policy that protects against SQL Injection attacks (BASE_85619), and attached it to the new website by referencing the variable we defined earlier. 

I ran the CLI command in a similar way as we did before in order to store the output into a variable called security_policy.

Akamai DevOps [~] >> security_policy=`akamai appsec --section security clone-policy BASE_85619 --config 47147 --version $security_version_id --prefix JG${security_version_id} --name $my_hostname`

The next step is to indicate the scope of protection by applying the security configurations to all URLs as indicated with a slash followed by a star.

Akamai DevOps [~] >> akamai appsec --section security create-match-target --config 47147 --version $security_version_id --hostnames $my_hostname --paths '/*' --policy $security_policy

 

2614333

Lastly, I activated the security configuration in staging.

Akamai DevOps [~] >> akamai appsec --section security activate --config 47147 --version $security_version_id --network STAGING --note “adding SQL injection protection” --notify no-reply@akamai.com 

 

468326

This step may take a few minutes. You use the “version” parameter to check the status of a given version.  

Akamai DevOps [~] >> akamai appsec --section security version --config 47147  --version $security_version_id --verbose | jq .staging.status

 

"status": "Pending"

The above output shows the version is currently pending activation in staging.

Once activated the same API call should return the following output:

Akamai DevOps [~] >> akamai appsec --section security version --config 47147  --version $security_version_id --verbose | jq .staging.status

 

"status": "Active",

Now, when I repeat the SQL injection attack, I get an access denied message, showing that the security configuration was successful.

Access Denied

 

You don't have permission to access "http://jgarza2.appsec.astronaut.training/vulnerabilities/sqli/?" on this server.

Reference #18.2c323217.1589938812.3bd5b5

You can view the full demo here:

 

You Might Also Like: 

About the author

Javier

Javier Garza is a developer evangelist at Akamai Technologies where he helps the largest companies on the internet run fast and secure apps by leveraging web performance, security and DevOps best practices. Javier has written many articles on HTTP/2 and web performance, and is the co-author of the O’Reilly Book “Learning HTTP/2”. In 2018, Javier spoke at more than 20 developer-related events around the world, including well-known conferences like Velocity, AWS Re:Invent, and PerfMatters. His life’s motto is: share what you learn, and learn what you don’t. In his free time he enjoys challenging workouts and volunteering for non-profits in areas like children and education