Client-side desync attacks

Hello @SecGlad ,

I understand that you would like to know if Azure WAF prevents from Client-side desync attacks (CSD) and if yes, you would like to know which OWASP ruleset and ruleID prevents this.

I read a bit about Client-side desync attack and found that CSD attack involves two key techniques: JavaScript resource poisoning via Host-header redirects and using the HEAD method to splice together a response with harmful HTML.

On checking the Azure WAF managed ruleset, I found some rules which detects XSS vectors making use of javascript uri and tags and also rules for not accepting GET or HEAD requests with bodies from client as below:

Refer: https://video2.skills-academy.com/en-us/azure/web-application-firewall/ag/application-gateway-crs-rulegroups-rules?tabs=drs21#drs941-21

https://video2.skills-academy.com/en-us/azure/web-application-firewall/afds/waf-front-door-drs?tabs=drs21#drs941-21

https://github.com/coreruleset/coreruleset/blob/v4.0/dev/rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf#L156

https://video2.skills-academy.com/en-us/azure/web-application-firewall/ag/application-gateway-crs-rulegroups-rules?tabs=drs21#drs920-21

https://video2.skills-academy.com/en-us/azure/web-application-firewall/afds/waf-front-door-drs?tabs=drs21#drs920-21

https://github.com/coreruleset/coreruleset/blob/v4.0/dev/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf#L157C6-L157C49

However, there is no direct rule mentioning about CSD.

So, I discussed this with the Azure WAF Product Group team, and below is their response:

Our WAF is able to provide only limited protection against client-side desync attacks. Our WAF rules may be able to detect some of the XSS attack being smuggled within the request, but we won’t be able to stop the desync attack itself.

However, there is a way to use custom rules to help block this type of exploit. Please see the below details: 

We can offer some protection using custom rules. This attack relies on the application server ignoring the Content-Length header in the request and sending a response without reading the request body. The most likely case for this to happen is with requests sent to static assets like /favicon.ico or a javascript, css or image files. What our customers can do is to create a custom rule that will block the request if the request method to a static asset is anything other than GET or HEAD. How a customer chooses to identify static assets depends on their application. They can choose to do this with a requestUri EndsWith condition or any other way it works for them. We would recommend a custom rule that looks something like this:

{
        "name": "StaticAssets",
        "priority": 5,
        "ruleType": "MatchRule",
        "action": "Block",
        "matchConditions": [
          {
            "matchVariables": [
              {
                "variableName": "RequestUri"
              }
            ],
            "operator": "EndsWith",
            "negationConditon": false,
            "matchValues": [
              ".ico",
              ".css",
              ".js",
              ".jpeg",
              ".jpg",
              ".png"
            ],
            "transforms": []
          },
          {
            "matchVariables": [
              {
                "variableName": "RequestMethod"
              }
            ],
            "operator": "Equal",
            "negationConditon": true,
            "matchValues": [
              "GET",
              "HEAD"
            ],
            "transforms": []
          }
        ],
        "skippedManagedRuleSets": [],
        "state": "Enabled"
      }

Please note that the second condition has negationCondition set to true. The above rule will deny a request to any of those file extensions (static assets) if the request method is not GET or HEAD. If the attacker sends a GET or HEAD request with request body, rule id 920170 will block the request with the message "GET or HEAD Request with Body Content". This is a workaround but can be effective, nonetheless.

Another option to protect against Client-side desync attacks, would be to go for a third-party web application firewall offering available in the Azure Marketplace.

Please refer the below blog on "Client-side attacks: Why you’re vulnerable and how Azure Marketplace can help" written by Microsoft PG for more information:

https://techcommunity.microsoft.com/t5/marketplace-blog-for-partners/client-side-attacks-why-you-re-vulnerable-and-how-azure/ba-p/2601058

Kindly let us know if the above helps or you need further assistance on this issue.

Please "Accept the answer" if the information helped you. This will help us and others in the community as well.