Web cache deception alert triggered when testing a request that requires bearer token authorization

Describe the bug A clear and concise description of what the bug is. In a case when sending a request that requires a bearer token based authorization, a 401 response would commonly be returned in case of an invalid or non-existent token. When running a web cache deception scan on such an endpoint, the ZAP tool triggers an alert even when receiving a 401 response.

The cause of the 401 response is because the web cache deception plugin does not pass the required bearer token in the Authorization header (Bearer null).

To Reproduce Steps to reproduce the behavior: Prerequisite: Have a web app that integrates with an API that requires a bearer token based authorization and provides a login page.

1. Open the ZAP tool and click on Manual Explore.
2. Enter the URL of the web app.
3. Click Launch Browser
4. Login with the necessary credentials.
5. Once logged in, click on Active scan in the ZAP HUD.
6. Wait for the scan to complete.
7. Look for Web cache deception alerts.
8. Open the entry and view the request and response payloads. The request payload will have Bearer null for the Authorization header. The response will be 401.

Expected behavior If ZAP is unable to access a resource without authorization, then a web cache deception alert must not be triggered for that resource.

Screenshots If applicable, add screenshots to help explain your problem.

Software versions

• ZAP: 2.11.1
• Add-on: N/A
• OS: Windows 10
• Java: openjdk version “11.0.12”
• Browser: firefox 96

Errors from the zap.log file N/A

Additional context We use Auth0 as an authentication provider. Our frontend web app authenticates the user with Auth0 when logging in. Auth0 provides the bearer token to our web app when the user successfully authenticates. This bearer token is then passed to the backend API (which is being tested by ZAP here) to determine whether the user is authorized to access any API resource. However, ZAP sends Bearer null when testing for web cache deception which results in the below exchange with the API application.

Sample request as sent by ZAP for this scan:

GET https://REDACTED/api HTTP/1.1
Host: REDACTED
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:95.0) Gecko/20100101 Firefox/95.0
Accept: application/json, text/plain, */*
Accept-Language: en-US,en;q=0.5
Authorization: Bearer null
Origin: https://REDACTED
Connection: keep-alive
Referer: https://REDACTED/
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
Content-Length: 0

Sample response for the above request:

HTTP/1.1 401
Date: Wed, 12 Jan 2022 13:52:56 GMT
Content-Type: application/json
Connection: keep-alive
Server: nginx/1.19.7
Vary: Origin
Vary: Access-Control-Request-Method
Vary: Access-Control-Request-Headers
WWW-Authenticate: Bearer error="Invalid access token"
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
X-Frame-Options: DENY
X-Frame-Options: SAMEORIGIN

{"timestamp":"2022-01-12T13:52:55.842+00:00","status":401,"error":"Unauthorized","message":"","path":"/"}

This triggers a web cache deception alert.

Would you like to help fix this issue? Just say if you’d like to try and help fix this issue. We’ll provide any advice and guidance you need.

[bettercalln1ck]

Sure, I will look into it.

[kingthorin]

Ping @bettercalln1ck 😉