urls that redirect with a 'sessionID in the url' give cluttering in the objects list.

[stephanie0x00]

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:

1. Perform scans against SSO portals.
2. 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.

[underdarknl]

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.

[underdarknl]

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.

[tzijlmans]

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?

[stephanie0x00]

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.

[stephanie0x00]

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