Trustwave's 2024 Financial Services Threat Reports Highlight Alarming Trends in Insider Threats & Phishing-as-a-Service. Learn More
Get access to immediate incident response assistance.
Get access to immediate incident response assistance.
Trustwave's 2024 Financial Services Threat Reports Highlight Alarming Trends in Insider Threats & Phishing-as-a-Service. Learn More
In my previous post I described a potential problem with web application firewalls protecting web applications. After getting your attention it is only fair to follow up with a solution.
Firstly, the problem is not as serious as it may appear at the first glance. Secondly, the solution, in the cases when the rules might be affected, is pretty straightforward. It's a simple matter of rewriting rules to avoid the slippery path (or not writing them to be vulnerable to evasion in the first place). You should have in mind, however, that the most important step in dealing with impedance mismatch is to understand the problem exists. Everything else is just a technicality.
It turns out the impedance mismatch problem typically affects only those rules that are designed to focus on named parameters and cookies. This is a feature that is not used frequently. For example, the Core Rules project does not need to do this because it is generic in nature. It does not care what parameters are called. What it really cares is the payload (either parameter names or values) and this is where inspection takes place - irrespective of impedance mismatch.
If you do need to address problems that manifest only with certain named parameters then it's probably because you want to deal with a particular problem in the application you are using. Which means you have a context in which you work and you can take simple precautions. You should always try to avoid using the named-variable approach (e.g. ARGS:parameter) and address all variables instead (i.e. ARGS). My favourite has always been having a rule that warns about parameters with strange characters in them (a space would be a strange parameter in this context).
SecRule ARGS_NAMES "!^[][a-zA-Z0-9_.]+$"
This rule will not work equally well for all environments. You should customise it to better suit your circumstances. Strictly speaking it is not designed to deal with impedance mismatch but to unearth unusual requests. If there are unusual characters used in parameter names (and this is not by design in the application) you will want to know about that so you can investigate.
As far as ModSecurity is concerned, we will pro-actively research other web application environments and document any issues we discover.
Trustwave is a globally recognized cybersecurity leader that reduces cyber risk and fortifies organizations against disruptive and damaging cyber threats. Our comprehensive offensive and defensive cybersecurity portfolio detects what others cannot, responds with greater speed and effectiveness, optimizes client investment, and improves security resilience. Learn more about us.
Copyright © 2024 Trustwave Holdings, Inc. All rights reserved.