Top 25 Coding Errors Leading to Software Vulnerabilities
Is your software free from coding vulnerabilities? Software vulnerabilities are caused by configuration or common coding errors in software engineering that actually can be avoided or fixed. To help you improve cyber security in your system, here is a review of the most commonly occurring and exploited software weaknesses reported by MITRE (CWE Top 25 2023) and OWASP (OWASP Top 10 2021).
Contents
- Collection and Rating Methodologies
- When in the SDLC Do Most Coding Errors Happen?
- The Most Vulnerable Programming Perspectives Revealed
- How to Avoid Common Software Vulnerabilities and Exploits?
- FAQ
Cyber security is one of Waverley’s strong area of expertise and we are often asked to handle complex software security issues. The wide variety of customer’s problems we address gives us a broad perspective on what can go wrong and where a system can be susceptible to a security breach.
In this article, we summarize the most common software vulnerabilities brought to light by the software engineering community, explain how these weaknesses can be exploited to affect a company’s operations, and, lastly, how businesses and developers can protect software systems from cyber-attacks.In our analysis we use the lists of the most critical errors in source code resulting in security vulnerabilities regularly updated by MITRE and OWASP – non-profit organizations working on improving software security that our teams reference when mitigating cyber security threats. The latest software vulnerability listings were issued in 2023 by MITRE and in 2021 by OWASP.
Collection and Rating Methodologies
The mission of MITRE and OWASP (Open Web Application Security Project) is to reduce cybercrime by improving software security and finding solutions for technology issues. They provide the lists of the most critical security defects in code that leave your systems vulnerable and result in serious security risks. The initiative helps developers, quality assurance specialists, project managers, researchers, and other people working in the industry and brings more cyber security awareness to the IT community.
Here we focus on the MITRE’s 2023 CWE (Common Weakness Enumeration) Top 25 Most Dangerous Software Weaknesses and the OWASP’s 2021 Top 10 Web Application Security Risks lists. Compiled through surveys and personal interviews with members of the IT community, the lists contain mistakes observed in the real-world programming practice.
In the CWE Top 25 2023 list, MITRE ranges software weaknesses by score. The factors they use are the ease of finding a weakness and it’s exploitation severity, which come from public reports. MITRE also provides extensive lists of known software weaknesses organized in graphs and tables for the convenience of software developers, architects, and researchers well as detailed weaknesses descriptions, their relationships with one another, origin, mitigation strategies, etc.
We carefully examined the Top 25 list to see which software development aspects face the most of high-severity and easily exploitable risks:
| Aspect | Weakness | Position in Top CWE | Occurs during | Applicable to |
|---|---|---|---|---|
| Improper Control of a Resource Through its Lifetime | CWE-787: Out-of-bounds Write | #1 | implementation | C, C++, Assembly languages |
| CWE-125: Out-of-bounds Read | #7 | implementation | C, C++ | |
| CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer (Buffer overflow) | #17 | implementation | C, C++, Assembly languages | |
| CWE-416: Use After Free | #4 | implementation | C, C++ | |
| CWE-502: Deserialization of Untrusted Data | #15 | Architecture and design, implementation | Java, Ruby, PHP, Python, JavaScript | |
| CWE 918: Server-Side Request Forgery(SSRF) | #19 | Architecture and design, implementation | Not Language-Specific | |
| CWE-276: Incorrect Default Permissions | #25 | Architecture and design, implementation, installation, operation | Not Language-Specific | |
| Data neutralization | CWE-79: Improper Neutralization of Input During Web Page Generation (‘Cross-site Scripting’) | #2 | implementation | Not Language-Specific |
| CWE-89: Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’) | #3 | implementation | Not Language-Specific | |
| CWE-78: Improper Neutralization of Special Elements used in an OS Command (‘OS Command Injection’) | #5 | implementation | Not Language-Specific | |
| CWE-20: Improper Input Validation | #6 | Architecture and design, implementation | Not Language-Specific | |
| CWE-77: Improper Neutralization of Special Elements used in a Command (‘Command Injection’) | #16 | implementation | Not Language-Specific | |
| CWE-94: Improper Control of Generation of Code (‘Code Injection’) | #23 | implementation | Interpreted languages | |
| Access control issues | CWE-862: Missing Authorization | #11 | Architecture and design, implementation, operation | Not Language-Specific |
| CWE-287: Improper Authentication (Broken Authentication) | #13 | Architecture and design, implementation | Not Language-Specific | |
| CWE-798: Use of Hard-coded Credentials | #18 | Architecture and design | Not Language-Specific | |
| CWE-306: Missing Authentication for Critical Function | #20 | Architecture and design | Not Language-Specific | |
| CWE-269: Improper Privilege Management | #22 | Architecture and design, implementation, operation | Not Language-Specific | |
| CWE-863: Incorrect Authorization | #24 | Architecture and design, implementation, operation | Not Language-Specific | |
| CWE-276: Incorrect Default Permissions | #25 | Architecture and design, implementation, installation, operation | Not Language-Specific | |
| Protection mechanism failure | CWE-352: Cross-Site Request Forgery (CSRF) | #9 | Architecture and design | Not Language-Specific |
| CWE-798: Use of Hard-coded Credentials | #18 | Architecture and design | Not Language-Specific | |
| File-handling issues | CWE-22: Improper Limitation of a Pathname to a Restricted Directory (‘Path Traversal’) | #8 | implementation | Not Language-Specific |
| Handler errors | CWE-434: Unrestricted Upload of File with Dangerous Type | #10 | Architecture and design, implementation | ASP.NET, PHP |
| Pointer issues | CWE-476: NULL Pointer Dereference | #12 | implementation | C, C++, Java, C#, Go |
| Numeric errors | CWE-190: Integer Overflow or Wraparound | #14 | implementation | Not Language-Specific |
| Communication Channel Errors | CWE 918: Server-Side Request Forgery (SSRF) | #19 | Architecture and design, implementation | Not Language-Specific |
| Insufficient control flow management | CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization (‘Race Condition’) | #21 | Architecture and design, implementation | C, C++, Java |
As we can observe in the pie-chart below, out of the 10 development aspects revealed in the Top 25 CWEs list, the most vulnerable ones are Resource Control, Data Neutralization, and Access Control, including the majority (nearly 75%) of the listed software weaknesses (some weaknesses fall under two or more development aspects).
Meanwhile, the OWASP Top 10 2021 list of security risks takes a more domain-specific approach and focuses solely on web application development vulnerabilities. The organization relies upon the MITRE’s Common Weakness Enumeration and evaluates software weaknesses primarily based on the weakness incidence rate that is the number of applications within the available dataset in which the instances of a weakness were found in. In addition, OWASP’s scoring system also includes such factor as the weaknesses’ potential impact. Thus, unlike MITRE, OWASP comes up with the list of Top 10 risk categories for web developers rather than separate weaknesses:
| Risk category | Average incidence rate | Number of CWE occurences | Average impact |
|---|---|---|---|
| #1 – Broken access control | 3,81% | 318k of 34 CWEs | 5,93 |
| #2 – Cryptographic failures | 4,49% | 233k of 29 CWEs | 6,81 |
| #3 – Injections | 3,37% | 274k of 33 CWEs | 7,15 |
| #4 – Insecure design (new) | 3% | 262k of 40 CWEs | 6,78 |
| #5 – Security misconfigurations | 4,51% | 208k of 20 CWEs | 6,56 |
| #6 – Vulnerable and outdated components | 8,77% | 30k of 3 CWEs | 5 |
| #7 – Identification and authentication failures | 2,55% | 132k of 22 CWEs | 6,50 |
| #8 – Software and data integrity failures | 2,05% | 47k of 10 CWEs | 7,94 |
| #9 – Security logging and monitoring failures | 6,51% | 53k of 4 CWEs | 4,99 |
| 10# – Server-side request forgery | 2,72% | 9k of 1 CWE | 6,72 |
Common code vulnerabilities can occur at any stage of the software development life cycle: during design and architecture as well as during implementation and operation. Flaws can also occur across different programming languages and computer system components, which can result in various types of vulnerabilities in code.
When in the SDLC Do Most Coding Errors Happen?
In the course of our analysis of the MITRE and OWASP weaknesses lists, we discovered an interesting fact. Certain computing concept areas seem to be more prone to various types of software vulnerabilities than the other. This is due to a higher amount and frequency of potentially dangerous and often exploited faults.
Based on the top weaknesses lists provided by MITRE and OWASP, we tried to find out when most of the coding errors take place. Naturally, most of the MITRE’s Top-25 weaknesses are also the members of the OWASP’s Top-10 weakness categories, however some appear to be classified under different categories by the organizations. For example, CWE-22 Path Traversal appears in both lists but falls under File Handling Issues section in MITRE’s classification while it’s mentioned in the Broken Control Access in OWASP’s Top-10.
Thus, in this article, we discuss top coding vulnerabilities as classified into software development categories that might be under threat if common software weaknesses take place.
The Most Vulnerable Programming Perspectives Revealed
Resource Control
Buffer Overflow. The software weakness commonly known as “buffer overflow” is ranked #17 on the CWE Top 25 2023 list while its subcategory Out-of-bounds Write tops the list and another one – Out-of-bounds Read takes the seventh position.
The buffer overflow failures happen when the memory buffer is set to receive more data than its capacity permits. Then, in the course of program execution, the data are written outside of the memory block. As a result, read or write operations can be conducted from a location outside the buffer limits. Due to buffer overflow, an unauthorized user can exploit this security vulnerability fairly easily. They can execute malicious code, read sensitive data, or change the control flow in the program.
Improper System Resource Allocation or Consumption. Software vulnerabilities may occur with limited system memory, file storage, or CPU capacity. This code vulnerability type typically arises when crucial system resources are:
- not released after the end of software effective lifetime
- referenced after being previously freed
- not controlled by the systems
These faulty conditions are caused by the confusion: it is unclear which program component is responsible for which resource. This creates a “hole” or vulnerability in the system giving hackers a loophole to perform their attacks. The attacks, in turn, can cause a denial-of-service state (aka DoS attack), crash a program, or execute malicious code. Another potential consequence of these coding errors is a memory exhaustion attack, which can slow down your program and its hosting OS.
Server-Side Request Forgery (SSRF). This software vulnerability is listed as a separate risk category by OWASP and belongs to both resource control and communication channel categories of issues according to MITRE. It allows an attacker to use a web application’s back-end server to send crafted requests to an unexpected destination and bypass the available access controls. This happens when an application does not validate URLs provided by the user. As a result, hackers can get access to sensitive data on local files, internal servers, or cloud metadata storage as well as use internal services for such malicious actions as remote code execution, denial-of-service attacks, and port scanning of hosts.
Data Processing
Most common coding weaknesses that belong to this category are also called “injections” which make an application vulnerable when attackers get to modify and compromise data, commands, and queries that the system has to process. Such coding errors include:
- cross-site scripting
- SQL injection
- code injection
- OS command injection
Computer programs use queries and commands for their components to communicate. If these messages are missing proper encoding, hackers can use this vulnerability to tamper with the application. With SQL injection or XSS, they can insert special characters that cause the data to be interpreted as control information for the program. This way, coding errors let certain software components receive malicious commands and perform the wrong operations.
Improper Handling of Sensitive Information. Unlike buffer overflow, for example, this category of weaknesses is language-independent and includes software flaws such as:
- sensitive data exposure
- cryptographic issues
- insufficient or excessive logging
Computer programs use queries and commands for their components to communicate. If these messages are missing proper encoding, hackers can use this vulnerability to tamper with the application. With SQL injection or XSS, they can insert special characters that cause the data to be interpreted as control information for the program. This way, coding errors let certain software components receive malicious commands and perform unexpected or unintended operations.
Read more:Code Review: Best Practices
Security Weaknesses
Access Control. The category access control weaknesses shares the position with data neutralization issues as second most likely reason for vulnerabilities following the CWE classification. At the same time, broken access control is #1 risky category according to OWASP. Here are some of the most common access control software vulnerability examples:
- improper, incorrect or missing authorization
- improper, incorrect or missing authentication
- weak credentials management (for instance, the use of hard-coded passwords)
- privilege management issues
The core problem with access control vulnerabilities is the incorrect security configuration of the system and component access controls. How does this happen? Quite often, software components come with default security settings. Far too often programmers fail to pay enough attention to adjusting access controls to the custom security terms and requirements. They may also ignore the principle of least privilege – a user or process must be given only the privileges needed to perform its intended function.
Computer applications end up getting deployed without the required security features, for example, properly set authorization and authentication procedures. As a result, users risk their accounts becoming vulnerable, an easy target for cyber-attack. When attackers take advantage of the developers’ coding errors, password security is compromised, hackers get control of the systems and devices. Exploiting security vulnerability through malicious code execution, they may also gain access to sensitive information.
Cross-Site Request Forgery is ranked #9 on MITRE’s Top 25 CWE list. It is a composite software weakness involving additional erroneous conditions including:
- origin validation error
- confused deputy
- external control of critical state data
- insufficient session expiration.
These programming mistakes may overlap resulting in a web application that cannot verify whether an incoming server request was intentional or not. Hackers can easily detect and exploit these coding errors in web applications. They trick the systems into sending false unintentional requests to the server. In the end, such requests will be treated as valid ones.
Improper Handling of Sensitive Information. OWASP also pays great attention to cryptographic failures, listing this category as second most risky one. It includes software flaws such as:
- hard-coded password
- broken or risky crypto algorithm
- insufficient entropy
Cryptographic coding errors lead to intentional or unintentional sensitive information disclosure to unauthorized users. This software vulnerability allows hackers to perform cyber-attacks, commit fraud, or steal identities. They utilize sensitive information including credentials, credit card numbers, health records and so on. If your organization is dealing with your customers’ private information, your reputation is threatened. If your customers are based in Europe, you’re also likely to be cited for non-compliance by the GDPR.
Insecure Design and Business Logic. A new category in the latest list from OWASP and high in the rating (#4), it stresses the importance of considering security aspects long before application implementation – at the design and architecture stage. Provided there are flaws in the business logic of an app, this will leave a hole in security for cyber criminals, no mater how flawless the implementation is.
For example, in a booking app, the functionality may allow users to book a certain amount of items without prepayment and any additional validation, thus providing the way for malicious actors to easily exploit a software feature with a weakness in their interest. This is why it is important to involve security professionals and software testing specialists as early as the architecture and design stage of the development cycle – to make sure you have a well thought-through system.
Security Misconfiguration and Incorrect Default Permissions. When access permissions are granted to a wider range of users than needed, it poses a substantial cyber security risk. For example, developers may set loose permissions to avoid possible complications during the first application run. This makes software operation during the installation stage easier for the user, however, it is expected that the permission parameters will be tightened later on. Sometimes this crucial step doesn’t happen because the users or even system administrators fail to read the documentation carefully and continue to use default accounts and passwords without changing them as recommended.
Another reason why an application can be vulnerable is the use of unnecessary features and components which only make your system more exposed to potential attackers. Also, if a system has upgraded recently, security settings may return to default parameters and, unless reviewed and set to secure values, can make an app easier to break.
Other Software Weaknesses
- Numeric: Integer Overflow/Wraparound. A subcategory of incorrect calculation issues. Basically, this means that software is performing calculations that lead to unexpected results. This vulnerability affects resource management and execution control.
- Pathname: Path Traversal. Cyber – intruders can use special elements to provide external input to construct a pathname. This gives them access to files or folders outside the restricted directory. It is also known as a dot-dot-slash attack: attackers use a sequence of ../ characters to traverse the root directory. Due to this software vulnerability, hackers can read files with sensitive data. They may also create, overwrite or delete vital security files, as a result of coding errors.
- Pointer: Null Pointer Dereference. The null pointer indicates that the pointer is not referring to a valid object. When the null pointer is dereferenced, it typically causes a run-time error or immediate program crash. The inventor of the null pointer, Tony Hoare, called it his “billion-dollar mistake.” As he commented, it lead to numerous software vulnerabilities and system crashes that caused tremendous damage to users and businesses. No wonder the related software weakness is now listed as one of the Top 25 CWE in 2019.
- Handler: Unrestricted Upload of File with Dangerous Type. This programming fault prevails in web server technology as a resource consumption issue. The size or number of uploaded files is not restricted so attackers can simply upload malware in the form of files that get automatically processed afterward. As a result, an uploaded file is interpreted and executed as code by the system. This coding error is especially typical of the PHP programming language. Such a vulnerability exists since, quite often, .php file types are treated as automatically executable.
- Channel: Untrusted Search Path. The attackers supply an external search path pointing to a location or database beyond the application’s direct control. The vulnerability allows them to implant malware, gain access to unauthorized data, and modify configurations. In this case, any type of critical source seen as trusted by the system may be under threat.
- Using Components with Known Vulnerabilities. This practice is hiding a tricky cyber security threat. Developers are often using ready-made application components to build complex systems and fail to check for bugs or software vulnerabilities in the library dependencies of those components. The known coding mistakes are fairly easy to detect so attackers who know the possible effects readily exploit them. The effects can be any of the inner software issues mentioned above. The consequences can range from trivial to severe.
- Insufficient Control Flow Management leading to ‘Race Condition’.
- Using Components with Known Vulnerabilities. This practice is hiding a tricky cyber security threat. Developers are often using ready-made application components to build complex systems and fail to check for bugs or software vulnerabilities in the library dependencies of those components. The known coding mistakes are fairly easy to detect so attackers who know the possible effects readily exploit them.. The effects can be any of the inner software issues mentioned above. The consequences can range from trivial to severe.
How to Avoid Common Software Vulnerabilities and Exploits?
Of course, any potential cyber security threats should be and can be prevented. You can handle some of them in-house, checking your code and operating systems on a regular basis. Others might require professional third-party assistance. Below is a list of security measures to protect your devices and systems, all of which are highly advisable and useful to employ.
- Don’t forget to update your operating systems and libraries. As soon as known software vulnerabilities in these products get documented, they come with patches. We strongly recommend running the updates in a testing environment beforehand to make sure they are safe.
- Reduce your exposure to possible attacks: disable, block and remove any system component you don’t use or don’t need and follow the least privilege principle in granting access rights to the system users.
- Follow the principle of least priviledge when setting system access permissions for users. With a role-based access control, each user must have the ability to only access those functions and information which they need to perform their tasks, and not more.
- Secure your network by means of endpoint restrictions, continuous monitoring, and penetration testing.
- Carefully check your system default security configurations and make custom settings, if needed.
- Introduce automation into your operations to avoid man-made mistakes.
- Inspect and monitor your computer service providers’ security policies to detect possible security threats for you.
- Use trusted and reliable resources of external dependencies you use to build software.
- Make sure your staff is aware of the basic cybersecurity practices and measures.
- Write your code and design architecture with security in mind: make it clear and easy to read.
- Devise a back-up plan in case of an emergency situation to quickly recover and learn from your mistakes.
- Stay up-to-date with the latest news and useful articles related to cybersecurity issues.
- Never postpone fixing your bugs, especially before moving on with the project.
- Consider turning to cybersecurity companies for security risk assessment, audit and security consulting services.
- Don’t hesitate to contact professional cybersecurity providers for attack mitigation and incident handling when in need.
FAQ
What is code vulnerability?
Code vulnerabilities are software flaws that open opportunities for potential application misuse, exploits, or breaches that result in sensitive information disclosure, data leaks, ransomware attacks, and other cyber security issues. Code vulnerabilities emerge when coding errors are made in the process of software development. Such errors are also called coding weaknesses as they make application code weak and easy to break for hackers.
What are common software vulnerabilities and why should I be concerned about them?
The list of software vulnerabilities is quite elaborate as there are many factors to take into account when writing secure code. Technologies are constantly developing and so are the attack approaches: hackers keep finding new, yet unknown ways to exploit software. Such non-profit organizations as MITRE and OWASP conduct regular surveys and researches within the development community in order to reveal most common, dangerous, and new flaws in application code, as well as define their causes and possible mitigations. As a result of such research, they provide the list of most common software weaknesses which is updated on a regular basis.
Despite certain changes and new findings, some software weaknesses keep their top positions in the list year by year. For example, such weakness as buffer overflow, various types of injections, encryption issues, missing or incorrect authorization and authentication, improper credentials management, inadequate privilege management, path traversal, cross-site request forgery, and server-side request forgery are rather widespread. Also, quite often, attackers manage to break software systems due to low cyber security awareness of software users.
Thus, it is crucial for both software developers and users to be aware of common software vulnerabilities and coding weaknesses causing them – to create secure applications and use them wisely.
What are the potential consequences of software vulnerabilities and exploits?
Since cyber criminals are on the hunt for certain profit or advantage, they aim at what’s the most precious: secret or sensitive information and financial reward. And all this – at users’ cost. Therefore, if software that you or your company are using gets exploited, you risk having your personal or confidential information stolen or disclosed, business-critical systems blocked, bank accounts broken, reputation spoilt, and other destructive effects.
How can I identify if my software or system is vulnerable to attacks?
The best and most reliable option is to get the help of professionals. Software development and cyber security companies, such as Waverley Software, provide various cyber security services, including vulnerability scanning, penetration testing, and security audits to help companies evaluate their cyber security levels and make the necessary improvements – set up the DOS/DDOS attack protection, security monitoring and analytics, data back-ups and conduct incident response activities.
How to find vulnerabilities in software?
Cyber security and coding professionals use monitoring and analytics tools that help them track and spot suspicious activity within the system, unexpected application behavior, unwanted user actions, and other improper operations. Also, in the course of software development, Quality Assurance specialists check applications for bugs, including those that can affect application security. Another source of vital information about your system health can be user reports and customer support tickets that must be carefully analysed.
