by Christopher Duram

Penetration testers may come across a variety of vulnerabilities that need to be addressed in order to strengthen a client’s cybersecurity posture. However, some issues are more common than others. As the Elliott Davis penetration testing team reviewed the web application penetration tests conducted in 2022, we found several common web application vulnerabilities. Our assessment findings are mapped to the Open Web Application Security Project (OWASP) Top Ten. That Top Ten was created by OWASP to highlight the most commonly exploited web application vulnerabilities.

The current list (last updated Fall  2021) is:   

  • Broken Access Control
  • Cryptographic Failures
  • Injection
  • Insecure Design
  • Security Misconfiguration
  • Vulnerable and Outdated Components
  • Identification and Authentication Failures
  • Software and Data Integrity Failures
  • Security Logging and Monitoring Failures
  • Server-Side Request Forgery

The top three findings for web applications that Elliott Davis discovered were the following:  

1. Broken Access Control

Broken Access Control can be described as a user having access to unauthorized content. Some of the most common findings related to broken access control were privilege escalation, forced browsing to unauthorized pages whether authenticated or unauthenticated (often referred to as Insecure Direct Object Reference – IDOR), and unintended user enumeration where the web application’s application programming interface (API) or functionality allows the retrieval of another user’s usernames or user information. The image below shows a simple example of broken access control. A user has logged in to their mortgage company’s website and is being redirected to a loan account with an ID of 1000. By changing the ID to 1001, they find they can navigate to another customer’s loan account.

2. Security Misconfiguration

Security Misconfiguration is the situation that arises when a security control is misconfigured and allows an attacker to bypass it or leverage it to attack the web application. This could happen through a misconfiguration of an enabled control or simply the not enabling a security control. One example is the lack of a SecureFlag on session cookies. SecureFlag can prevent their theft if an attacker finds a way to inject JavaScript into the web application itself. Below is an image of the Elliott Davis website showing a secure flag set.

Another example of a security misconfiguration is development features that are left enabled on APIs after they are deployed into production. One example is the increasingly popular API GraphQL; by default GraphQL has introspection enabled. Introspection grants unauthenticated users the ability to analyze the entire schema of a GraphQL database, which can be especially useful for an attacker who wants to discover what can be queried.

The image below shows a tester performing an introspection request with Burp Professional (a popular tool for web security testing). The server responds by providing the entire schema for the GraphQL database.

3. Insecure Design

Insecure Design is a new category that OWASP added to the Top Ten with the 2021 release. This category is intentionally broad with the goal to help the industry “shift left” and focus on preventing web applications from being easily exploited before developers even begin coding. This category of vulnerability aligns with business logic flaws. For instance, if Multi-Factor Authentication (MFA) or a web CAPTCHA can be bypassed due to how the flow of authentication works, it would be considered a business logic flaw and fall under the Insecure Design category. The open authentication authorization flow below is an example of a customer’s custom implementation that could allow unintended access by not validating the data it is sending. In this authorization flow, a customer ID is looked up, and a Secure Messaging Service (SMS) sends a one-time password (OTP) code to the phone number on record. However, when the session token request is made, the server is not validating the customer ID that is being sent the response. Because of this, an attacker with access to an account can choose any other customer ID to submit with the OTP code and receive back a valid session token for that other customer account, thereby bypassing MFA.

Do I need a Web Application Penetration Test? If your organization has a web hosting site or server, including an email server, you are vulnerable to hackers. In a previous article, we discussed why web application testing should be performed regularly. Web applications are living tools that organizations use and push updates to regularly. While web applications may be secure when they are first deployed, changes over time often introduce new bugs. Incorporating manual penetration testing and threat modeling into a company’s Software Development Lifecycle (SDLC) before deployment can strengthen its overall security and help avoid some of these common issues.

We can help

Contact a team member to learn more about our penetration testing services.

The information provided in this communication is of a general nature and should not be considered professional advice. You should not act upon the information provided without obtaining specific professional advice. The information above is subject to change.