On the web, the go to method for maintaining state in the stateless HTTP protocol is cookies. The .NET framework included a way of putting cookies into the URL for clients who couldn't support cookies. This had the view of S(aaaaaaaaaaaaaaaaaaaaaaaa) in part of the path of the URL.
Historically, this has been real bad for WAFs and session related issues such as session fixation, session hijacking and more. The author includes a link to various posts about previous issues. Due to these security concerns, the feature was removed from the .NET core in newer versions.
From the WAF bypasses the author posted on Twitter, it's clear that putting sessions into the middle of a URL causes weird problems. While testing new WAF bypass techniques, they noticed two weird anomalies.
The cookieless feature could circumvent the protected directories and URL filters in IIS. Normally, paths in these locations would be blocked. However, by including two sessions in the URL, the validation was bypassed. Why does this occur?
In the rewrite portion of the cookieless paths in the .NET framework, it appears to only perform the removal once for verification. Then, during the resolution process, it will remove the second session and allow the user to access the path. At least, this is what it seems like but it's not explained very well.
In IIS, there are application pools. Some paths could use one pool while others would use another. By using the double session path from above, it is possible to create pool confusion. This can lead to a privilege escalation, given the right scenario.
Interesting bug! It turns out that string parsing is very hard to do correctly. Double adding a value is something I'll be testing for in the future.