Hi,
we've identified some unintended problematic code wrt to cookies, e.g. in https://github.com/OWASP/Benchmark/blob/b38d197949f775b3c165029bda9dc6bd890265fb/src/main/java/org/owasp/benchmark/testcode/BenchmarkTest01826.java#L37-L42
Going to a URL like https://localhost:8443/benchmark/crypto-02/BenchmarkTest01826;SameSite=None;?BenchmarkTest01826=SafeText injects SameSite=None into the cookie header. Much worse things are not possible since the URL can't contain newlines.
Now Tomcat is nice enough to mitigate this throwing an exception An invalid path [/benchmark/crypto-02/BenchmarkTest01826;foobar] was specified for this cookie. However, as far as I can tell there's no guarantees from the servlet specs that this happens and indeed when I run the benchmark with e.g. JBoss Wildfly, I get back a response with a bad cookie header. So in my opinion Tomcat's great security feature doesn't mean this isn't an application bug static tools should be flagging.
The fix would be to use getContextPath() which comes from configuration unlike attacker-controlled getRequestURI().
The call to setDomain() would be similarly problematic, except setting a bad Host header requires so much control over the HTTP user agent that I don't see scenarios where this would be exploitable in practice. So we're taking that as a challenge for our SAST to filter out :)
Hi,
we've identified some unintended problematic code wrt to cookies, e.g. in https://github.com/OWASP/Benchmark/blob/b38d197949f775b3c165029bda9dc6bd890265fb/src/main/java/org/owasp/benchmark/testcode/BenchmarkTest01826.java#L37-L42
Going to a URL like https://localhost:8443/benchmark/crypto-02/BenchmarkTest01826;SameSite=None;?BenchmarkTest01826=SafeText injects
SameSite=Noneinto the cookie header. Much worse things are not possible since the URL can't contain newlines.Now Tomcat is nice enough to mitigate this throwing an exception
An invalid path [/benchmark/crypto-02/BenchmarkTest01826;foobar] was specified for this cookie. However, as far as I can tell there's no guarantees from the servlet specs that this happens and indeed when I run the benchmark with e.g. JBoss Wildfly, I get back a response with a bad cookie header. So in my opinion Tomcat's great security feature doesn't mean this isn't an application bug static tools should be flagging.The fix would be to use
getContextPath()which comes from configuration unlike attacker-controlledgetRequestURI().The call to
setDomain()would be similarly problematic, except setting a badHostheader requires so much control over the HTTP user agent that I don't see scenarios where this would be exploitable in practice. So we're taking that as a challenge for our SAST to filter out :)