Conventional web application tests are fairly straight-forward — the scanner sends a payload to a target, receives a response, analyzes that response, and based on the analysis of that response raises an alert.
How does AcuMonitor solve this?
Out-of-band vulnerability testing, accounts for vulnerabilities that do not provide a response to a scanner during testing, and therefore, are not detectable using the conventional ‘request/response’ testing model.
Detecting out-of-band vulnerabilities requires an intermediary service that the scanner has access to. Acunetix, combined with AcuMonitor, makes automatic detection of such vulnerabilities painless and transparent to the user running the scan.
The illustration below shows how Blind XSS is detected using Acunetix and AcuMonitor
- Acunetix first sends a payload to the web application
- The XSS payload gets stored in a datastore which may remain there for an indefinite amount of time (i.e. long after the scan has completed)
- This payload is executed inside a victim’s browser at a later date, possibly from an entirely different web application which shared the same datastore
- Once the XSS payload executes, it will contact AcuMonitor notifying it that it has executed
- AcuMonitor in turn notifies Acunetix that the vulnerability has executed
- Acunetix raises an alert for the newly discovered Blind XSS vulnerability
What vulnerabilities can AcuMonitor detect?
AcuMonitor can automatically detect the following vulnerabilities during a scan.
- Blind Server-side XML/SOAP Injection
- Blind XSS (also referred to as Delayed XSS)
- Host Header Attack
- Out-of-band Remote Code Execution (OOB RCE)
- Out-of-band SQL Injection (OOB SQLi)
- SMTP Header Injection
- Server-side Request Forgery (SSRF)
- XML External Entity Injection (XXE)
Security of AcuMonitor data
A common question about AcuMonitor is – “Does this mean that the AcuMonitor service stores details of vulnerabilities it detected?”.
AcuMonitor is designed to be secure in the way data is transferred to it, as well in terms of what it stores, and for how long it stores it.
AcuMonitor’s payloads will always make use of TLS when possible. This ensures that connections to AcuMonitor are encrypted. Additionally, AcuMonitor does not receive or store enough information to identify the source of a vulnerability – in other words, AcuMonitor only knows that a payload from a vulnerability test conducted by Acunetix resulted in a callback, but it does not know what the source of the vulnerability is; nor is any information about the original HTTP request sent by Acunetix stored in AcuMonitor.
- AcuMonitor will record that a callback was made from a location using a random identifier generated by Acunetix to distinguish one test from another
- The HTTP request which was originally used to trigger the vulnerability is not stored at AcuMonitor, instead it is stored on the machine running Acunetix
- Requests made to AcuMonitor will only be stored for a limited amount of time (maximum of 7 days)