mod2lab3

docs/waf2025/module2/lab2.rst

@@ -3,6 +3,9 @@ Lab 2 – Discover the OWASP Dashboard
 Objective
 ~~~~~~~~~~~~~~~~
 
+**BIG-IP 17.1 includes updates to the OWASP Compliance Dashboard bringing the list of controls in line with the 2021 top 10 list.**
+
+
 - Open up and view the OWASP Compliance Dashboard
 
 - Apply some basic attack signatures using the Dashboard

docs/waf2025/module2/lab3.rst

@@ -1,91 +1,75 @@
-Lab 3 – Refine your security posture using the OWASP Dashboard
----------------------------------------------------------------
+Lab 3 – Test your Policy against the Juice Shop
+-----------------------------------------------
 Objective
 ~~~~~~~~~~~~~~~~
+Revist the Juice Shop to test what the OWASP Compliance Dashboard has done so far.
 
-- Continue to apply protections to your security policy
 
-- Protect a logon page
 
-- Assess the rest of the dashbard to apply more protections and document other best practices in your policy
+Cross Site Scripting (XSS)
+~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Task – We will continue applying protections while working down the Dashboard
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+This hack we will cause a simple reflected XSS attack on the Juice Shop application by compromising a parameter value in the URL. First go to **Account** in the upper right corner, then to **Orders and Payment**, select **Order History**.
 
-#. On the Main tab, click **Security > Overview > OWASP Compliance**. Click on the expand arrow next to A1 Injection.  At the bottom you can see the missing piece for 100% Injection protection is applying **Evasion Techniques**.  
+.. image:: ../images/mod1lab2-xss-orderhistory.png
 
-#. At this point clicking on the checkmark and applying would implement Evasion Technique protection.  You are welcome to do this from the dashboard, but let's see how the dashboard interacts with a manual change to the policy.  Perform the following steps to apply in the policy.
+Click on the truck. This will take you to an expected delivery page with search results. Carefully look at the URI and notice that it is not encoded or using a trusted html link for the parameter value. 
 
-    - Go to **Security -> Application Security -> Policy Building -> Learning and Blocking Settings**
-    - Click and expand the section titled **Evasion Technique detected** 
-    - Click the checkbox for **Enable** all
-    - Press **Save** at the bottom of that screen
-    - Press **Apply Policy** button at the top right corner of your screen
 
-    .. image:: ../images/evasiontechniques.png
+.. image:: ../images/mod1lab2-xss-uricompare.png
 
-#. Go back to the Dashboard.  Click **Security > Overview > OWASP Compliance**.  You now see you are 100% protected against A1 Injection.  Now expand **A2 Broken Authentication**.  You can see with some of the default protections, and the previous attack signatures we applied are providing some protections.  The signatures we applied previously protect against some auth attacks, and cookie tampering protection is on by default when applying a base policy.
+Paste the following code after **yourhost.access.udf.f5.com/#/track-result?id=** in the URI. 
 
-    - To the right of **Session Highjacking Protection** click on the **Enforce** checkmark.  You will now see the potential protections percentage for Broken Authentication increase. Press the blue **Review & Update** button below.  Then the  **Save & Apply Policy** button.
+.. code-block:: none
+    
+    <iframe src="javascript:alert(`data all over this screen that wasnt planned`)">
 
-    .. Note:: Unfortunately protecting against all of the OWASP top 10 is not always as easy as applying attack signatures. In some cases you need to apply more app specific protections such as a logon page.  If your application does not have a logon page, this would be a good example of when to select the no symbol (we call it the ghostbuster symbol) button, which will ignore the requirement since it does not apply.
+The full URL will look like this after encoding is done by the browser. Dont paste this code below into the browser. This is meant for reference since you will have a different host. 
 
-#. The following steps will declare our login page for the Juice Shop app, then we will apply more A2 Broken Authenticaton protections against it.
+.. code-block:: none
+    
+    https://ea06dc66-bfd7-4aa2-a99c-72137fd3ea1a.access.udf.f5.com/#/track-result?id=%3Ciframe%20src%3D%22javascript:alert(%60data%20all%20over%20this%20screen%20that%20wasnt%20planned%60)%22%3E
 
-    - Under A2 click the link named **Not Fulfilled** next to Login Enforcement.  This is just a link/shortcut to the login page settings.  
+The result should now be a response page from the BIG-IP
 
-        .. image:: ../images/loginenforcement.png
+.. image:: ../images/xss_test.png
 
-    - This opens a new tab in the policy where you declare the info for your login page.  Press **Create** on the top right corner of the page.  
-    - In the login URL field enter ``/#/login``
-    - In **Authentication Type** select **HTML Form**
-    - Type ``email`` in the **Username Parameter Name**
-    - Type ``password`` in the **Password Parameter Name**
-    - Type ``Invalid`` in the **A string that should NOT appear in the response** field
 
-        .. image:: ../images/loginform.png
 
-    .. Note:: You can identify the strings and parameters listed above by either getting info from the application developers or by using tools built into your own browser.  Here is a method from one of our F5 videos, the link brings you right to that discovery method https://youtu.be/YqswibSgMyk?t=178
 
-    - Click the **Create** button at the bottom of the page.  
 
-#. Now we will apply brute force protection to the login page we created
+SQL Injection
+~~~~~~~~~~~~~
 
-    - Go to **Security -> Application Security -> Brute Force Attack Prevention**
-    - Click **Create** in the top right corner
-    - On **Login Page** select the login page we just created ``/#/login``
-    - Here you can view the mitigatons and thresholds for Brute Force Protection.  For the lab, we will leave the settings at their defaults, and press the **Create** button below.
-    - Press the **Apply Policy** button in the top right corner.
-    - You can close that tab and now go back to your other OWASP tab and refresh the page.
+Paste the following path in your browser's location bar after the FQDN of the Juice Shop:
 
-    .. Note:: Notice we are not at 100% completion for A2 risks.  We will return to this in the next section as the configurations are a little more advanced.  
 
-#. Back on the OWASP Dashboard, path **Security -> Overview -> OWASP Compliance**. Click on the expand arrow next to **A3 Sensitive Data Exposure** and notice that previous protections we put in place satisfied many of the requirements.  Applying DataGuard will inspect outbound traffic for any sensitive information being sent from your application.  The power of our full proxy archetecture makes this protection possible.
+.. code-block:: none
+   
+    /rest/products/search?q=qwert%27%29%29%20UNION%20SELECT%20id%2C%20email%2C%20password%2C%20%274%27%2C%20%275%27%2C%20%276%27%2C%20%277%27%2C%20%278%27%2C%20%279%27%20FROM%20Users--
 
-    - To the right of **DataGuard** click on the **Enforce** checkmark.  You will now see the potential protections increase to 100%.  Press the blue **Review & Update** button below.  Then the  **Save & Apply Policy** button.
+The location bar should look something like (don't copy this since your FQDN will be different):
 
-    .. Note:: The default settings of Data Guard will prevent the transmission of number sequences matching credit card and social security numbers.  This can be customized to match patterns sensitive within your organization, but is out of scope for this level of class.  To see these settings though, go to menu **Security -> Application Security -> Data Guard**
+.. code-block:: none
 
-#. Back on the OWASP Dashboard, path **Security -> Overview -> OWASP Compliance**. At this time we are going to skip a few of the next controls, as their configuration is a little more advanced.  Click on the expand arrow next to **A6 Security Misconfiguration**.
+    https://ba3eff45-2f23-49ab-8122-2e3bdc1ed9ad.access.udf.f5.com/rest/products/search?q=qwert%27%29%29%20UNION%20SELECT%20id%2C%20email%2C%20password%2C%20%274%27%2C%20%275%27%2C%20%276%27%2C%20%277%27%2C%20%278%27%2C%20%279%27%20FROM%20Users--
 
-    .. Note:: The catagories A6, A9, and the 10th (notice how we refuse to write that one out) cover practices that require controls outside the scope of a WAF. The administrator will need to manually evaluate whether these conditions are being met for this application.
+The result should now be a response page from the BIG-IP.
 
-    - In the A6 list, these may be processes you currently run, or they can be left as a reminder that you are not currently applying these controls. Click the **?** next to each best practice to see a more detailed description.
-    - Click on the **checkmark** for all processes that your organization is currently following for the application.  You can also click the **No/Ghostbuster** symbol here if the condition is not met.
-    - Below is an example, but you may complete this any way you choose.
+.. image:: ../images/sql_test.png
 
-        .. image:: ../images/securitymisconfig1.png
 
-        .. Note:: In this example, we have marked that we are performing application and vulnerability scanning.  We have chosen to ignore the app and system patching (An example why would be a legacy system or app that no longer recieves patching).  In this instance, we want to ignore that requirement as it is not applicable to the application. In our example, App System hardening is a practice that we have not yet implemented, so we will leave this unsatisfied until that is complete. 
 
-#. On the OWASP Dashboard, path **Security -> Overview -> OWASP Compliance**. Click on the expand arrow next to **A8 Insecure Deserialization**.  You can see we are already at 100% coverage for this risk.  Previously applied signatures that covered other risks are also protecting us here.  You can click around in this area to see more info on the risks and each signature set.  
 
-#. On the OWASP Dashboard, path **Security -> Overview -> OWASP Compliance**. Click on the expand arrow next to **A9 Using Components with Known Vulnerabilities**.  While the risk is different than A6, the best practices that best mitigate this risk are the same.  This can give more validity to start applying these practices in your process.
+Unauthorized File Access
+~~~~~~~~~~~~~~~~~~~~~~~~
 
-#. On the OWASP Dashboard, path **Security -> Overview -> OWASP Compliance**. Click on the expand arrow next to the 10th risk **Insufficient Logging & Monitoring**.  This will be another manual risk protection.  Since logging profiles are added in the virtual server confiuration the dashboard cannot read if there is logging in the WAF policy.  The good news is in we already did this work.  If you remember we added a logging profile right after we built our initial configuration using the guided configuration.  
+Navigate to /encryptionkeys to expose an unwanted directory listing
 
-    - Click on the **Checkmark** next to **Log Illegal Requests**.  Since we already added this type of logging to our virtual server.  
-    - We do not and never will have a remote logging server or SIEM in this environemnt, so I will choose to ignore it by clicking our **No/Ghostbuster Symbol**
-    - Click **Review & Update** button below and then **Save & Apply**.
+.. image:: ../images/juice_shop_encryptionkeys.png
 
-#. Way to go!  You now have a WAF policy that is protecting against a significant portion of the OWASP Top 10.
+Click on the file ``premium.key`` and attempt to download it.
+
+.. image:: ../images/files_test.png
+
+Notice that while you can get to **/encryptionkeys**, an attempt to download the file is now blocked by BIG-IP Advanced WAF.