Please share with the community what you think needs improvement with Acunetix Vulnerability Scanner.
What are its weaknesses? What would you like to see changed in a future version?
The solution should work on dealing with the number of false positives it delivers. While we do have it integrated with other solutions, it could still offer more integrations.
I had some issues with the JSON parameters where it found some strange vulnerabilities, but it didn't alert the person using it or me about these vulnerabilities, e.g., an error for SQL injection. They need more customized scans along with a way to edit their default payloads. While you can select which check to do, you can't add which payload to use.
The jargon used makes it difficult for project managers to understand the issues, and the technical explanations used make it difficult for developers to understand issues. These things should be simplified much more. That would be very helpful for us when explaining to them what needs to be fixed. The report output needs to be simplified.
The scanning speed could be faster. It digs really deep, so that could be one of the reasons why it takes a while. If I want to scan an application, it's going to take over three to four hours. That's something I think they could improve. Instead of posting hundreds of requests to find the vulnerability, if it simply had the capability to find that particular vulnerability in the payload itself, that would make a big impact. The vulnerability identification speed should be improved. It takes more time compared to other tools I have used. Simply put, Acunetix passes too many payloads in order to identify one part of the ratio. That's probably why it can take a while to identify a particular issue. Other tools are able to identify vulnerabilities with just a few requests. Acunetix takes more time to make certain if a vulnerability exists. That's one of the areas which they can improve on. The scan configuration could be improved. The first thing that we need to do is set up a site policy and a scan policy. By site policy, I mean we have to choose what kind of technology our site is developed with so that it will only pass payloads related to that technology. For example, if I'm using MySQL or Python as my backend database, it will only check payloads related to MySQL or Python; it won't check Java or other programming languages. We have to define the scanning configuration as well as the site configuration each and every time. This has to be done whenever we are adding a new set of sites or domains. Other tools provide a list of predefined scan policies, but with Acunetix, we have to create our own every time. We have to spend a lot of time setting up these configurations, rather than just picking them from a vast variety of predefined sets of configurations, which is much easier.
The vendor messed up our contract when they changed the licensing scheme and downgraded our license without any notification. It was dropped from a premium license with unlimited scan targets to a professional license with 10 targets per year. This is insufficient for us because we have about 50 public websites, and twice that number between internal and development sites. We ran out of scanning targets after only two months, so we have been evaluating other products since then. There is room for improvement with respect to technical support. We were having trouble with our Active Directory Federation Services. They couldn't work out how to authenticate the websites. There is room for improvement in website authentication because I've seen other products that can do it much better.
The costs for the licensing have changed and it's not in our favor which is why we're now looking at other options. One of our issues is that Acunetix only supports web scanning, no mobile app for now. If they were to include that it would mean not having to work on two separate tools.
We want to see how much bandwidth usage it consumes. When we monitor traffic we have issues with the consumption and throttling of the traffic.
The solution limits the number of scans. It would be much better if we could have unlimited scans.
An area that we wanted to test was if it will tie bandwidth and does it throttle traffic? How much bandwidth usage does it consume when it sorts out the traffic. When monitoring the traffic we always have issues with the bandwidth consumption and the throttling of traffic. Everything now is moving to the cloud. If they would consider SD1 possibilities, it would give it the longevity that it needs in the market. They may not need it, as they would be able to integrate it with other SD1 platforms as an extra feature. By definition, they are not next-generation. The next-generation is fully cloud, properly load-balanced, and you would want something that is tailored along those lines from the get-go. It would give you more deployment, less support, and less technical hands looking at the solution.
In general, this is a good tool to check the security from the attacker's standpoint. However, when thinking about improvements there are still some attacks that we are not able to control with this kind of tool because there are some things you do in the front-end that sometimes launch processes in the application at the back-end. We need to be able to tie all of the front-end activities with all of the back-end activities. That's a missing piece that no one is providing. In terms of additional features, we are currently missing some tools that would allow us to work more efficiently with the mobile environment, with Android and iOS. The tools that we evaluated in the past are not really good for mobile applications. You can control the static code, you can control all the dynamic applications, but not within the phone, or within the tablet.
In terms of what needs improvement, the way the licensing model is currently is not very convenient for us because initially, when we bought it, the licensing model was very flexible, but now it restricts us.
It would be interesting to do differential scans. Normally, after the initial scan, the customer will start patching the discovered vulnerabilities. It would be nice to have a feature to "retest" only a single vulnerability that the customer reports as patched, and delete it from the next scans since it has already been patched. The executive summary reports could be improved with some graphs and a very short description of what has been discovered in a way that can be understood by C-level people.
On the vulnerabilities screen, where you put your target on the drop down, it would be nice to have more choices, not have such limited options. One thing that we used to be able to do in other applications with a macro was step-by-step filing in the fields of the app and being able to test certain forms. I haven't seen this in Acunetix. This would be a longer macro instead of doing a login, i.e., we are looking for a workflow process. We have experienced few false positives. Though, it does depend on the application because sometimes it will identify false positives on one application, but not on another.
There are quite a few false positives that come out. It's mostly based upon finding XSS vulnerabilities, even though we know that XSS vulnerabilities do not exist within some of the web applications because of some frameworks we're using. So, we're not entirely sure why it finds a bunch of these cross site scripting vulnerabilities, but these are main false positives that we have come across. You can't actually change your password after you've set it unless you go back into the administration account and you change it there. Thus, if you're locked out and don't remember your password, that's a thing. If you're exporting vulnerabilities to view so you can ingest them into another viewer, the ability to select all the vulnerabilities would be nice. Because as of right now, you have to manually go through and click on every single vulnerability that you want to export. With the implementation, when we started, there were a lot of issues. They've actually fixed a lot of the issues in the past (almost) year now. Initially, when you were creating a login sequence, when you wanted to edit it, you actually had to go back, open it in a text document, then edit the request that way because you weren't able to edit it through the GUI. Now, they've updated that, so you can actually go back and edit it, which is very nice. We had some issues, not particularly bugs, like with the user interface, e.g., "Why isn't this here?" Just specific tools that we were looking for initially, which they ended up implementing later on.
Acunetix runs the automated vulnerablity check scan and provides a report. testers/developers need to copy these vulnerable http/https request from the report, use other external tools like postman to resend the request observe the vulnerability and exploit them. If this was available within the Acunetix tool would have been a great feature.
I would like to see them build up that IAS tool, the Interactive Application Security Testing module that is embedded with PHC. That's a very cool function. I would also like to see them enhance the database. I don't know what version of OWASP Top Ten vulnerabilities they actually employ for Acunetix, but there are some versions of OWASP Top Ten vulnerabilities out there and I would like to see some PCI included as well within Acunetix. That would be great.
It should be easier to recreate something manually, with the manual tool, because Acunetix is an automatic tool. If it finds something, it should be easier to manually replicate it. Sometimes you don't get the raw data from the input and output, so that could be improved. That's the main concern for me. I would like to see some more advanced settings when it comes to authentication and authorization, and other fine-grain adjustments you could do to the scan engine. The advanced functionality could be a little bit better.
What do you like most about Acunetix Vulnerability Scanner?
Thanks for sharing your thoughts with the community!
Let the community know what you think. Share your opinions now!