Security is a non-functional feature that means securing users’ personal data and payment info from third-party users or ensuring specific people have related permission to do specific actions. Risky points that can cause personal data exposure are named vulnerabilities.

As time goes on new kinds of vulnerabilities or new ways to use existing vulnerabilities show up and it is critical to find ways to defend against these conditions. For this reason, OWASP (Open Web Application Security Project) was launched in 2001 and became a non-profit organization in 2004. This organization improves the security of software to make it safer.

OWASP introduced OWASP Top 10 in 2003 to draw attention to the most common vulnerabilities on the market. This top 10 list is updated every 2 or 3 years. Currently, the list’s last updated version is its 2021 version. Here are the most common vulnerabilities in web applications as of 2021:

1. Broken Access Control
2. Cryptographic Failures
3. Injection
4. Insecure Design
5. Security Misconfiguration
6. Vulnerable and Outdated Components
7. Identification and Authentication Failures
8. Software and Data Integrity Failures
9. Security Logging and Monitoring Failures
10. Server-Side Request Forgery (SSRF)

Now, let’s see what these top 10 vulnerabilities are, what are their impacts, and how to prevent them.

In order to understand broken access control, we need to understand what authentication and authorization are. Basically, authentication is proof of who we are, like an ID card and authorization defines what we’re allowed to do. In systems, there are user groups (admins, moderators, users, etc.) and all of these groups have permissions to do specific actions. Just like the way an ID card doesn’t grant access to a lab, logging in to the system shouldn’t grant you access to admin controls. Broken access control is a kind of vulnerability that makes a user that should have limited access to gain access to higher tiers of their position in the system. As a result of this vulnerability, the attacker can access sensitive data and even modify it. To prevent this, it is highly recommended to not solely rely on user data, check access rights on every level (UI and server levels), and deny access by default.

In systems, there are all kinds of personal information that is to be kept secret, like payment info, social security numbers, and health records. To ensure that the data is secured, some techniques and cryptographic algorithms are used. It is critical to do this in an impenetrable and unpredictable way. If this process fails at some point, it means that critically sensitive data is exposed, and the impact of this situation can affect business continuity. As prevention, it is recommended to always obscure data and use updated cryptographic algorithms.

It is a kind of vulnerability that occurs when:

• User-supplied data is not validated, filtered, or sanitized by the application.
• Dynamic queries or non-parameterized calls without context-aware escaping are used directly in the interpreter.
• Hostile data is used within object-relational mapping (ORM) search parameters to extract additional, sensitive records.
• Hostile data is directly used or concatenated. The SQL or command contains the structure and malicious data in dynamic queries, commands, or stored procedures.

As a result of any of these conditions, data can be stolen, modified, or even deleted. To prevent injection, it is recommended to use the latest frameworks and reject untrusted/invalid input data.

Insecure design is basically a failure to use security by design methods/principles resulting in a weak system. The impact of insecure design is a breach of confidentiality, integrity, and availability. To prevent insecure design flaws, security checks should be implemented on every step of SDLC, using manual (code review, threat modeling) and automated (SAST and DAST) methods to improve security. You can see the difference between an insecure and a secure design below.

As an example of this vulnerability in 2018, Intel optimized the design for performance so that the CPUs would perform better. Insecure design in this process has led to problems named Meltdown and Spectre.

Spectre is a vulnerability allowing for arbitrary locations in the allocated memory of a program to be read and Meltdown is a vulnerability allowing a process to read all memory in each system. Both vulnerabilities enable attackers to extract encryption keys and passwords from compromised systems, enabling other attacks dependent on access to compromised systems.

Security misconfiguration includes many different definitions, these are:

• Missing appropriate security hardening across any part of the application stack or improperly configured permissions on cloud services.
• Unnecessary features are enabled or installed (e.g., unnecessary ports, services, pages, accounts, or privileges).
• Default accounts and their passwords are still enabled and unchanged.
• Error handling reveals stack traces or other overly informative error messages to users.
• For upgraded systems, the latest security features are disabled or not configured securely.
• The security settings in the application servers, application frameworks (e.g., Struts, Spring, ASP.NET), libraries, databases, etc., are not set to secure values.
• The server does not send security headers or directives, or they are not set to secure values.

The impact of this vulnerability depends on the situation. It can vary from personal data leak to complete loss of the entire system.

To prevent this vulnerability there are multiple recommendations which are:

• Development, QA, and production environments should all be configured identically, with different credentials used in each environment. This process should be automated to minimize the effort required to set up a new secure environment.
• A minimal platform without any unnecessary features, components, documentation, and samples. Unused features and frameworks should be removed or should not be installed.
• A task to review and update the configurations appropriate to all security notes, updates, and patches as part of the patch management process.
• A segmented application architecture provides effective and secure separation between components or tenants, with segmentation, containerization, or cloud security groups.
• Sending security directives (security headers) to clients.

It is not safe to use components that are outdated and components that have known vulnerabilities. Versions of used components should be known, and they should be updated regularly. If not, the system would be open to attacks.

The impact of this vulnerability is data exposure, and it may get worse depending on the situation.

To prevent these kinds of vulnerabilities, it is recommended to remove unnecessary features, and unused dependencies, obtain components from official sources over secure links, prefer signed packages to reduce the chance of including a modified, malicious component, and monitor for libraries and components that are unmaintained or do not create security patches for older versions.

The Heartbleed Bug on OpenSSL 1.0.1 through 1.0.1f (after the heartbeat extension) can be given as an example of these kinds of vulnerabilities.

Heartbeat is a request-response model, the client requests a heartbeat request with some payload and length of payload. The receiving peer just sends back the same payload. Heartbleed, however, is a malicious heartbeat request with a small payload and large length field to the vulnerable party to elicit the victim’s response, permitting attackers to read up to 64 kilobytes of the victim’s memory that were likely to have been used previously by OpenSSL.

To understand it better in a Heartbeat request client sends the request as “Send me this 5-letter word: ‘light’ to keep the connection alive” and the server sends the response as “light”.

In a malicious heartbeat request, the client sends the request as “Send me this 500-letter word: ‘light’ to keep the connection alive” and the server responds “light” and fills the following 495 letters with subsequent characters the server happened to have in active memory. The leaked data can include encryption keys, user credentials, and protected content.

Confirmation of the user’s identity, authentication, and session management is critical to protect against authentication-related attacks. There may be authentication weaknesses if the application:

• Permits automated attacks such as credential stuffing.
• Permits brute force or other automated attacks.
• Permits default, weak, or well-known passwords.
• Uses weak or ineffective credential recovery and forgot-password processes, such as “knowledge-based answers,” which cannot be made safe.
• Uses plain text, encrypted, or weakly hashed password data stores.
• Has missing or ineffective multi-factor authentication.
• Exposes session identifier in the URL.
• Reuse session identifier after successful login.
• Does not correctly invalidate Session IDs.

The impact of this vulnerability is the attacker taking the identity of another user or even the admin.

To prevent this vulnerability, default credentials should not be used, multi-factor authentication should be implemented, and failed login attempts should be limited or delayed increasingly.

Software and data integrity failures relate to code and infrastructure that do not protect against integrity violations. Many applications now include auto-update functionality, where updates are downloaded without sufficient integrity verification and applied to the previously trusted application. Attackers could potentially upload their own malicious updates to be distributed and run on all installations.

The impact of this vulnerability is data exfiltration and supply chain attacks which affect all users that auto-update their app.

To prevent this, the use of digital signatures or similar mechanisms to verify the software or data is from the expected source and has not been altered is highly recommended. Also, the use of unconnected back-ups is recommended.

Solarwinds Attack in 2020 can be given as an example of these kinds of vulnerabilities. Hackers inserted their malicious code into Orion system. The attack is estimated to infect more than 18,000 systems worldwide, causing irreparable damage worth billions of dollars.

It is important to monitor what’s going on with the system to identify any suspicious acts or attacks.

If logging and monitoring are not done correctly, the security breaches can’t be identified, and correct actions can’t be taken.

To prevent this, it is crucial to ensure all login, access control, and server-side input validation failures can be logged with sufficient user context to identify suspicious or malicious accounts and held for enough time to allow delayed forensic analysis. The logs are generated in a format that log management solutions can easily consume and data is encoded correctly to prevent any injections to prevent attacks on the logging and monitoring systems.

Server-side request forgery flaws occur when a web application is fetching a remote resource without validating the user-supplied URL. Basically, an attacker sends a malicious request to a database server impersonating a web server and the database server trusts this input and executes it.

The impact of this vulnerability is the attacker accessing sensitive data.

To prevent SSRF, all client-supplied input data should be validated, HTTP redirections should be disabled, and raw responses should not be sent to clients.

Security, an essential non-functional feature, aims to protect users’ data and ensure permissions are correctly set. Vulnerabilities, which can expose personal data, evolve over time. OWASP Top 10 is an efficient list of risks in a system, but it doesn’t cover all the vulnerabilities we need to be aware of.

OWASP continues to make web applications safer with their products and OWASP Top 10. Who knows how this list will be changed in the next update?

• https://www.udemy.com/course/web-application-security-for-absolute-beginners-no-coding/
• https://en.wikipedia.org/wiki/Heartbleed
• https://www.prplbx.com/resources/blog/ssrf-guide/