Provide authenticated login for webscans

[de-jcup]

At the moment web scans are only done unauthenticated.
This reduces possibility of finding vulnerabilities much.

Current config (anonymous only)

{

	"apiVersion": "1.0",

	"webScan"   : {
               "uris": ["https://productfailure.demo.example.org"]
         }
}

Provided login mechanism

Some web scanners provide different authentication methods:

• basic
• form based
  • automated
  • scripted
  • recorded

We want to provide all of them without being product specific.
Basic and form based automated are simple - for "scripting or "recorded" this will be tricky.

Handle basic login

just provide product with information

Handle form based automated login

just provide product with information

Handle recorded or scripted logins

"Recorded" is a little bit "evil" when wanting to be product independent. Scripting as well. To solve this we will provide a scripting part where operations can be described in a very simple way. A product dependent script will be generated. If the product needs a recorded script/file, we will generate the record entry... All necessary metadata should be available when defining necessary script steps inside configuration.

[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.