Each year Cobalt publishes The State of Pentesting report to explore common vulnerabilities and provide key security insights. The State of Pentesting 2022 report revealed that teams have been struggling to fix and prevent the same vulnerabilities for at least the past five years in a row. 

These top vulnerability categories include:

1. Server Security Misconfigurations
2. Cross-Site Scripting (XSS)
3. Broken Access Control
4. Sensitive Data Exposure
5. Authentication and Sessions

The majority of discovered vulnerabilities stem from not staying on top of configurations, software updates, or access management controls. In order to fix and prevent these issues, it’s important to first understand the more technical details.  

With that in mind, here’s a glossary of all the vulnerabilities we covered in our latest State of Pentesting report 

Stored Cross-Site Scripting (XSS) 

What is it? 

Here’s an example of how it works: A web form has a field that accepts user text input, then stores that input somewhere on the server’s database. An attacker accesses that web form and enters a line of code, which the server accepts and stores in the database. The next time a user pulls up data that includes the attacker’s input, their browser attempts to run the malicious code.

What about Reflected Cross-Site Scripting (XSS)? 

Here’s an example of Reflected XSS: An attacker creates a URL that contains a vulnerable parameter. When they send that URL to another user, the user’s browser accepts the code string and performs whatever actions it describes—for example, generating an alert box that prompts users to share sensitive information. The main difference between Stored and Reflected XSS, is that with Reflected XSS malicious content isn’t stored permanently on any database.

Note: While Stored and Reflected XSS attacks function differently, the methods for remediating them follow the same design principles.

How do you fix and prevent Cross-Site Scripting?

Overall, you should treat all user-supplied input as untrusted (or potentially malicious) data. This means taking the following steps while designing the application:

1. Only accept untrusted data input in select locations.
2. Create a whitelist of allowed characters.
3. Always sanitize input, encode output, or both, for any data that comes into or out of the application.
4. Use a well-known and secure encoding API for input and output encoding, such as the OWASP ESAPI, or research and use an existing output encoder.

Note: We do not recommend trying to write input and output encoders, unless absolutely necessary.

Broken Access Control: Insecure Direct Object References (IDOR)

What is it? 

Insecure Direct Object References (IDOR) can give access to resources via user-supplied input. Attackers could bypass authorization by modifying a value of a parameter that points directly to an object in your database.

Here’s an example: Due to the way a website or application handles resources, one customer’s file has the ID “file123” in the URL, which corresponds to that file’s location in the database.

An attacker who can access “file124” changes the resource ID number in the URL to a different number, such as “file123” and can view the other customer’s file.

How do you fix and prevent IDOR?

Use per-user or per-session indirect object references. For example, instead of using the resource’s database key, you could use a drop-down list of six resources authorized for the current user with the numbers “1” to “6” to indicate which value the user selected. The application then maps these per-user indirect references back to the actual database key on the server, and returns the requested information.

Check the user’s access when they try to view content. Each time the application uses a direct object reference from an untrusted source, the application should also make an access control check to ensure that the user is authorized to access the requested object.

Components With Known Vulnerabilities: Outdated Software Versions

What is it? 

Let’s look at a recent example of a vulnerability that sidetracked development and security operations everywhere: the Log4j flaw. In late 2021, any team using the Apache Log4j library for logging and configurations was vulnerable to a remote code execution attack. Hackers could run code on vulnerable devices and take full control of them.

Apache issued a patch to fix this vulnerability on December 6th. It later became clear this patch didn’t fully address the problem, so they released another patch on December 13th.

How do you fix and prevent Outdated Software Versions?

The core of the problem is version management, which can add a lot to teams’ workloads when it takes dozens of apps and programs to keep a website, product, or business running. Staying on top of updates for all of them can quickly spiral out of control, which is why our pentesters recommend using an automated Vulnerability Management System to scan for software updates and notify the IT team when there are fixes to deploy.

Server Security Misconfiguration: Insecure SSL or TLS protocols

What is it: 

SSL stands for Secure Socket Layer, which is a type of protocol responsible for encryption, protecting the transfer of sensitive information like credit card details, Social Security Numbers, or other types of Personally Identifiable Information (PII).

Because SSL has serious cryptographic weaknesses, the next version of the protocol—TLS or Transport Layer Security—became available in 1999. There have been multiple security updates since then, but many servers still take connections using outdated versions of the protocol. What we recommend is that your servers accept TLS v 1.2 or higher.

How do you fix and prevent Insecure SSL or TLS protocols?

Use only the most up-to-date TLS protocols. Configure your servers to accept only TLS version 1.2 or 1.3. And, do not accept any Secure Sockets Layer (SSL) versions.

Note: For legacy clients that require insecure browsers (sorry, Internet Explorer), it may be necessary to enable TLS 1.0. However, if you need to be PCI DSS compliant (e.g. your company processes credit card information), this is strictly forbidden.

While you’re at it, now is also a good time to check your SSL certificates and make sure they have not expired.

Server Security Misconfiguration: Lack of Security Headers

What is it? 

Security Headers are a type of HTTP response header—code which instructs browsers how to display content and interact with a web page without any of that instruction rendering on the user’s screen.

Security headers regulate security features around that communication and can help mitigate different attacks, such as Clickjacking, XSS, and encryption-related downgrade attacks.

They can also strengthen privacy by enabling users to use their browsers’ security features such as disabling access to their webcam or microphone.

How to implement security headers:

Consider implementing the following recommended security headers, at a minimum:

• HTTP Strict-Transport-Security (HSTS)
• X-Frame-Options
• X-Content-Type-Options 
• Content-Security-Policy (CSP)
• X-Permitted-Cross-Domain-Policies
• Cross-Origin-Resource-Policy (CORS)

For more information on these and other headers that your servers may need, see the OWASP Secure Headers Project.

Broken Access Control: Username or Email Enumeration

What is it? 

A login portal or forgotten password interface, or similar web feature, prompts users to enter their username or email address. When a user enters a valid response, the server displays a message saying it’s valid (such as “We are sending a password reset email”). When they enter an invalid response, the server displays a different message (like, “user not found”). 

An attacker can use different responses to determine what items on a list of potential usernames and email addresses are valid. This could be a list of identified users from past breaches or guesses based on common first and last names in Census data. The attacker could then use their list of legitimate usernames to conduct further attacks against users, such as password spray or brute-force attacks.

How to prevent Username or Email Enumeration:

Ensure that the application does not reveal existing user names or any data associated with them, whether because of a misconfiguration or a design decision. For example, the message could respond to all requests, valid or invalid, with “If this account exists, we will send a password reset email to the address on file.” 

Weak SSL Configuration: Insecure Cipher Suites

What is it? 

Related to the Insecure TLS detailed above, an Insecure Cipher Suite refers to the method by which secured data is encrypted. Ciphers are the secret codes used to encrypt information and make it impossible to read without knowing the cipher itself. 

The goal is to ensure that people other than the intended recipient can’t decode the message. However, some suites of ciphers are old enough that they have been “broken,” and can be reliably translated back into the original text.

How to fix Insecure Cipher Suites:

Create a shortlist of cipher suites that your servers accept, and use only those. Select only cipher suites that offer 128-bit encryption. Configure the server to use only strong cipher suites, which include AES ciphers at 128 bits or higher, TDES/TDEA triple-length keys, and RSA at 2048 bits or higher.

Lack of Binary Hardening: Lack of Jailbreak Detection

What is it? 

When a mobile device has been jailbroken, someone has installed a custom version of the Operating System on the device that gives them higher levels of user permissions than the out-of-the-box version. This is sometimes called “rooting” when it gives the user root access to their device.

How to fix and prevent Lack of Jailbreak Detection:

Implement mechanisms to detect whether the application is running on a jailbroken or rooted mobile Operating System. This blocks some of the tools and techniques reverse engineers like to use. 

Like most other types of defense, jailbreak detection is not very effective by itself, but scattering checks throughout the app’s source code can improve the effectiveness of the overall anti-tampering scheme.

Mobile Security Misconfiguration: Absent SSL Certificate Pinning

What is it?

Certificate pinning is the process of associating a backend server with a specific X.509 certificate or public key instead of accepting any certificate signed by a trusted Certificate Authority. 

After storing, or “pinning”, the server certificate or public key, the mobile app will only connect to the known server. This instructs the application not to trust external Certificate Authorities, which reduces the attack surface.

How to fix and prevent Absent SSL Certificate Pinning:

Pin and hard-code the certificate into the application. For more information, see the OWASP cheat sheet on Certificate Pinning: https://owasp.org/www-community/controls/Certificate_and_Public_Key_Pinning

Insecure Data Storage: Sensitive Application Data Storage Unencrypted

What is it?

A vulnerable application stores cleartext sensitive information (such as usernames and passwords, PII, credit card data, or Social Security Numbers (SSN), depending on the application) within a resource that a user with the correct permissions could access. 

Even if the information is encoded and not human-readable, an attacker could use various techniques to determine which encoding is being used, then decode the information.

How to fix and prevent Insecure Data Storage:

Configure the application to store any sensitive information in an encrypted format and resource. 

OWASP also recommends performing threat modeling on your application, to determine how it handles the following features: 

• URL caching (requests and responses) 
• Keyboard input cache 
• Copy/Paste buffer cache 
• Backgrounded application 
• Intermediate data 
• Logging 
• Stored HTML5 data 
• Browser cookie objects 
• Third-party analytics data

Server-Side Include (SSI) Injection

What is it?

Some servers' configurations allow coders to include pieces of code that get processed before the rest of the page does. This could be a line of code that displays the user’s name on every webpage, for example. However, if the server doesn’t validate whether these Server-Side Includes (SSI) are from a legitimate source, an attacker could include their own code, which the server will execute.

By executing the command, the server or application could give an attacker a privilege or capability that the attacker would not otherwise have, such as accessing a password file, conducting a port scan, or even opening a command shell. 

Command injection can be an issue with wrapper programs.

How to fix and prevent Server-Side Include (SSI) Injection:

The most effective method of eliminating Code Injection vulnerabilities is to avoid allowing software to evaluate code unless absolutely and explicitly necessary. 

However, if there is no way to achieve the same result without code evaluation, ensure that any user input is validated very strongly, placing as many restrictions as possible on that user input.

Server Security Misconfiguration: Using Default Credentials

What is it?

When an application, Operating System, networked device, or other piece of software is installed, it may include pre-configured login credentials for an Administrative panel, or it may create this account with a generated password during setup. 

This Admin username and password may be written in some published documentation, or it may be available on the Internet. If this password is predictable, and no one changes it on the first access, an attacker could simply look up the password and gain unauthorized access to the application. 

How to fix and prevent Server Security Misconfiguration: Using Default Credentials:

1. Never use default credentials as it is trivial for an attacker to gain access by providing known or easy-to-guess credentials. 
2. Implement a process to change any default credentials as the first step of setting up any kind of environment.
3. Ensure that all passwords meet or exceed proper password strength requirements. Cobalt recommends at least 12 characters, with complex characters (symbols, capital letters, numbers). Longer passwords are more difficult to crack. 
4. If possible, consider disabling external access for systems with Administrative features.

—

Consider using security assessments like pentesting, which can be useful for development teams to patch vulnerabilities and remediate risk. You can also learn about these and other vulnerabilities on the OWASP, SANS CIS Controls, and CVE websites. Download The State of Pentesting 2022 for more information and key insights to ensure critical business assets remain fully protected.