Tag Info

New answers tagged

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


26

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


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


3

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.


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


0

This could be of benefit if customers buy your web application and then install it on a platform of their own and you need to make it secure despite the underlying OS and back-end architecture. If the application has been properly put together and treats user input correctly in all places, then there should be no difference. If however, parts of the ...


0

If you find something different between servers, then you're finding problems with the server/infrastructure and not the app. Yes, there are instances when a particular infrastructure can process application code differently, but then that's a problem with the infrastructure and not the application code itself. I would not see that there would be value in ...


1

Some applications have aggressive session expiration logic, such as destroying a session if a single bad request is submitted. Others are more forgiving. In any case, you can use Burp's Macros to continuously validate a logged in session and to re-login if a Burp request triggers a logout/session expired action. Yes, you want to ensure you have a valid ...


4

Burp has some relatively complex options available for session handling but in the basic case, the scanner will use sessions from burps "cookie jar", so as long as it knows about a valid session ID it'll use it. If you invalidate your sessions while the scanner is running (for example by using logout functionality) then the scanner will likely stop working ...


1

Extending the OWASP theme... OWASP highlights a top 10 of issues to be concerned with: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project As well as the top 10 it is worth reflecting on the attack surface you are managing: https://www.owasp.org/index.php/Attack_Surface_Analysis_Cheat_Sheet One of the OWASP tools, Zap (Zed), helps spider your ...



Top 50 recent answers are included