The main difference between our Basic and Standard web application security assessment services is that for Basic assessments, we only perform unauthenticated testing, unless of course we gain authenticated access through exploitation of some vulnerability. Our standard application security assessments test the application from both unauthenticated perspectives and authenticated perspectives of user roles in scope. Let’s briefly describe what I mean by unauthenticated and authenticated perspectives as well as authenticated roles.
- 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 aparticular 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.
While there are many reasons an organization may wish to identify vulnerabilities that exist from an unauthenticated perspective, there are many more reasons organizations should consider testing from both unauthenticated and authenticated perspectives.
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.
Obviously a vulnerability has to be discovered before it can be exploited, but many applications have a more exposed unauthenticated attack surface due to the triviality of gaining an account. Authenticated testing may not add the same value for applications which have a small amount of users, do not have sensitive authenticated functionality, have strict out-of-band user registration, or have a high level of trust for their users. However, for those applications that do have sensitive authenticated functionality, many users, or a low level of trust for their users, authenticated testing is usually recommended.
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.