Hot answers tagged

5

Those log entries look like normal scanning activity. You can also notice that the scanner did not target your setup specifically, because multiple versions and directories are tried. And as you said, none of those actually exist in your setup. What I don't understand is, why does he use // rather than / That's likely a bug in their scanning software ...


5

I've solved it by generating a fake certificate that doesn't reveal domain name and adding it as a default one on the start of the config: server { listen 443 default; server_name _; ssl on; ssl_certificate /path/to/fake.crt; ssl_certificate_key /path/to/fake.key; return 403; } And yes, it requires a nginx ...


4

This appears to be a bot looking for common vulnerabilities in websites. Such bots are very commonly run by black-hat hackers to identify potential hacking targets. All websites get scanned by such bots regularly. It is unlikely to be an attack specifically targeted at you. The only useful defense is to make sure that you don't have any vulnerable web ...


4

There are two possible answers. Either: because vulnerability scanners are by their nature 'dumb', that is they are operating based on pre-configured logic, they will make a best guess at what could be wrong with something using the logic incorporated within the scanner's code and can make mistakes. For example, if the scanner is checking for a particular ...


3

The idea of fuzzing is to send data to the interface with not much intelligence: garbage, random input and so on. When you are using a vulnerability scanner, you usually test for well known problems. In the case of web applications: injections and so on. It is possible that a vulnerability scanner can include some sort of fuzzing as one of the tests it ...


3

It is very common to see the vulnerability scanner requests in the server logs. Default pages of all major web, database administration tools, Linux and Windows, are checked sooner or later, regardless of what you are actually using. The bots look for the default (unchanged) passwords. Bots also try to find other vulnerabilities and check maybe you use ...


3

It is possible. WebInspect has had this feature since 2007 -- it may have been the first. Burp Suite Professional was also released that year with Spider and Scanner supporting runs simultaneously. Some tools like Netsparker do crawl first, but in this case I have found that you can install Netsparker, configure it, have it crawl, attack, and export results ...


2

The simple fact is that all automated web application scanning tools have a trade-off between false positives (flagging an issue when it's not present) and false negatives (not flagging an issue that is present) and they have to make a balance between the two as part of the product development. The way issues like the one you describe are generally coded is ...


1

Browsers don't submit anything after the hash character to the server. Anything after that character can only be access on the client side with JavaScript. Some vulnerability scanners (like burp suite) perform a static code analysis to see if the application is vulnerable to DOM-based cross-site scripting, for example. They generally don't execute ...


1

The scanner used was Netsparker, it self identified in the beginning of your log. https://www.netsparker.com That's the name of the scanner.


1

I'd add my opinion on this. Let's say you have an application to test (I am not including thick clients here as it's pure web application). The conditions on which the estimation might rely are: Considerable Items Number of URL's which could be fetched via Burp's Spider Number of Parameters which could be fetched via Burp's Engagement tools Number of ...



Only top voted, non community-wiki answers of a minimum length are eligible