Read A General Overview: Checking Information Level Scan Results before reading this article.
This article outlines key Information Level findings you can use to get more insight into the health and performance of your Web Application scans.
Scan Status must be completed. If you see that a scan failed, please check the Warnings tab for additional information. If it's missing or you cannot conclude what has caused the failure, please re-run the scan to check if the error can be replicated. If it can, please check our Status Page for a potential system outage from AppCheck's side. If none of the above apply, then please raise a query with Technical Support via our Help Centre.
Scan Interference will be flagged in the form of a red banner at the top of the scan. Interference is detected when your IPS intercepts communication between the scanner and the scan targets - this may take the form of blocking requests entirely, modifying requests, or rate limiting. More details can be found either in the High level findings (for Web application scanners) or Info level findings (for Infrastructure scanners). For more information, see Allowing AppCheck Access to Your Network or Applications.
Contents
Authenticated Web Application Scans
These type of scans will mostly be authenticated using GoScript, If other custom authentication headers are used, the Mapped Attack Surface will provide additional references that can be used to confirm successful authentication.
The Information Findings
Successful/Unsuccessful Authentication and Auth Analysis
These indicate whether the scanner was able to establish an authenticated session with the target, to understand the authentication mechanism, and to extract the authentication token(s) required to submit authenticated requests.
Successful Authentication
This finding is produced when the GoScript completes successfully (or the scan was able to log in during the initial stages of the scan using the provided credentials if not using GoScript). However, seeing this finding does not indicate that the scanner remain authenticated for the duration of the scan. Look for this finding to be paired with a "Successful Auth Analysis" finding.
Successful Auth Analysis
This indicates that the scanner was able to understand the authentication mechanism and extract the authentication token(s) required to submit authenticated requests, thus allowing it to maintain and re-establish an authenticated session as needed for the duration of the scan. This finding can only be produced following Successful Authentication.
Unsuccessful Authentication
This indicates that the scan encountered an authentication barrier that it was not able to pass. If you have configured the scan with authentication for the listed barrier then it indicates that the authentication failed (this could mean the GoScipt failed to complete, or the Basic Auth Header was rejected, etc). In most cases the solution will involve testing and updating your GoScript or credentials.
It is possible for an application to contain multiple authentication barriers. If your scan is configured to pass one but not another then expect to see both Successful Authentication and Unsuccessful Authentication.
Unsuccessful Auth Analysis
This means the scanner was unable to identify the authentication mechanism used by the target(s). It can mostly be resolved by guiding your GoScript to an endpoint that invokes the used auth token/cookies, however, it is a bit more difficult to troubleshoot. If you cannot identify the reason for failed auth analysis, please contact Support.
Mapped Attack Surface
Shows a logical list of attack targets, grouped by the structure of the request and the structure of the response, with response status codes for each group. This information can be found be clicking on the Mapped Attack Surface finding, then clicking on the "Details" tab.
This output is not a list of every page crawled, it is the de-duplicated list of targets believed to map to unique controllers (back-end page generation/application code). For more information see How can I see a list of which paths or URLs AppCheck has scanned (crawled and attacked) for my web application?
How To Use the Output Information For Troubleshooting - If status codes returned in this info finding are different from expected status codes (e.g. 403 when 200 is expected), manually check this by logging into the target in your browser to confirm the target responds as you expect.
Changes in expected status codes can occur if the scanner gets locked out whilst scanning or if something changes during the scan, it can also occur due to time-outs. If the scanner receives response codes that differ from those you see in manual testing, this likely indicates obstruction by a WAF/IPS, or failure to authenticate.
When To Use the Output Information For Troubleshooting - The finding is used when checking the number of logical targets identified by the scan and their responses. It gives you a good idea of whether or not the scanner (or crawler in particular) was able to explore your application and API in its best capacity.
A small number of logical targets (for a large web application) and a large number of errors in response codes may indicate that the scan configuration requires further adjustment.
How much time you wish to spend troubleshooting issues in your attack surface is a judgement call. If you feel that the targets listed with good responses represent a sufficient sample of your application's controllers then you may consider this adequate for scanning.
Possible Scan Turbulence
Lists targets which were slow or timed out. A large number of targets reported in Scan Turbulence may indicate that the server is overloaded. Reducing the Max Threads setting may help address this problem:
- Web Application Scanner Settings
- Advanced Settings
- Max Threads
- Advanced Settings
For more information see How many HTTP requests (or how much traffic) does AppCheck make when scanning my website or service?
You can also add a Scanning Window schedule to avoid times when your application/ web server is used the most.
Reducing the Max Threads value and adding Scanning Windows would increase the total duration of the scan, this is because reducing the Max Threads value will reduce the requests rate and the Scanning Window will limit the scan's running time(s).
Slow Target Skipped
Lists targets that were skipped after retries due to slow responses. This is similar to Possible Scan Turbulence (and also requires more attention due to missed endpoints), and you can take similar steps to mitigate this - Scanning Windows and Threads Reduction.
Non-GoScript Authenticated Web Application Scans
These are scans where authentication is provided without the use of GoScript, perhaps via a basic authentication header or another method. In most cases these type of scans do not provide a finding for successful or unsuccessful authentication. However, the Mapped Attack Surface information finding will provide additional information on the crawled paths and endpoints.
The status codes (200, 401, 403, etc) received from the endpoints in the output of this finding will provide information on the Scanner's interaction with the listed endpoints.
Un-Authenticated Web Application Scans
These type of scans are for targets where authentication is not required. These type of scans do not produce information findings unique to targets that didn't require authentication.
These scans produce the same information findings that the authenticated scans produce minus the Successful/Unsuccessful Authentication and Auth Analysis findings. Every other finding listed in the Authenticated Web Application Scans section can be used for analysis and troubleshooting.
If the scanner encounters an authentication barrier in the target application, and has not been configured to authenticate, you may see an Unsuccessful Authentication finding. Whether you are content to ignore this, and scan only the elements of the application that are not locked behind the barrier, or whether you wish ti implement an authenticated scan, is your choice.
Comments
0 comments
Article is closed for comments.