Provide authenticated login for webscans about sechub

[de-jcup]

JSON format

The next example json shows up different login configurations at once. In real world scenario only one.
So only basic or form in combination of either autodetect or script should be used.

{
    "apiVersion": "1.0",
    "webScan": {
        "uris": [
            "https://productfailure.demo.example.org"
        ],
        "login": {
            "url": "https://productfailure.demo.example.org/login",
            "basic": {
                "realm": "${{ .LOGIN_REALM }}",
                "user": "${{ .LOGIN_USER }}",
                "password": "${{ .LOGIN_PWD }}"
            },
            "form": {
                "autodetect": {
                    "user": "${{ .LOGIN_USER }}",
                    "password": "${{ .LOGIN_PWD }}"
                },
                "script": [
                    {
                        "step": "username",
                        "selector": "#example_login_userid",
                        "value": "${{ .LOGIN_USER }}"
                    },
                    {
                        "step": "password",
                        "selector": "#example_login_pwd",
                        "value": "${{ .LOGIN_PWD }}"
                    },
                     {
                        "step": "input",
                        "selector": "#example_additional_locaion_field",
                        "value": "munich"
                    },
                    {
                        "step": "click",
                        "selector": "#example_login_login_button"
                    }
                ]
            }
        }
    }
}

The example above would be suitable for our go client. The client would replace LOGIN_USER and LOGIN_PWD template variables with dedicated entries from environment. So passwords would not be inside the configuration file and are injectable at runtime (e.g. on a Jenkins Build by secret credentials)

Projects not using go client but having a direct approach would be responsible itself to ensure their secrets are not leaked: Either use a generated config file at runtime, or provide placeholders like done in go client by themselfes (e.g. a ${loginUser} ) etc.

We provide following step types:

• input
  Use this to setup an input field. Needs selector and value
• username
  Same as input, but tagged as being credential part. SecHub will try to hide this information where
  possible. Please use this for username at login.
• password
  Same as input, but tagged as being credential part. SecHub will try to hide this information where
  possible. Please use this for password at login.
• click
  Use this to do a click operation. Needs only selector.

[de-jcup]

Netsparker

Basic authentication

https://www.netsparker.com/blog/docs-and-faqs/configuring-basic-digest-ntlm-kerberos-authentication-scanner/

https://www.netsparker.com/support/configuring-basic-ntlm-kerberos-authentication-netsparker-standard/

REST documentation

https://your-netsparker-server/docs/index#!/Scans/Scans_New

Form authentication

https://www.netsparker.com/blog/docs-and-faqs/form-authentication-password-protected-websites-netsparker/

REST documentation

https://your-netsparker-server/docs/index#!/Scans/Scans_New

[de-jcup]

Client parts will be done on another issue, so closing this isue.