Neelam Pawar
Google Cloud - Community
7 min readJun 6, 2022

--

Tutorial 3: Setup Web Application Security Protection and Detection Lab in Google Cloud — Vulnerability Exploitation Playbook

This lab cover total 4 blogs, Below are links for reference

Part-1: WAF tuning

Part-2: Reconnaissance Playbook

Part-3: Vulnerability Exploitation(This Blog)

Part-4: Data Disclosure and Exfiltration

Vulnerability Exploitation playbook is third in the four-part tutorial series for the Google cloud WAF protection and detection lab. The purpose of the Google cloud WAF security protection lab is to demonstrate Cloud armor WAF’s capabilities in identifying and protecting against suspicious activities and potential attacks against your web applications. This playbook explains how to test Cloud Armor WAF’s protections against a Cross Site Scripting (XSS) attack .

In this tutorial you will:

  1. Simulate Cross Site Scripting (XSS) attack against the target OWASP Juice Shop application directly and then attack the same instance of the web application Protected through Cloud armor
  • Inject a proof of concept (POC) XSS payload in the target OWASP Juice Shop application directly and then through Cloud Armor WAF

2. Observe the difference in the web application behavior in the two scenarios

3. Review the summarized logs in the cloud armor WAF and security policy logs

Configuring Burp Suite and Firefox

To inject the POC XSS exploit code in the OWASP Juice Shop application, we will connect to the Kali VM . Once connected, we will use Burp Suite (Community Edition), a powerful web application security research and analysis tool which is bundled in the Kali Linux distro. In this playbook, we will be using Burp Suite to inspect application requests and responses to understand what happens when injecting the POC XSS payload in the target web application is different scenarios.

Burp Suite works as a client-side proxy and your web browser should point to Burp’s Proxy Listener so, it can intercept requests and responses.

  1. Sign into the Kali VM using your credentials
  2. Launch the web browser and ensure that you are able to access the OWASP Juice Shop website directly with URL http://<<App engine Public IP>>:3000 and also through cloud armor WAF policy with URL https://<<Public IP of global load balancer>>.nip.io
  3. Launch Burp Suite by clicking on Applications on the top left and then click Web Application Analysis → burpsuite

Figure 1 — Launch Burp Suite

4. In the “Burp Suite Community Edition” window, accept the defaults (Temporary project → Use Burp defaults → Start Burp) to start Burp Suite

Figure 2 — Launch Burp Suite

5. When open, click on Target → Scope tabs and then add the 2 URLs for the Juice Shop website in the “Include in scope” box. This will setup Burp to only capture requests and responses for these specific websites while excluding traffic going to other destinations

a. http://<<App engine Public IP>>:3000(without WAF)

b. https://<<Public IP of global load balancer>>.nip.io ( With WAF)

6. The exclusions in the “Exclude from scope” are optional and will help reduce noise in the capture

a. http://<<App engine Public IP>>:3000/socket.io/

b. https://<<Public IP of global load balancer>>.nip.io/socket.io/

! IMPORTANT: For the scenarios demonstrated in this document, OWASP Juice Shop application was running on HTTP port 3000.

7. Then click on the Proxy → Options tabs and verify that Burp Proxy is running on 127.0.0.1:8080

8. Click on the Intercept tab and turn off intercept

9. Launch Firefox browser on the Kali Linux VM and update the proxy settings to use Burp proxy listener under Menu → Preferences → Network Proxy → Settings → Manual proxy configuration and point it to 127.0.0.1:8080

Vulnerability Exploitation

After collecting and analyzing web application specific data from the various recon activities to detect vulnerabilities, an attacker can then successfully exploit the identified vulnerabilities with the intent to compromise a user or the application itself to elevate privileges. In this playbook, we will simulate a Cross Site Scripting (XSS) attack against the target application using a proof of concept (POC) exploit payload.

Performing Cross Site Scripting (XSS) Attack against the Target Web Application

In this tutorial, you will perform a Server Side Cross Site Scripting (XSS) attack against the OWASP Juice Shop application two times.

  1. Scenario 1: Injecting the XSS payload in the target web application directly
  2. Scenario 2: Injecting the same XSS payload in the same target web application protected by Google Cloud Armor WAF

Scenario 1: Injecting XSS payload when going to the OWASP Juice Shop Application directly

Sign into the Kali VM using your credentials

Using Firefox, browse directly to the Juice Shop site by going to

http://<<App engine Public IP>>:3000:3000/

3. In Burp Suite, check the Proxy → HTTP history tab for request and response data for this website

4. Click the website menu icon on the top left and then click on Customer Feedback

5. In the Comment box of the Customer Feedback form, copy/paste the POC code
<iframe src=”x-javascript&colon;alert(`xss`)”>

6. Give a Rating, respond to the CAPTCHA challenge and click Submit

7.Upon clicking Submit, you should see a Thank you message

8. Switching back to Burp, we can see the following request and response for the Feedback that we submitted in Step 4 above

Figure 1 — Request with XSS Payload in Burp Suite

Figure 2 — Successful Response from Juice Shop in Burp Suite

9. The 201 Created response code with a successful status tells us that the malicious POC XSS payload was stored successfully by the web application.

Scenario 2: Injecting XSS payload when going to the OWASP Juice Shop Application protected by Cloud armor

We will now attempt to perform the injection of the same XSS payload in the Customer Feedback form on the Juice Shop website Protected by Cloud armor.

  1. On Kali VM, launch a new instance of Firefox and browse to the Juice Shop website published through Load balancer and protected with Cloud armor security by going to https://<<Public IP of global loadbalancer>>.nip.io
  2. In Burp Suite, check the Proxy → HTTP history tab for the request and response data for this website
  3. In the browser window, click on the website menu icon on the top left and then click on Customer Feedback
  4. In the Comment box of the Customer Feedback form, copy/paste the POC code
    <iframe src=”x-javascript&colon;alert(`xss`)”>
  5. Give a Rating, respond to the CAPTCHA challenge and click Submit

6. Upon clicking Submit, you will observe that the thank you message does not show up this time

  • Tip: The web application does not provide an error response in this scenario. This is due to the behavior of the Juice Shop application

7. Switching back to Burp, we can see the following request and response for the Feedback that we submitted in Step 5 above

Figure 1–403 Forbidden Response from Cloud armor security policy in Burp Suite

8. The 403 Forbidden response from the Https load balancer tells us that the request with the POC XSS payload was blocked by Cloud armor security Policy

Understanding What Happened

Upon reviewing the HTTP requests and responses for the two attempts to inject POC XSS payload to the same instance of the Juice Shop application, we see the pattern as shown in the below table. This clearly indicates that the malicious XSS payload which could otherwise be stored in the application is not allowed through by Cloud armor security Policy

Key Takeaway

Cross Site Scripting (XSS) is one of the most common type of application security vulnerability and an external adversary can easily exploit a vulnerable application to compromise the application and its users to elevate their privileges.

For web applications secured with it, Google cloud armor can protect against XSS attacks by detecting and blocking XSS payload at the network edge, with its out of the box ruleset.

Next Step

Test Cloud armor capabilities for SQL injection and cross site scripting .

Part-4: Data Disclosure and Exfiltration

--

--