Tag Info

New answers tagged

1

Are you sure you need to have an externally hosted website? A lot of the testing I do happens on a virtual machine -- I install a flavor of linux, apache webserver, the software package, and fire away. With a virtual machine, you have the following assurances: You will not disrupt other people's websites. You will have access to all logs and all parts of ...


0

The Metasploit Framework is my go-to tool for pentest automation still to this day, however, I do like what I've seen of CORE INSIGHT and Immunity Security SWARM. There are a few tools such as mana-toolkit and Responder.py that must be run outside of the Metasploit framework, but so many things can be done inside msfconsole these days (`use kiwi' comes to ...


2

Pentest reports should never give assurance. You can't state that a webapplication is secure, you can only state you didn't find anything or that you did find things. It's important you do not make yourself liable and that your contracts are waterproof as to ensure you do not imply that you guarantee the security of the application.


5

If code is served by a large Content Delivery Network (CDN), like Google's CDN, then it is more than likely that you will be hacked through other means. Large CDNs have a lot of money to spend on security, and a CDN is unlikely to be a weak point in your own infrastructure. Once a site hits a certain level of popularity, then it needs to serve static ...


1

The main issue with including scripts from other sites is that they (or even someone that gets to hack their server) might modify the script to include malicious code. Right now you have 2 options that have pretty big "downsides": Reimplementing addthis script would be pretty time consuming, so, I don't think you want to go that way. Also you would have ...


1

Yes, it is a security issue. The included JavaScript runs in the context of your website, which means that it has control over anything that you would have control over. External JavaScript files can harm you by among other: read cookies (eg to steal sessions) read user input (eg to read password inputs) change what the user sees (eg to display ads, ...


1

It seems that you are talking about wordpress.com, where the website is hosted on the server of wordpress, not your own server. Even if you registered a website at wordpress.com, if you scan/attack it you are attacking the wordpress.com server, which might not be a good idea. Here is what I could find out: I looked at the TOS of wordpress.com, and the ...


1

I've used several scanners against my own web servers, both VPS and shared hosting. With shared hosting I informed the hosting company because it "could" create some traffic. Als long as you have a go from the hosting party you should be fine. Regarding the VPS, I never informed them as the IP's are specifically for me. Hope this helps.


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


1

Wpscan wasn't able to reproduce this vulnerability so they removed it from the database. If you update the wpscan database with wpscan --update and then rerun wpscan against the url you're targeting you will notice the vulnerability does not appear.



Top 50 recent answers are included