Hot answers tagged

32

These types of spurious requests are very, very common. They are either looking to see if you are already compromised, or looking to get your server to throw an error to gather info about your server (from error messages). You aren't the only one: http://shadow.wolvesincalifornia.org/awstats/data/awstats092014.shadow.wolvesincalifornia.org.txt # URL with ...


12

The attacker tries to find out if you have certain premade web software installed by requesting files which are typical for them. When they find out you use, say, wordpress or phpbb or mediawiki, they can then try to use exploits specific to these applications to take over your site. The best countermeasure against this is to avoid installing too much ...


10

Yes, those are scans. If you Google those strings you will see that they show up in the web logs of numerous sites throughout the Internet, usually cheap webhost sites which put their logs up where Google can see them. This is sufficient indication that some tool is trolling for that URL. There is not enough information to indicate what the scan is ...


4

Is your system publicly accessible? Yes: Someone is probably scanning it. No: Are you scanning the server? Yes: Well, you've just answered your own question now haven't you? No: It's probably not getting scanned. I don't know: Wait... what? I don't know: You've got bigger problems. And yes, you're probably getting scanned.


4

That is the correct behavior. In the case of client-side JavaScript, it is by design that the script source is sent to the client to be executed. So, the fact that you can manually browse to the URL for the script file is irrelevant. It gives you no more access than the application intends for you to have. A source-code disclosure vulnerability is when ...


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

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


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


3

Yes, all your assumptions are correct there. As you are including content from addthis.com, your client-side Origin is fully trusting this domain. If there was any compromise to addthis.com, or if addthis.com decided to change the script to do something more invasive then your site would be vulnerable. For example, addthis.com may suddenly decide they want ...


2

A source code disclosure vulnerability is an involuntary disclosure of source code. Since JavaScript code runs client-side, on the browser, it's disclosure is intentional. Under this definition, only exposure of the server-side code is a source code disclosure vulnerability. The example you give actually has the GPL on it, so it's already disclosed ...


2

When scanning over a network, the topology between the scanning software and the server you are scanning is very important. Some tools need to be run on the server you are scanning. Depending on the type of scan you are doing, some tools will require that you run them on the server you are analyzing. This is usually done in what is called white-box ...


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


1

Configure your browser to point to Burp's proxy details (e.g. 127.0.0.1:8080) and then configure Burp to use an upstream HTTP proxy for all target hosts (* as the destination): However, if the upstream proxy is SOCKS, not HTTP, you need to configure it underneath (under the SOCKS Proxy heading) instead. This causes everything to be fed through the proxy. ...


1

If you are running a web sever, you might also want to set up a honeypot in your web application and trap automated scans. This can be done by configuring a section of your site, and disallow it in robots.txt. Any automated scans will ignore this, and will actually try to scan it. Any IPs accessing the disallowed area can be blacklisted using fail2ban for ...



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