Closed de-jcup closed 4 years ago
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:
https://your-netsparker-server/docs/index#!/Scans/Scans_New
Client parts will be done on another issue, so closing this isue.
At the moment web scans are only done unauthenticated. This reduces possibility of finding vulnerabilities much.
Current config (anonymous only)
Provided login mechanism
Some web scanners provide different authentication methods:
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.