When it comes to our dynamic scanning customers our goal, in addition to a high quality report of your code's vulnerabilities; is to also perform these scans as quickly and efficiently as we can. While there are a variety of metaphorical bumps in the road that can occur in this post we will be focusing on one we've seen quite a bit lately. The problem arises when our dynamic scanner hits a wall in the form of a [java applet/flash-based form/activex] or any function that is non-dom based or in other words Non-Standard Authentication. Our dynamic scanner is built to find flaws in dom-based programs and if we hit these types of walls it can adversely affect our ability to complete your scans in a timely fashion.
Examples of Non-Standard Authentication Forms
Technically, a login form is a mechanism for a normal user to perform the function of logging into your application. However, if the back end code that the form interacts with is improperly designed, the form could be exploited to bypass the authentication check. Separating which parts of a web application should be tested for functionality and what parts should be tested for security is not always a cut and dry process. CAPTCHAs are also technically a functional component of a web application, though their function is to prevent bots from accessing the page, clearly a security measure, this is more analogous to putting a lock on a fence. If the lock is popular enough, people will figure out how to circumvent it either through software or manual intervention. But in general, if an automated tool is being used to test a webapp with a CAPTCHA, it is unlikely to break this mechanism unless it is poorly designed, in which case it comes back to the function of the app being tested, not the security. In front of many webapps is a web application firewall (WAF). They are generally in the form of an appliance that filters traffic to the webapp in an attempt to prevent common vulnerabilities like XSS, SQLi and CMDi. These devices are useful as countermeasures, but at the end of the day, the site that they sit in front of can still be vulnerable and should itself be tested. Again, the WAF is a functional component of the server/hardware configuration. By design, it should stop XSS and SQLi attack strings from reaching your webapp, but the application itself should also have adequate defense mechanisms in place, not all attacks will come directly from traffic. Also, a WAF is not a panacea, it can be defeated like any other mechanism. In my opinion, the focus of security testing is heavily weighted towards preventing an unauthenticated malicious user from forcing their way into a site via a SQL injection or similar attack. Obviously, everyone wants to guard against that scenario but an attack can come from the inside or more likely, from an inside user's account that has been compromised. In this case, security measures designed to stop unauthenticated users are obviously not going to help much. So how can you avoid these bumps in your application submissions? We had our dynamic team come together and brainstorm a few questions that you should pose to your internal IT team or whichever resource you may have that understands the makeup of your webapp.
Questions to Ask Before Submitting an Application for Dynamic Scans
- Is there ANY mechanism in place specifically designed to deter automated use of the site?
- CAPTCHAs, security questions and randomly ordered number pads are all examples of this.
- Does the site allow the same user to be logged in multiple times, or is this forbidden? If so, does the mechanism that forbids this lockout the users credentials? If so how strict is it?
- If this is the case, we will have trouble scanning the site as currently, our scanner will attempt to create multiple sessions. If possible, removing this restriction on the credentials used for the scan is ideal. Otherwise, scan coverage may be impacted.
- Does the server have a WAF (web application firewall) or other filtering mechanism between the client and the server?
- These types of mechanisms should be disabled during a scan in order to test the actual web application and not the WAF.
- Is the site publicly accessible, in other words, can you get to the site from ANY computer with an internet connection, or only one from inside your company’s internal network?
- If the site is NOT normally accessible outside of your network, firewall rules and possibly port forwarding/routing rules will need to be put in place before we can scan the site. In most cases, whitelisting the Veracode IP range is the most important part of this process, these IP’s are available on the platform and listed in a sidebar when creating a new scan request.
Once you've gotten answers to these questions, make a list of the potential roadblocks our scanner may encounter and ensure that the appropriate workaround is in place. Submit this info with your dynamic scan and enjoy the speedy results we can deliver. Got more questions on dynamic scanning? Let us know in the comments!
