- Why Bright
-
Product
- Resources
- DAST
- Application Security Testing
- Penetration Testing
- Vulnerability Management
Guide to DAST (Dynamic Application Security Testing)
Your primer for application security testing.
We explain the concept of penetration testing.
Comprehensive overview of vulnerability management.
- DevSecOps
- API Security
- Unit Testing
- Fuzzing
All the necessary knowledge to get started with DevSecOps
We take a deeper look into securing & protecting your APIs!
All you need to know about keys of unit testing & best practices.
We explore fuzzing and evaluate if it's the next big thing in cybersec.
-
Company
- Partners
- Contact
How to know if a scan was successful and what to do if it wasn't
Welcome to Bright. In this video, you’ll learn how to check if your scan completed successfully or not and how to optimize your scan configuration. If your scan finished with the done status, it means there were no critical problems during the scan. However, the target might not have been covered completely by validating the target coverage or attack surface. In other words, you can be confident that your scan quality is high and the real vulnerabilities were detected. The attack surface is defined by the entry points that were identified and included in the scan. Each entry point represents a single interaction of Bright with the target application. So the first thing you should do is to review the number of found entry points in the scan results. There you should also check out the network and engine notifications tabs to make sure that there were no blockers or connectivity issues during scanning. Such blockers may not only critically affect the results of a scan, but also the scan duration and are typically associated with either network or configuration issues. In most cases, network issues originate from improper allow listing of the bright IP in the web application firewall, or simply WAF. For example, if during a scan, Bright receives mostly 403 or 405 statuses, it may indicate that Bright is blocked by a WAF, but response statuses like 401 could also indicate that there is a problem with authentication. Configuration issues typically refer to misconfigured authentication objects, API schemas, or incorrect crawler parameters. For example, you may mistakenly select the wrong authentication object for a scan. In this case, the protected parts of your target won’t be included into the attack surface and will be skipped during scanning. In this video, we provide a short list of potential scam blockers. For more information about troubleshooting of network and configuration issues, check out our docs. Now let’s look at an example. We have already run a scan with a crawler against a vulnerable application. Let’s open the scan results to check if the scan passed successfully. In the coverage section, we see that the scan only found five entry points, while the expected number for this application is much higher. Generally, if no entry points or only a few of them are found during a scan, this should be a red flag. In other words, the bright engine faced some blockers during the scan. As we said in the introduction, the problem of incomplete scan coverage may be caused by a WAF. That’s why we usually start reviewing the scan results by looking at the response statuses found in the network tab. In our case, the majority of statuses are 200, which means that the bright engine was not blocked by a WAF and we should search for the cause in some other place. The next step of our investigation is to review the engine notifications for any skipped entry points which indicate incomplete coverage of the target. You can search for error messages by keywords. For us, it’s skipped. Once the search parameter is applied, we see a long list of skipped entry points. The bright engine may skip entry points for several reasons. For example, due to incorrect authentication configuration, if response from an entry point takes too long or because a user manually excluded certain entry points from a scan to determine the exact reason, we need to review the initial scan settings in the configuration tab. For this video we set up a misconfigured scan intentionally by excluding most entry points of the target manually. This is seen from the ignored URLs list. If you have multiple skipped entry points during a scan, you should also pay attention to the authentication object configuration and consider increasing the response time limit in the parameter called skip entry points. If response is longer than two, check the attack surface coverage. You can also view the site map which shows all the parts of the application that Brite has identified and scanned. Thanks for watching and happy scanning from all of us at Bright.