Exercise 2.1: Protocol Compliance¶

Objective¶

• Attach the security policy to the appropriate virtual server.
• Validate that the security policy is working correctly.
• Implement HTTP Protocol Compliancy checks
• Explore Learning and Blocking
• Get familiar with ASM Event Logs
• Estimated time for completion 45 minutes.

Apply Security Policy¶

1. Remove the previously created DoS profile and bot logging profile.
2. Enable the lab1_webgoat_waf Security Policy

Your virtual should look like this

Burp’ing the App¶

In this section we are going to use the free/community version of an excellent DAST tool; Burp. Unfortunately, the free version does not actually allow DAST but it is still an excellent tool for packet crafting and that’s exactly how we are going to use it. We will be manually sending two different attack types to demonstrate the protocol compliance features of ASM.

HTTP Compliancy Check - Enforce Host Header¶

1. Open Burp by clicking the icon in the system tray at the top of the screen. (If it offers an update, please decline)

2. This will be a temporary project so click next to proceed and choose “Use Burp Defaults” on the next screen.
3. Click Start Burp and navigate to the Repeater tab once opened.
4. Under the Request tab paste in the following http request, remove any whitespace, or use the text version on the desktop, and click Go.

Attack 1: No Host Header - Run this 10 times.

POST https://webgoat.f5demo.com/WebGoat/login HTTP/1.1
User-Agent: R2D2
Pragma: no-cache
Cache-Control: no-cache
Content-Type: application/x-www-form-urlencoded
Content-Length: 38

username=f5student&password=f5DEMOs4u!

5. A popup will appear asking for target details. Fill out the form as shown below.

Request and Response should look like this

6. Navigate to Security > Event Logs > Application > Requests and clear the illegal request filter. You should see these requests being logged as legal but you may want to implement policy per the “Good WAF Protection recommendations”, to not allow this since it is not RFC compliant HTTP/1.1

Learning and Blocking¶

The first place we always take a look when we want to implement a new control is under learning and blocking settings.

1. Navigate to Security > Application Security > Policy Building > Learning and Blocking Settings and look for HTTP Protocol Compliance failed

2. Notice the violation is set to learn only and is not enabled by default in a Rapid Deployment Policy. That is why the request was seen as legal and there was no alert in the event logs.
3. Since learning was on by default there must be a learning suggestion ready for us. Let’s go take a look.
4. We want to specifically find the learning suggestion for HTTP protocol compliance failed - HTTP Check: No Host header in HTTP/1.1 request
5. Navigate to Security > Application Security > Policy Building > Traffic Learning and click on the Magnifying Glass.

6. Under the Advanced Tab move the slider to the left so you can see alerts with a learning score of less than 5 and click Apply Filter

7. Note the action ASM is suggesting that you take - “Enable HTTP Check”

8. Click Accept Suggestion and then browse back to Security > Application Security > Policy Building > Learning and Blocking Settings > HTTP Protocol Compliance failed and notice that by accepting the learning suggestion ASM has now enabled the protection but it is still in learning mode so uncheck that manually.

9. Be sure you have clicked “Save” and Applied the Policy prior to proceeding.
10. Go back to Burp and run the attack again one or more times.

11. Browse to Security > Event Logs > Application > Requests on the BIG-IP GUI. Clear the Illegal Request option to view all requests received by the security policy. You should now see the alerts since we have enabled this compliancy check and turned off learning.

HTTP Compliancy Check - Bad Host Header Value¶

The Bad Host Header Value check is an HTTP Parser Attack and definitely something that should be implemented as part of Good WAF Security.

Risk: If we allow bad host header values they can be used to Fuzz web servers and gather system information. Successful exploitation of this attack could allow for the execution of XSS arbitrary code.

1. Navigate to Security > Application Security > Policy Building > Learning and Blocking Settings > HTTP Protocol Compliance failed and find Bad host header value Notice that by default this is also in learning mode but disabled by default in a Rapid Deployment Policy.

2. Uncheck the Learn box and Check the Enable box. Scroll up, click Save and Apply Policy.
3. Go back to Burp and under the Request tab paste in the following http request, remove any whitespace, or use the text version on the desktop, and click Go.

Attack 2: XSS in HOST Header

POST https://webgoat.f5demo.com/WebGoat/login HTTP/1.1
User-Agent: BB8
Pragma: no-cache
Cache-Control: no-cache
Content-Type: application/x-www-form-urlencoded
Content-Length: 38
Host: <script>alert(document.cookie);</script>

username=f5student&password=f5DEMOs4u!

4. Browse to Security > Event Logs > Application > Requests and review the alert for this attempted attack. Note the alert severity is much higher (4) for this attack type due to the risk it presents.

5. Click Export Request and review the detailed report. Notice the XSS alerts and how they are currently still in staging. We will cover this in the next module.

HTTP Compliancy Check - Multiple Host Headers¶

Description - Examines requests to ensure that they contain only a single “Host” header. This is an example of an HTTP Request Smuggling Attack

Risk - An attacker may try to evade security checks by confusing ASM and/or application servers as to which hostname is being accessed.

Example - The website may be accessed by non-browser clients attempting to bypass security gateways.

Order of Operations

1. Disable learning and Enable the Compliancy Check for Multiple Host Headers in learning and blocking settings.
2. Use BURP to perform the Attack

POST https://webgoat.f5demo.com/WebGoat/login HTTP/1.1
User-Agent: BB8
Pragma: no-cache
Cache-Control: no-cache
Content-Type: application/x-www-form-urlencoded
Content-Length: 38
Host: LordVader
Host: LukeSkywalker

username=f5student&password=f5DEMOs4u!

3. Review Event Logs to ensure the attack is being mitigated. Notice the alert level is lower for this attack type due to less risk than a potential XSS as seen in the previous exercise.

This concludes module 2