Hello,

The current implementation is not able to handle the default Azure SSO workflow as described here.

The KMSI workflow requires a third interaction as can be seen in Microsoft's workflow description.

Unfortunately there is no way to bypass this by setting a cookie or similar and there also does not seem to be an easy way to extend/script the DAST analyzer to perform the necessary step.

current non-working setup

include:
  template: DAST.gitlab-ci.yml

variables:
  DAST_WEBSITE: "https://some-sso-website.com"
  DAST_AUTH_URL: "https://some-sso-website.com"
  DAST_USERNAME_FIELD: "css:[id=i0116]" # The ID of the AAD "Username" field
  DAST_FIRST_SUBMIT_FIELD: "css:[id=idSIButton9]" # The ID of the "Next" Button
  DAST_PASSWORD_FIELD: "css:[id=i0118]" # The ID of the AAD "Password" field
  DAST_SUBMIT_FIELD: "css:[id=idSIButton9]" # The ID of the "Sign In" Button
  DAST_BROWSER_SCAN: "true"
  DAST_USERNAME: "some-user"
  DAST_PASSWORD: "some-user-password"
  DAST_BROWSER_LOG: "auth:debug"

Proposal

It would be great to extend the implementation to allow for the three-step-login as defined by Microsoft. An easy solution might be to add DAST_KMSI_FIELD. That field could then be assigned to either

• the Yes-Button (css:[id=i0116])
• the No-Button (css:[id=idBtn_Back])

The proposed .gitlab-ci.yml file would then look like this

include:
  template: DAST.gitlab-ci.yml

variables:
  DAST_WEBSITE: "https://some-sso-website.com"
  DAST_AUTH_URL: "https://some-sso-website.com"
  DAST_USERNAME_FIELD: "css:[id=i0116]" # The ID of the AAD "Username" field
  DAST_FIRST_SUBMIT_FIELD: "css:[id=idSIButton9]" # The ID of the "Next" Button
  DAST_PASSWORD_FIELD: "css:[id=i0118]" # The ID of the AAD "Password" field
  DAST_SUBMIT_FIELD: "css:[id=idSIButton9]" # The ID of the "Sign In" Button
  DAST_KMSI_FIELD: "css:[id=idSIButton9]" # The ID of the "Yes" Button
  DAST_BROWSER_SCAN: "true"
  DAST_USERNAME: "some-user"
  DAST_PASSWORD: "some-user-password"
  DAST_BROWSER_LOG: "auth:debug"

Implementation Plan

• DAST_AFTER_LOGIN_ACTIONS will be a list of comma separated actions to be executed after login. Example: "click[on=css:.remember-me],click[on=id:stay-signed-in]" .
• Add new field to configuration
  • Add AfterLoginActions []string to tomlAuthConfig (toml_auth_config.go).
  • Add AfterLoginActions browserk.LoginAction to AuthDetails (auth.go). Parse (see new point) and assign this property in toml_auth_config.go.
• Parse DAST_AFTER_LOGIN_ACTIONS
  • In scanner/auth, create a new package actions. Create a new struct, LoginAction.
  • In browserk/auth.go, create a new interface called LoginAction.
  • In the actions package, create a ClickAction. Ensure that the click[on=xxxx] can be parsed into a click login action.
  • In the actions package, create a LoginActions (similar to selector.QuerySelectors)
  • In the actions package, create a parser.go with a Parse function. Parse should convert a series of login action strings into actions.LoginActions, and the Parse function should return browser.LoginAction (similar to scanner/browser/selector/parser.go#Parse)
  • Parse should return an error with an appropriate error message if unable to be parsed.
  • If there is no after login steps, Parse should return an empty actions.LoginActions. This way, the service that uses the steps won't need to worry about it being nil.
• In auth.Service.processLoginSteps, after attempting login and before navigating to about:blank, ask the login actions to execute.
  • Cookies recorded during this process should be captured as part of the AuthContext
  • Add Execute(loginCtx *browserk.Context, crawler browserk.Crawler, browser browserk.Browser) ([]*browserk.Navigation, error) to each browserk.LoginAction.
  • The click action will need to create a new click navigation (see how PathToLoginForm works in authenticator.LoginFormFinder). The crawler will process the navigation.
• Update an end-to-end test to use this new field. Avoid writing a new test if possible to minimize the the number of end-to-end tests required to run in CI.
• In DAST
  • Add configuration DAST_AFTER_LOGIN_ACTIONS and pass it on to Browserker.
  • Upgrade Browserker

Out of scope

• The after login action items will not create separate entries on the auth report (please make sure PM is aware of this, we can create a new issue if required)