- Unauthenticated: Application content (pages) available to a user without credentials e.g. /index.aspx, /products.jsp, etc
- Authenticated: Content only available to a user with credentials e.g. /admin.php, /change_password.aspx, etc
- Authenticated Role: A group of users with access to a particular subset of the application's entire authenticated content. For example, a "helpdesk" role might only have access to create and close tickets but a "helpdesk_manager" role might also have access to ticket reporting functionality.
One of the most compelling reasons to test from an authenticated user's perspective is that some vulnerabilities are exploitable without credentials but are only discoverable with credentials. Furthermore, a certain vulnerability may reside in a page only accessible by a certain authenticated role. Consider the following example scenarios:
- SQL injection is possible within an application but only on a page that requires authentication. Without actually authenticating, an assessor would be unable to identify this major vulnerability.
- A web application assigns predictable session identifier values but only sets them after successful authentication. Without authenticated testing a serious external weakness which would allow user impersonation would go unnoticed. Furthermore, since it is a best practice to only provide session IDs after successful authentication, the application would appear perfectly secure to the unauthenticated assessor.
- A web application redirects users to pages that are not linked to from an unauthenticated perspective. Authorization is not enforced, allowing anyone who forcefully browses to these pages, authenticated access. Without credentials, and depending on the complexity of the pages' directory structure and file names, unauthenticated testing may very well leave this serious external weakness unrevealed.
- A web application is vulnerable to cross-site request forgery (CSRF) and allows an attacker to force users to order checks to an address of the attacker's choice. Without authenticated testing, the check order functionality would not have been touched by the assessor even though CSRF is an externally-initiated attack, relying on the users' own session cookies.
- A web application allows a normal authenticated user to obtain administrative user privileges based on the presence of an "admin" parameter or cookie. Without testing from both the user and administrator perspectives, this flaw may not be discovered.
Our Standard web application security assessment service categorizes findings based on severity and whether they are discoverable and exploitable from authenticated or unauthenticated perspectives. Authenticated testing is performed for a variety of security roles if requested, which allows us to rigorously assess applications' authorization, authentication, and session management mechanisms.
Another interesting, and sometimes confusing subject that should influence testing methodology is regulation. For example the Payment Card Industry's (PCI) Data Security Standard (DSS) mandates in 6.5 that all (internal and external) web applications are developed based on secure coding guidelines so as to prevent the ten types of vulnerabilities outlined in the Open Web Application Security Community (OWASP) Top Ten list. DSS 6.6 goes further and mandates that all publicly accessible web applications be either assessed for the presence of OWASP Top Ten vulnerabilities or actively managed by a web application firewalls that can prevent exploitation of the OWASP Top Ten vulnerabilities. An entire separate document clarifying what is meant by "Application Reviews" and "Web Application Firewalls" attempts to shed light on what testing is required for an "Application Review". It mentions that manual or automated testing may suffice but it does not spell out that unless authenticated testing is performed from multiple security roles along with unauthenticated content testing, OWASP Top Ten vulnerabilities won't be detected.
I personally think authenticated security assessments from multiple security roles is an implicit requirement in the PCI DSS (unless you deploy a WAF) given that it specifies identifying OWASP Top Ten vulnerabilities. The fact is, you can't say you tested thoroughly for vulnerabilities if you failed to test half the application's content. If I'm right, this means that companies that have purchased unauthenticated web application security assessments, knowingly or inadvertently, have not fulfilled the DSS 6.6 requirement.