Many people only run external or “unauthenticated” web application security scans; they do not audit the admin portal, or user portal of most business web applications which most of their own employees use. Be it for a PCI DSS compliance, business partner requirements, or internal audit, the need is to only see what can be seen (and exploited) from the outside world.
However, more and more people – namely savvy auditors, developers, and IT professionals – are performing authenticated vulnerability scans of their web applications; i.e. scanning the web portals that are typically used only by trusted users such as employees and freelancers and not accessible to the public. Scanning of such trusted web portals is becoming more important simply because many of the successful hack attacks typically happen from the inside of the trusted network because an insider was involved, or a malicious user managed to gain access to a trusted user account. In that case by scanning authenticated sections of your web applications, identifying vulnerabilities and remediating them you are also improving your containment policies.
Findings that are often identified during authenticated web vulnerability scans include:
Typically during a web application security scan one can also often identify vulnerabilities associated with the web application login system or even other user accounts. All of these low hanging fruit type web application vulnerabilities can be easily exploited by malicious users to further penetrate the network and generate more damage.
Authenticated web vulnerability scans are not completely hands-off. You’ll need to monitor the scanner to ensure that authentication and crawling are working properly. As you can imagine, it pays to know your application – the pages and the workflows. This is especially beneficial when configuring login macros and adjusting the overall scope of your scan. If, during your authenticated web vulnerability scans, you see that the scanner is not:
…then you’re probably not getting a good authenticated scan. It could be that your scanner is not properly logging in because of a poorly configured login macro, or the session is not well kept. It could also be that the user account or accounts you configured the scanner to login with are locked. User accounts and their management policies, such as account lockouts etc tend to be a big problem for automated scans. So be sure to keep an eye on these areas when running your authenticated web application security scans. Otherwise, you might have a false sense of security that your entire web application has been properly vetted.
Another thing you’ll want to keep in mind when running authenticated web vulnerability scans is the different user roles in your application. Each user role is going to have unique permissions/privileges within the web application which likely means that the web application security scanner will uncover unique vulnerabilities for each account you test with.
If you don’t have the time or ability to test every user role, at least start out testing the user role that’s most representative of your user base. Ideally you’ll want to test the highest level admin or supervisor role. The administrative accounts are usually the most targeted accounts and if these user accounts are ever compromised, it will likely present the greatest level of opportunity for exploitation. Yet, still, lower-privilege accounts might have access to pages and workflows that others do not and, therefore, vulnerabilities such as SQL injection might be unique to that role level.
The most important thing about authenticated web vulnerability scans is to ensure that you’re doing them. In the interest of time, effort, money, containment policies or whatever variables apply to your situation, you may not need to run authenticated scans every time you test. Just make sure you’re running them on a periodic and consistent basis.