Targets are the websites and web applications that you would like to scan using Acunetix. In Acunetix Online, you can also configure Network assets as Targets. These will need to be configured in Acunetix before they can be scanned. Once configured, a Target can be scanned as often as required.
Change to the Add Targets page to configure new websites to scan:
- From the Targets dropdown in the sidebar, select "Add Targets"
- For each target you wish to add:
- Provide the address of the asset to scan
- Optionally, enter a short description that will allow you to easily identify this target
- Click the Add another Target button if you need to add another target
- Click the "Save" button when done
- Proceed to configuring any additional settings for the new Targets
Using a CSV file to import Targets
- If your Targets are already configured in another application, such as an Asset Management application, you might want to export the Targets from the 3rd party application and import them into Acunetix. This will save on the Target Configuration time. You can import a number of Targets into Acunetix using a .csv file. Proceed as follows:
- Browse to Acunetix UI > Targets > Add Targets
- Click on the Import CSV button
- Select the .csv file to import. The file should have the following format:
- Address, Description
E.g. http://testphp.vulnweb.com, PhP Test Site
- Click the Import button
- Confirm that all the Targets have been imported, and proceed to configuring any additional settings for the new Targets.
Targets can be grouped for easier management. For example, from the Vulnerabilities page, you can filter for the vulnerabilities of one Target Group, or in the Scan page, you can filter for scans of a specific Target Group. Users' accounts are also given access to specific Target Groups.
You will first need to create the Target Group, after which, you can configure target group membership for the Target Group.
Configuring Basic Target Options
Your target's basic details are listed at the top of the Target Settings page.
You can assign a different level of business criticality (Low, Normal, High, Critical) from the default labelled Normal. This will give you the opportunity to filter scans and vulnerabilities based on this metric, allowing you to focus on the more critical items in your web inventory if necessary.
Default Scan Profile
Every time you start a scan on a target, you can specify the scan profile to use, with the default scan profile being Full Scan. You may decide, however, to change the default scan profile for a particular target. For example, if you consider one of your targets to be a Low Business Criticality target, you may set your default scan profile for that target to be the High Risk profile; following this change, every time you launch a scan on this target, the default scan profile will be set to High Risk.
Your target may be adversely affected by high speed or high intensity (simultaneous requests) scans, or may trigger defence mechanisms that invalidate your scan results. You can adjust the scan speed to one of the following:
- Fast (default) — 10 concurrent requests, zero delay between requests
- Moderate — 5 concurrent requests, 250ms delay between requests
- Slow — 2 concurrent requests, 250ms delay between requests
- Slower — 1 concurrent requests, zero delay between requests
You can enable Continuous Scanning on a Target to have Acunetix scan the Target on a daily basis and report back any new vulnerabilities immediately. New vulnerabilities can be introduced by web developers making updates to the site or by administrators making changes to the web server’s configuration. In addition, Acunetix is often updated to detect new vulnerabilities.
Continuous Scanning performs a full scan once a week. This scan is augmented by a daily quick scan, which only scans for critical vulnerabilities. Continuous scans updates the vulnerabilities for the Target, and these can be accessed from the Vulnerabilities page. You will be notified by email and in the notification area when new vulnerabilities are identified.
After running the first scan on a target, and having identified and fixed any outstanding vulnerabilities, the Continuous Scanning option feature helps you to ensure that they remain secure.
Configuring Site Login
You may need to scan restricted areas within the web application configured as a Target in Acunetix. The information used to access the restricted area can be configured from the Site Login options found in the General Settings within the Target's configuration.
In most cases, you can select to have Acunetix try to auto-login into the site. This will work for most web applications which use a simple login process. You need to provide the Username and Password to access the restricted area. The scanner will automatically detect the login link, the logout link and the mechanism used to maintain the session active.
Using the Login Sequence Recorder
For more complex web applications, which might be using a more elaborate login mechanism, you would need to Launch the Login Sequence Recorder and record a login sequence (*.lsr file), which can then be uploaded and saved with your Target settings.
A Login Sequence is used to perform the following tasks during the crawling and scanning phases:
- Access form-based password protected area
- Replay login actions to authenticate to the website or web application
- Restrict actions which the crawler and scanner can access (such as logout links)
- Mark actions that require Manual Intervention each time they are accessed, such as pages with CAPTCHAs, one-time password and two-factor authentication.
A new Login Sequence may be created by following the steps below.
- Navigate to the Targets section from the left-hand-side menu
- Select the Target for which you wish to record a Login Sequence
- Enable the "Site Login" panel, and select "Use pre-recorded login sequence"
- Launch the LSR by clicking on the "New" link
By default, the LSR will browse to the Target URL that you are configuring the Login Sequence for.
You may start browsing to the login page and perform a successful login. Remember to use correct and valid credentials. With each action that is recorded, the panel on the right will start to be populated with login actions. Since the LSR is recording actions and not HTTP requests, it also works with web applications that make use of anti-CSRF tokens.
Once logged in, you may wish to replay the actions to ensure that the Login Sequence is valid and is logging in successfully. This can be done by clicking on Play at the bottom-left of the screen.
The right-hand-side pane shows a list of actions that have been recorded. Clicking on a specific action will reveal Action Properties on the bottom right-hand-side of the screen. Click next to record restrictions.
🔍 Acunetix Online Information
In Acunetix Online, this feature is not available.
Some login pages require additional steps before the "Login" process can be completed – some examples would be CAPTCHA, Two-Factor Authentication (2FA) or Multi-Factor Authentication (MFA), and other one-time password (OTP) mechanisms. As you record your login sequence, you will encounter the point where you need to intervene manually to perform a step that cannot be automated. When you encounter this point, select the "manual" option.
The LSR will keep track of this; when you are performing a scan, Acunetix will pause and prompt you for your Manual Intervention with a popup notification.
When you have completed the Manual Intervention actions, make sure that any actions created by the LSR that are part of the Manual Intervention process are deleted by selecting each superfluous action, and deleting it by clicking on the (delete) icon.
Now you can simply continue with the recording of the remaining Login Sequence actions.
Restrictions instruct the Crawler and Scanner not to follow specific links during a scan. Typically, you would want to restrict logout links or other links that might destroy a valid session in order to ensure that the scanner does not get logged out during the scan. The LSR also supports restrictions on HTTP methods commonly used in RESTful web services such as PATCH, PUT, DELETE in addition to the standard GET and POST requests.
If the link you are restricting contains a nonce or a one-time token, you may use wildcards (*) to restrict links with changing values. A Restriction may be set by following the steps below.
- Click on the link that you wish to restrict.
- Upon clicking the link, a dialogue will pop up asking if you wish for Acunetix to either
- Intercept this request (either in its exact form or by using wildcards)
- Forward such requests which match this request
- Forward all requests, meaning that there will be no restrictions
- In this example, we do not need to make any modifications to the Restriction, therefore we can select the first option – Restrict request using exact match
- The Restriction will be recorded, and shown in the panel on the right. You may add as many restrictions as you need.
Identifying a Valid Authentication Session
In the final step, the LSR will try to identify a valid session automatically. The session pattern is required, so that the Scanner will be able to know the difference between an invalid (logged out) and a valid (logged in) session. If the scanner is able to know that the session has been invalidated, it can replay the login sequence and validate the session again.
This is done by comparing the logged in and logged out states of the web application. There may be cases where no difference can be identified automatically. In such cases, you will need to either configure it by navigating to pages and let the LSR identify the pattern, or it can also be done manually. In addition to authentication mechanisms that rely on cookies, the LSR also supports authentication mechanisms that rely on HTML5 LocalStorage.
You can identify a valid authentication session while navigating:
- This can be done by browsing to authenticated areas of the website that will return a different response depending on the user being logged in or logged out.
- For example, a response from the website will contain the text “Logout” if the user is logged in. If it is not found in the response, the user is not logged in.
Manually Configuring User Session Pattern
If Acunetix is still unable to identify a user session pattern, you will have to configure one manually. The important point is that the responses sent by the web server will differ between those of a logged-in user and those of a user that is NOT logged in. Your task is to identify a reliable difference that the scanner can use to verify whether or not it is logged into the site.
When you have identified and configured the session pattern, it may be verified by clicking Check Pattern at the top of the right-hand-side panel.
Once you click on Finish you will be returned to the "Target Information" page. Click on the "Save" button to upload this saved login sequence file onto the Target Information page.
There are 3 main options for session pattern validation.
Option 1: Identify a visual difference on one of the web pages — some web pages will show, for example, a "Your Basket" link, only to logged-in users; some will show the name of the logged-in user (which obviously would not appear if there is no user logged-in). In such cases, you can instruct the LSR which page to go to by simply typing in something like this in the Session Validation Request text area:
GET https://juice-shop.herokuapp.com/profile HTTP/1.1
...and setting the dropdown labelled "Session VALID if:" to "pattern is found in response" to the logged-in specific text or user name:
Option 2: Identify a difference in the HTTP Response Headers in the logged-in web pages compared to the not-logged-in version. You can check this with Google Chrome, for example, by using the "Inspect" feature; the "Network" tab will show a "Response Headers" section that could include a header such as "X-Logged-In: true", but would be absent or have a different value such as "X-Logged-In: false":
Now you can set the dropdown labelled "Session VALID if:" to "pattern is found in headers" to the identified header value:
Option 3: Identify a web page that receives a numeric response when logged in (typically 200), and some other response when not logged in, such as a 404 (not found) or a 500 (server error). Set the dropdown labelled "Session VALID if:" to "status code is" to the valid value:
Acunetix supports the OAuth2 authentication mechanism, allowing you to configure targets for web applications that require OAuth2. A new OAuth Login Sequence may be created by following the steps below.
- Navigate to the Targets section from the left-hand-side menu
- Select the Target for which you wish to record a Login Sequence
- Enable the "Site Login" panel, and select "Use OAuth for this site"; this will expose the configuration fields
- Set the Grant Type to one of the OAuth2 Authentication Flow mechanisms; the supported Grant Types are:
- Authorization Code
- Client Credentials
- Password Credentials
- Set the "Access Token URL" and the "Authorization URL" (only for the "Authentication Code" grant type) for the Authentication Provider; you can obtain the URL(s) from the Authentication Provider (eg. Google or Facebook)
- Set the "Redirect URI" for your target; this is the URI which the user will be redirected to after completing the login process with the Authorization provider
- Set the "Client ID" and "Client Secret" fields for your target; these are unique values assigned to your web application by the Authentication Provider when you registered your web application with the Authentication Provider for its login functionality
- Some OAuth2 authentication flows require the "State" field to be populated
- Set the "Scope" field to a space-delimited list of elements for which permission is being requested
- Some oAuth2 authentication flows require the "Username" and "Password" fields to be filled in
OAuth2 authentication flows that require a 3-legged sequence, such as filling username and/or password fields in a separate step, or requiring clicking on a "Confirm" or "Allow" button, are also supported. Clicking on the "3-legged Sequence" button will launch the Login Sequence Recorder window to present the OAuth2 Authentication Provider's dialog.
When you have completed the login sequence, the window will close automatically.
Click on the "Save" button at the top of the page to save your target's settings.
Using the Business Logic Recorder
Many web applications today utilise dynamically expanding or multi-step or multi-page forms. This means that a "first stage" form is presented to the user, and when the user inserts information into this first stage, this information will determine how the form will change, in the next step or page.
We very often see these types of forms in air travel web applications, and in highly interactive shopping carts – these are just two examples. The reality is that these multi-step forms are becoming common, and the Business Logic Recorder provides the tools necessary to create a string of actions for the scanner to follow to properly navigate multi-part forms.
Generating and Installing AcuSensor
AcuSensor improves the scan results provided by Acunetix by being able to identify all the pages on your website, increases the information about the vulnerabilities detected and decreases false positives. Check the relevant sections for more detail about deploying AcuSensor into a target web application.
Reset AcuSensor Token
If for some reason you wish to change the built-in token (similar to a unique key or password) for an AcuSensor agent (to invalidate an old token, or to use the same AcuSensor agent file for more than one target, for example), you will need to:
- edit the target
- navigate to the lower half of the AcuSensor panel
- click the Reset for Target button
Now the new AcuSensor agent for the target will contain a new unique strong built-in token - this means you will need to redeploy the AcuSensor agent to your target web application before starting a new scan.
Scanning for vulnerable software components - SCA
Software Composition Analysis (SCA) is an important part of application security testing. Today's web applications deliver rich functionality through the use of multiple open-source components. Like all software, open-source components are subject to vulnerabilities, and each component will have a development path typically tracked with version numbers. SCA is the process of analyzing an application’s source code to identify open-source components and their version numbers, and comparing this list with a master database that contains known components with version numbers and vulnerability exposures.
Scanning a target with SCA functionality
Acunetix provides an SCA server with a master database of open source components as part of Acunetix Online Services. You must ensure that Acunetix Online Services are enabled for your Acunetix installation before SCA analysis can occur; go to your profile page to check this:
When an application is scanned with Acunetix, the AcuSensor agent deployed to the application will analyze the application, create an inventory of components being used, and submit the inventory to the SCA server for comparison. The SCA server will then respond to Acunetix if it finds any components with known vulnerabilities.
Other Advanced Options
For each Target, you can configure other options, including:
- Crawling options, such as using a custom User-Agent
- Paths to be excluded when scanning the specific target
- HTTP Authentication
- Client Certificates
- Custom Headers
- Custom Cookies
- List of Allowed hosts, which will be scanned when scanning the specific Target. Note that these need to pre-configured as separate Targets beforehand
- Knowledge Base for each Target, collecting information about URLs, vulnerabilities, and other information, that is accumulated with each scan on the Target
- Excluded Hours profile