login + token revoke + session issues

[xakrurychle]

issue 1 - I was able to delete current session token - for security purposes, can some prevention check be implemented?

issue 2 - because I deleted current session token, the session is now dead but it still appears in 'fcli ssc session list' as not expired..

Name Type Url Created Expires Expired krystof_session SSC https://qa-st-c7-kho01.prgqa.hpecorp.net:8443/ssc/ 2022-12-14 12:00:59 UTC 2022-12-15 12:00:59 UTC No

only after running fcli ssc session logout -u user -p pass sessionName I removed the session completely

[rsenden]

We could potentially check whether the token passed to the fcli ssc token delete command isn't in use by an active session, however:

• The token could still be deleted through other means like FortifyClient or SSC UI
• This check would likely only look at SSC sessions, not SC SAST/DAST sessions, so those sessions could potentially still be accidentally invalidated while still marked as not expired

The session list command only looks at session files created at login; it doesn't check whether the token still exists. We can't implement any such functionality on either session list or arbitrary other commands that would fail if the token has been deleted/expired; SSC doesn't allow for checking token validity (as all token endpoints require user credentials, which are not stored by fcli for security reasons), and we can't just try by invoking an arbitrary endpoint, as either the token (for pre-generated tokens) or the user for which the token was created, isn't allowed to call a particular endpoint.

[rsenden]

We can't implement this in a reliable way without SSC API improvements, best thing we can do is to improve the description of the fcli ssc session list command, describing the fact that expiration date/status doesn't reflect any token changes or revocations.

[rsenden]

Command help has already been updated, and as described above, there's not much more that we can do from an fcli perspective to better handle such situations. As such, closing this issue.