Session Management Response Identified

[Hector Luna]

Hi everyone,

I am having a bit of an issue with the Session Management Response Identified rule. For some reason, it is throwing warnings for incomplete URLs for things that have already been whitelisted.

For example:
https://some.url/path/to/resource

Will throw a warning.

https://some.url/path/to/resource/complete

Will not throw a warning because it is whitelisted.

This is happening while using this week's release while the issue isn't present in last week's release.

Has anything changed?
Thanks!

[Simon Bennetts]

Hiya,

Not that I'm aware of.

How are you denylisting the URLs?

Cheers,

Simon

[Hector Luna]

I use a filter in the automation script that looks similar to this:

- ruleId: 10112

ruleName: "Session Management Response Identified"

context: ""

newRisk: "False Positive"

parameter: "(?i)(?:parameterName1|parameterName2)"

parameterRegex: true

url: "https:\\/\\/some\\.url\\/(?:\

path\\/to\\/resource\\/complete\\/?param1\\=.*&param2\\=.*$|\

path\\/to\\/resource\\/some\\?list$)"

urlRegex: true

attack: ""

attackRegex: false

evidence: ""

evidenceRegex: false

That throws a warning using this week's release, but not while using last week's release.
https://some.url/path/to/resource

evidence: parameterName1

Thanks!

[Simon Bennetts]

I put your URL regex into the ZAP Regular Expression Tester and it did not match the URL.

I also tried https://regex101.com/ just to make sure and that was the same.

I did replace the "\\"s with "\".

So double check the regex, ideally with the ZAP Regex Tester.

Cheers,

Simon

[Hector Luna]

That is exactly the issue.

I do not address the incomplete URL directly. For instance, I never address https://some.url/path/to/resource directly. It is always something like https://some.url/path/to/resource/complete... 

Thanks!

[Hector Luna]

I mean, the issue is that it is throwing a warning for a URL that is not something I target.
The issue seems to have gone away as of D-2024-02-19, but it was present in D-2024-02-12.

Thanks!

[Hector Luna]

So after doing further investigation, it seems that this issue is not gone from this rule.
Not only that, but the rule seems to be reporting things wrong.

For instance, I have a request like this:
DELETE https://root.url/path/to/item/itemId/action/delete

But the rule is reporting on this:
https://root.url/path/to/item/itemId/action
Method: GET

So not only is the URL it reports on wrong, but it is also the wrong method.
The rule also seems to not care about whether or not some URL is excluded in the execution plan either, while other rules have no issues excluding the very same URL.

I will to use a version of ZAP where this was not an issue. I believe this was not a thing at the beginning of February and report on my findings.

[Simon Bennetts]

This problem will not be fixed ... unless you give us enough diagnostics for us to diagnose and fix it.

Your choice...

[Hector Luna]

Absolutely. I am working on other things at the moment, but will look into getting something more concrete and useful to get to the bottom of this issue as soon as possible.