Take Care in Handling the Results of Your Web Application Testing

Take Care in Handling the Results of your Web Application TestingHow do you handle your web application testing, vulnerability scans, test data and related security assessment reports? I’ve found that this is something that doesn’t get a lot of attention in web application security circles but is still impactful to the business. It’s actually kind of ironic that those of us working in IT and security often forget about what’s at stake if web vulnerability information were to fall into the wrong hands. I should know – I used to take it too lightly and many others still do.

The thing is, everything from passwords to SQL injection requests to hard-coded encryption keys – practically anything imaginable related to web security flaws – is contained in the following files, screenshots and reports:

  • Web vulnerability scan files (the raw data such as .wvs files in Acunetix Web Vulnerability Scanner)
  • Web vulnerability scanner reports (i.e. PDF and HTML files)
  • Screenshots of exploits
  • Proxy log files
  • Username and password dictionaries
  • Final web application testing reports containing specific findings and methods of exploitation

The risk is increased when all of this information is scattered about on multiple systems – especially once it makes its way to unencrypted laptops and data backups, third-party email systems and under-protected mobile devices (and trust me, it will). Even hard copies of web application testing reports can create business risks. I see those being tossed around to third parties quite often like it’s no big deal at all.

You can have the best NDA (Non-Disclosure Agreement) in the world but that’s not going to keep this information under wraps. What’s required is all the parties involved taking the proper steps to keep this information in check. Depending on your unique situation, you may have a few other options. You can de-identify the data within the scan files and reports before handing them over. Operating system, database and application privilege levels can also be set to ensure that only those with need to know access can view this sensitive information.

In the end, you’re not going to have complete control of the information resulted from your web application testing. You’ll have to trust people to do the right things. Unfortunately, that’s where businesses often get themselves into trouble. Thus the cycle of information security and managing risks continues.

To receive the latest updates relating to the website security industry, ”Like” the Acunetix Facebook Page, follow us on Twitter, and read the Acunetix Blog.

Share this post
  • Yes you say right. Web applications have become one of the primary security risks institutions face. Web applications are often widely accessible to the Internet as a whole, which in turn leaves them exposed to a large number of potential hackers. Ensuring the security of websites and internet-facing applications created and maintained by the University is an important investment for our institution to mitigate the risk.
    Aligning security policy with business goals is often difficult. Without adequate resources and in-depth experience to test for vulnerabilities and determine their impact, organizations can make uninformed decisions that will result in data breaches, non-compliance to regulation, disruption of service, and a loss of revenue, confidence, and trust.

  • We were hit by a hacker from yesterday, who downloaded the entire contents of htdocs, icons and launched 4600 attacks against cgi-bin.
    Disturbingly, some of the things he tried to get hold of was
    acunetix-wvs-test-for-some-inexistent-file, acunetix-wvs-test-for-some-inexistent-file-second-try and acunetixsessionfixation.
    I’m not familiar with your products, so I don’t know the significance of these files, but perhaps you should be aware of the fact that they’re a hacker target.
    The attack failed, by the way (although I hope he had fun with some of the animated GIF’s he got from the icons directory… 🙂 )

  • We got attacked by yesterday. They made a total of 29,473 requests. As soon as I saw a few of their requests in our web application firewall, I knew it was likely to be acunetix because I considered using it a few years ago and recognised some of the patterns. Closer analysis confirmed it.

    So out of those 29,473 our WAF let through around 60 of the first 70 then from there they were considered a 100% attacker. The remaining 29,403 requests continued for around 9 hours but our WAF blocked them so cleanly that I never actually noticed until I checked the logs last nights.

    For any attackers out there considering using acunetix; it is a good web application vulnerability tester. It is not a good method for attacking servers. Way too heavy and way to obvious.

    • Hi Neil,

      Thanks for sharing. As you rightly say, Acunetix is not designed to be stealth. It is however designed to find all the vulnerabilities that can be identified automatically. It will try to do this as fast as possible, and this will surely trigger WAFs and other security systems protecting the web site.

      For legit users, ideally Acunetix scans a site directly i.e. not through a WAF, or similar, as these might affect the scan results. The idea is to find vulnerabilities and fix them.

  • I agree with Nicky – if your goal is to find web security vulnerabilities, then use Acunetix Web Vulnerability Scanner. Sure, it’s noisy – but that’s the nature of this type of testing. No vulnerability scanner is “quiet”. If your goal is to remain stealthy/hidden, then, well, you probably already know what else can be done through additional tools and manual analysis.

  • Leave a Reply

    Your email address will not be published.