Protect Applications in Google Cloud Platform (GCP) using Azure WAF

[Guest tobiotolorin]

Azure Web Application Firewall (WAF) provides centralized protection of your web applications from common exploits and vulnerabilities. You can deploy WAF on Azure Application Gateway or WAF on Azure Front Door Service.

 

This blog provides the steps to validate the deployment of a sample coffeeshop application in GCP and how to apply Azure WAF to implement security controls for access to the application. The Coffeeshop application has been modified from the online sample SQL injection application

 

 

 

In this blog post:

 

1. We will deploy our Coffeeshop application into GCP
   
2. We will then publish this application via the Azure App Gateway
   
3. Next, we will restrict access to the application in Google Cloud to only requests coming from App Gateway’s public IP address
   
4. We then test for SQL injection and XSS attacks.
   
5. Finally, we observe the events in our logs.
   

 

 

 

 

 

As shown in the diagram above, there are two paths to access the Coffeeshop app, delineated by the amber and green arrows. The amber arrow is direct access to the web app in GCP (to be denied in the 3rd phase) and the green path provides access through the App Gateway/WAF with DDoS protection enabled on the host VNet.

 

 

 

Deploy the application in Google App Engine (Step 1):

 

1. Go to Google cloud. Sign up/Login (trial account works) and go to Console. Create a new project. We called this project SampleappGCP.
   
   
   1. 
      
   2. Go to the Cloud shell and run a command e.g.
      gcloud projects list
      You will be required to Authorize access for the first time. Authorize the access.
      
      1. Enable the API for App Engine.
         a. Go to the left blade and search for APIs and Services.
         b. In the "+ Enables APIs and Services bar, search for App Engine(admin) API and enable it
          
         
         

      [*]

      Go back into the GCP Shell and make sure you are in your project directory. If you are not in the directory, use the following commands to see the projects ID and then navigate into the project (Coffeeshop in this case) directory:

       

      gcloud projects list

       

      gcloud config set project <Project ID obtained from the list above>

   • Go into the task bar.
     
   • Search for App Engine.
     
   • Click “Create application” and select a region to use.
     

 

 

 

 

Now that the app has been created, we need to deploy our code into the app. Go to the Cloud shell and clone the Coffeeshop app from Network Security Github

 

 

 

 

 

git clone GitHub - tobystic/sql-injection-demo: A simple mockup of a webshop to demonstrate the sql injection vulnerability.

 

 

 

 

 

 

 

 

Go into the repository that you have just cloned and deploy using the app.yaml file. Click yes to follow the prompt. This will take some few minutes

 

 

 

olotolor@cloudshell: ~ gcloud app deploy app.yaml

 

 

 

If all go well, the code should be deployed in the app created and you would be presented with a URL to access the application. e.g., https://sampleappgcp.wl.r.appspot.com. If you modify your code or yaml file, you have to run this command again to redeploy the app.

 

 

 

 

 

 

Create the SQL connection for the Coffeeshop application (Step 2)

 

 

Enable SQL database and use the database information in the readme page (also updated in the yaml file) to create a database in Cloud SQL. (You can ignore this step and just create a custom rule to test WAF if you do not need SQLi and XSS tests)

 

• Go to the left blade and Select Cloud storage.
  
• Create a bucket(sampleappsql).
  
  • Upload the database files from the SQL folder of the app files (from Network Security Github) into the sampleappsql bucket in your Cloud storage.
     
    
     
    

  [*]Go to the left blade and click SQL

  [*]Create MySQL instance (Coffeeshop) and set up the password (optional). (Make sure to update the instance name in the DB_host and Cloud SQL instance parameters in your yaml file). Also, ensure the cloud instance path is updated in the connnectdb.php file in the mysqli_connect string.

  [*]Select region and dev env. When done, click “Create instance”, this will take some minutes .

  [*]From the menu pane, create a database “inject_demodb”

  [*]Create user “sql_injection”

  [*]Click “Import” to import the databases from your Cloud bucket

 

You can confirm the status of your SQL API by using the describe command on instance name in the shell.

 

 

 

$ gcloud sql instances describe coffeeshop

 

 

 

 

 

 

Confirm connection using your root account.

 

 

 

gcloud sql connect coffeeshop --user=root –quiet

 

 

 

Go back to the cloud shell and redeploy your app using gcloud app deploy app.yaml . You should now see the coffee options populated

 

 

 

 

Publish Application via Azure App Gateway

 

 

(You may use the app gateway in the Netsec lab)

 

1. Create an App Gateway with a HTTP listener GCPlistener.
   
2. Add back-end host: GCPbackendpool (Target type: insert GCP <appUrl>)
   
3. Add a rule to route access from the HTTP listener GCPlistener to the GCP backend target GCPbackend
   
4. Confirm access to Coffeeshop app via App Gateway using App Gateway Public IP.
   

 

(If you get a Bad Gateway error, ensure the probe test is successful and the back-end setting has the right path to your app URI)

 

 

Restrict access to Coffeshop application to App Gateway public IP only (Step 3)

 

 

You can control your ingress traffic to your application. You can use the App Engine Firewall in GCP to restrict access to your apps. Open the firewall rules in the Google Cloud Console and you'll see a default rule that allows all traffic to your app.

 

• Add a new rule to allow only traffic from the public IP address from your App Gateway
  
• Then, update the default rule to Deny all traffic.
  

 

 

 

 

• Confirm that access using the original URL is now denied and app is only accessible via the App Gateway Public IP address.
   
  
  

Test for SQL injection prevention with Azure WAF. (Step 4)

 

 

Now that we have access to the application through the App Gateway, we can attempt to login with our SQL injection query.

 

Login with username “test” and password “test” and confirm a successful login access. (This is a user in the users.sql database that was imported.)

 

Now log out and refresh on the page. Attempt to use the injection query “ ' OR 1=1-- ” for both username and password. Confirm access denied by App Gateway WAF.

 

 

 

Test for Cross Site scripting attack

 

 

You can also try other attacks such as injecting the following script in the filter box

 

 

 

<script>alert("You are being attacked")</script>

 

 

 

 

 

 

This should give a denied access page just like the case for the SQLi above. (If access is not restricted, you should confirm that your Policy is in Prevention mode)

 

You can further test and permit direct access in the GCP firewall and then test again. This time, the XSS attack should be successful, and a JavaScript alert shown as below.

 

 

 

 

 

 

Click OK and click on “Recreate table” to rebuild your coffee order table.

 

 

 

Log review

 

The images below show the logging information about the attacks we have just carried out including their signature IDs. You can observe the prevention action in the message column, pattern match, the source request uri among others

 

 

 

 

 

 

Let's look at the XSS attack. We can see the signature ID in ruleId_s , action_s which shows the match action and other details messages.

 

 

 

 

In conclusion, you can use Azure Web Application Firewall to protect workloads in non-Azure cloud environment and apply existing security benchmarks to ensure your applications are protected from illegitimate access based on predefined compliance and security strategy in your organization. You can perform a similar proof of concept with Amazon Web Services by following instructions in the protect workloads in AWS blog.

At the end of this exercise, do not forget to disable the App Engine and SQL instances to manage the cost associated with this deployment tasks.

 

Continue reading...