minvws
urls that redirect with a 'sessionID in the url' give cluttering in the objects list.
Describe the bug When scanning SSO portals the objects list gets cluttered by all the new sessions that are created.
To Reproduce Steps to reproduce the behavior:
- Perform scans against SSO portals.
- Check the objects list and observe that a lot of objects are created for all new sessions.
Expected behavior A clear and concise description of what you expected to happen.
Screenshots If applicable, add screenshots to help explain your problem.
OpenKAT version Note the release tag (and if possible: the installation method) here. If it concerns an in-development version, note the branch(es) and commit hash(es) here as well.
Desktop (please complete the following information if relevant):
- OS: [e.g. iOS]
- Browser: [e.g. chrome, safari]
- Version: [e.g. 22]
Additional context Add any other context about the problem here.
This behaviour exists because The initial login page of that SSO portal redirects to a new url with a temporary valid session in the url. By the time OpenKAT gets around to fetching that url, it does not have the associated cookies, or a timeout has triggered for the url to be invalid, which in turn prompts the server to redirect to a new url with a new freshly generated session token. There is currently no way to automatically detect this behaviour in OpenKAT, but more worrysome, its also hard for the user to find the original Url and set its indemnification to zero. Its also hard to delete the produced url's because we lack proper filtering / searching tools in the ooi-list.
Perhaps adding a cookie-jar and sessions to the downloader could work. Or we can detect these loops with a BIT and push the indemnification down to zero.
How about an ignore list on hostnames after a redirect detection? There is no way to bypass login url's? And a special entry to check the SSO-portals with certain boefjes the gather security info?
One potential solution could be to let KAT ignore all the GET- parameters in a request (everything after the ? in an URL). There can be arguments for/against this solution.
This could possibly be combined with a check for SSO/SAML portals by checking for those words in the hostname and/or paths. If those words are detected we could skip all parameters, this might also be user dependent and could be a toggle switch where the user can decide how these URLs would be parsed.
Another potential solution would be to do two requests when there are GET parameters, without a cookie jar, and replace the changes with an EPHEMERAL tag, like https://sso.yayaya.com/login?session_id={EPHEMERAL}&action=login
We will create a config on the location header bit that has a list of parameters to ignore. Rerun all bits should then fix the issue.
default configOOI for the bit should at least contain the following arguments:
-
session_id
-
PHPSESSID
-
JSESSIONID
-
CFID
-
CFTOKEN
-
ASP.NET_SessionId
-
https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html#session-id-name-fingerprinting
We should lowercase all argument names before checking.
We could in the future also use this same list to ignore various cookies / http-headers.
In addition there are some voices that feel that session Id's in url's are in itself a potential security issue, we may want to ask the user If they want to add a finding to the root (cleaned url) if we had seen session parameters.
- https://owasp.org/www-community/attacks/Session_fixation
We could also (maybe in a separate config) allow for more general cleaning of url arguments that we are not going to need since they wont provide any different content:
A project that does this (and seems to have some update mechanism) is found here: https://github.com/fireindark707/url_cleaner/blob/master/src/url_cleaner/rules.json using https://raw.githubusercontent.com/AdguardTeam/AdguardFilters/master/TrackParamFilter/sections/general_url.txt and https://github.com/AdguardTeam/AdguardFilters/raw/master/TrackParamFilter/sections/specific.txt as a source
