Jump to content
  • Triaging WAF Violations with Temporary Allowances

    Rick Davis
    • Validation Status: Validated
      Summary: ​​​​​​​When securing applications with a Web Application Firewall (WAF), issues may arise that require remediation. This article explains how to implement a process for managing temporary allowances while your team addresses these issues. This approach ensures tracking and auditing of exceptions, delegation, and review and removal of allowances when they are no longer needed.
      Has Video?: No

    When securing applications with a Web Application Firewall (WAF), issues may arise that require remediation. This article explains how to implement a process for managing temporary allowances while your team addresses these issues. This approach ensures tracking and auditing of exceptions, delegation, and review and removal of allowances when they are no longer needed.

    The process:

    1. Identify the Issue: Review the logs to pinpoint the specific resource and violation.
    2. Investigate: Understand the root cause. 
    3. Temporary Allowance – It may be necessary to squelch the logging or maintain application functionality for the purpose of providing time for developers to update their code. 
      • Add the impacted URL to an exception list and set a tracking identifier for monitoring and removing the temporary allowance.
      • Configure the WAF to allow the entries in the temporary exceptions list to bypass security processing.
    4. Update Code: Modify the application code to comply with security standards.
    5. Temporary Allowance Review – Periodically monitor for the remediated code and remove the temporary allowance by removing the URL from the exception list.

    *Temporary allowances may be necessary earlier in the process to stop application disruptions or to reduce logging of discovered issues. By enabling exceptions, organizations can maintain operational continuity while investigating root causes and devising permanent solutions.


    Temporary Allowance Table

    By using a list of exceptions, specific requests which require temporarily bypassing WAF processing can be handled precisely, minimizing the risk of exposing the entire application to potential threats. This targeted approach ensures that only the necessary traffic is bypassed, maintaining overall security while addressing specific needs. Additionally, it allows for better tracking and auditing of these exceptions, ensuring that they are reviewed and removed when no longer needed.

    | Index | URL Pattern       | Comment                             |
    | 1     | example.com/login | Ticket: ABC-123, Expire: 2024-06-30 |
    | 2     | /admin            | Ticket: DEF-456, Expire: 2024-07-15 |
    | 3     | mqtt.example.com  | Ticket: GHI-789, Expire: 2024-08-07 |

    Including a Jira ticket number or another form of development tracking identifier as a comment to the temporary exception provides a clear link between the security exception and the corresponding development task, enabling seamless collaboration between security and development teams and facilitating better coordination and prioritization of efforts. Additionally, specifying an expiration date within the comment ensures transparency and accountability, indicating when the exception should be reviewed or removed to maintain security hygiene and mitigate potential risks effectively.

    add patset temp_exceptions
    bind policy patset temp_exceptions "example.com/login" -comment "Ticket: ABC-123, Expire: 2024-06-30"
    bind policy patset temp_exceptions "/admin" -comment "Ticket: DEF-456, Expire: 2024-07-15"
    bind policy patset temp_exceptions "mqtt.example.com" -comment "Ticket: GHI-789, Expire: 2024-08-07"

    🖱️ In the NetScaler web interface: AppExpert > Pattern Sets

    📖 Reference: Configure a Pattern Set



    Optional: Delegated Authority

    Using a table for exceptions allows management delegation without compromising security settings or policies. By separately defining permissible exceptions, team members can manage these allowances without full access to WAF settings.  This approach ensures efficient workflow and accountability, maintaining the overall security posture while empowering operations teams.

    With the following configuration, read-only users assigned the "Edit_Temp_Exceptions" command policy will be authorized to execute commands specifically for adding and removing entries in the "temp_exceptions" pattern set (table), ensuring controlled access to this aspect of NetScaler configuration.

    add system cmdPolicy Edit_Temp_Exceptions ALLOW "^(bind|unbind)\s+patset\s+temp_exceptions.\s+.*$"

    🖱️ In the NetScaler web interface:  System > User Administration > Command Policies     

    📖 Reference: Custom Command Policies



    Temp Allowances using an AppExpert Policy

    The following AppExpert expression evaluates HTTP requests to check if they contain certain hostname and/or URL patterns associated with the list of temporary exceptions:


    Breaking it down:

      This condition checks if the concatenation of the requested resources name and folder location matches any of the specified patterns defined in the "temp_exceptions" table.  
      📖 Reference: HTTP_HOSTNAME_T
      This condition checks if the requested objects location contains any of the specified patterns defined in the "temp_exceptions" table.
    • Consider changing STARTSWITH_ANY to CONTAINS_ANY() or EQ_ANY() to get desired matching behavior. 

    🖱️ In the NetScaler web interface:  AppExpert > Expressions > Advanced Expressions

    📖 Reference: Configure advanced policy expressions



    Optional: Test this expression with the Expression Evaluator.

    🖱️ In the NetScaler web interface:  AppExpert | Tools > Advanced Expression Evaluator               

    Production-quality systems are even faster than the evaluation speed of 0.0001 milliseconds.


    Update the AppFirewall Policy

    Finally, prepend your AppExpert policy expression to the existing WAF expression so that requests for objects in the "temp_exception" list are excluded from security enforcement:

    set appfw policy <name> "temp_exception.NOT && <existing rule>"

    Breaking it down:

    • temp_exception.NOT: This named entity is negated with .NOT so that it returns FALSE instead of TRUE when matching patterns defined in the "temp_exception" pattern set table.  When the condition evaluates to FALSE, the AppFW policy will not be applied to the incoming request.
    • &&: This is the logical AND operator, meaning both conditions must be true for the overall expression to evaluate True and enforce the associated security rules.
    • <existing_rule>: Refers to the condition used prior to the addition of the exceptions table.  This may be any AppExpert expression including but not limited to: HTTP.REQ.IS_VALID, or HTTP.REQ.HOSTNAME.DOMAIN.EQ("example.com")

     🖱️ In the NetScaler web interface:  Security > NetScaler Web App Firewall > Policies > Firewall

    📖 Reference: Creating and configuring Web App Firewall policies


    This appfw policy rule verifies that incoming HTTP requests are a policy match and not listed as a temporary exception. When both conditions are met, the expression evaluates to true, indicating that the request should proceed according to the defined application firewall policy it applies to.

    Periodically check for the remediated code and remove the resource location from the temporary allowance table to reinstate the security enforcement.


    User Feedback

    Recommended Comments

    There are no comments to display.

    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now

  • Create New...