"Sites" form too restrictive

[MiErnst]

Hi,
I did a setup of minion by using the provided Virtual Box VM. I want to run tests against my locally startet server with an installed web application. The "site" page of the admin console was not able to be configured against ip of my host machine or another port than port 80. So I had to configure my server setup and the hosts file. I don't think this admin page must be so restrictive. Allowing Context Paths would also be nice.

BTW: a message that the added site must be added to a group to be able to run scans against the site would be nice.

Kind regards
Michael

[st3fan]

Yes, the form is strict on purpose as we did not know how flexible we should be.

Allowing ports can certainly be done. What do you expect to happen when you also specify a context path? Should that configure all the tools to only scan under that path and exclude everything outside of it?

[idev]

+1
Adding Sites should also work for IPs only or subdomains (e.g. https://-stage-.tester.com/).

[MiErnst]

@st3fan
Sorry for the late reply but I was on vacation.
If a context path is given the context path should be used as a starting point for the scan. I thinks the tools should behave like they were configured directly on the domain, so no excludes for upper path elements or the domain itself.

[aellwein]

I fully agree with MiErnst, the scanning of context paths is an essential feature. Sometimes there is no way to provide an isolated virtual host for a scanned URL path, so the context path have to be respected. Imagine scanning of REST API of a server, locating somewhere under host:port/rest/...

[ashleyblackmore]

I agree with this. The form is far too restrictive. Since I am unable to run scans against certain targets (I get a "Site could not be reached" error when trying to hit the site without paths). If a path is not specified, how else is minion supposed to find it? I will patch the regex on my own fork for now