Attackers may use a variety of paths through your application to harm an organization. Each of these paths represents a risk that may or may not be significant enough to warrant consideration.
Sometimes finding and exploiting these paths is simple, while other times, it is extremely difficult. Similarly, the harm done may be insignificant or put you out of business.
To assess the risk to your organization, consider the likelihood of each threat agent, attack vector, and security flaw and an estimate of your organization’s technical and business impact. These elements work together to determine your overall risk.
In this post, we will list out the top 10 vulnerabilities highlighted by the Open Web Application Security Project (OWASP), an open community dedicated to enabling organizations to develop, purchase, and maintain applications and APIs that can be trusted.
When a hacker sends invalid data to a web application, it causes it to do something other than what the application was designed/programmed to do. SQL, NoSQL, OS, and LDAP injection flaws occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can lead to the interpreter executing unintended commands or accessing data without authorization.
2. Broken Authentication
An attacker with a broken authentication vulnerability can use manual or automatic means to gain control of a user account – or, worse, complete control of the system. Broken authentication vulnerabilities are common on the internet. Broken authentication typically refers to logic issues in the application authentication mechanism, such as poor session management, making username enumeration possible.
Application authentication and session management functions are frequently implemented incorrectly, allowing hackers to compromise keys, passwords, or session tokens or exploit other implementation flaws to temporarily or permanently assume other users’ identities.
3. Sensitive data exposure
One of the most common vulnerabilities is the exposure of sensitive data. It comprises stolen PII (personally identifiable information) data that should have been encrypted. These are commonly referred to as data breaches.
Many web applications and APIs fail to adequately protect sensitive data, such as financial, healthcare, and personally identifiable information (PII). Attackers may steal or alter such vulnerable data to commit credit card fraud, identity theft, or other crimes. Without additional safeguards, such as encryption at rest or in transit, sensitive data may be compromised, necessitating special precautions when exchanged with the browser.
4. XML External Entities (XXE)
An XML External Entity attack is an attack on a program that parses XML input. This attack occurs when an XML parser with a poorly configured configuration processes XML input containing a reference to an external entity. Most XML parsers are vulnerable to XXE attacks by default, and an XXE can occur in deeply nested dependencies. As a result, it is primarily the developer’s responsibility to ensure that the application does not contain this vulnerability.
Many older or incorrectly configured XML processors evaluate external entity references contained within XML documents. External entities can access internal files through the file URI handler, internal file shares, internal port scanning, remote code execution, and denial of service attacks.
5. Broken Access Control
Access control in website security refers to limiting which sections or pages visitors can access based on their needs. For instance, if you own an eCommerce store, you will most likely require access to the admin panel to add new products or set up a holiday promotion. However, it is unlikely that anyone else would require it. Allowing the rest of your website’s visitors to access your login page only exposes your eCommerce store to attacks. That is the issue with nearly all major content management systems (CMSs). They grant global access to the admin panel by default. They will also not compel you to use a second-factor authentication method (2FA).
Restrictions on what authenticated users can do are frequently not enforced properly. Attackers can take advantage of these flaws to gain unauthorized access to functionality and/or data, such as gaining access to other users’ accounts, viewing sensitive files, modifying other users’ data, changing access rights, etc.
6. Security Misconfigurations
Hackers constantly look for new ways to breach websites, and security flaws are common. Unpatched flaws, default configurations, unused pages, unprotected files and directories, and unnecessary services are things that hackers typically try to exploit to gain unauthorized access.
Keeping the CMS default configurations is one of the most common webmaster flaws. Today’s CMS applications (while simple to use) can be tricky from a security standpoint for end users. The majority of attacks are completely automated. Many of these attacks rely on users only having the default settings enabled.
This means that many attacks can be avoided by changing the default settings when installing a CMS. Some CMS applications, for example, are user-writable, allowing the user to install whatever extensions they desire. You can change the settings to control comments, users, and the visibility of user information. Another example of a default setting that can be hardened is file permissions.
The most common problem is security misconfiguration. Insecure default configurations, incomplete or ad hoc configurations, open cloud storage, misconfigured HTTP headers, and verbose error messages containing sensitive information are common causes. All operating systems, frameworks, libraries, and applications must be configured securely, but they must also be patched and upgraded regularly.
7. Cross-Site Scripting (XSS)
Cross-Site Scripting (XSS) is a common vulnerability that affects many web applications. In XSS attacks, malicious client-side scripts are injected into a website and used as a means of propagation. XSS is dangerous because it allows an attacker to inject content into a website and change how it is displayed, forcing a victim’s browser to execute the code provided by the attacker while loading the page. XSS is found in roughly two-thirds of all applications. In general, XSS vulnerabilities require user interaction to be triggered through social engineering or by visiting a specific page. Any website can be jeopardized if an XSS vulnerability is not patched.
8. Insecure Deserialization
Insecure deserialization frequently results in remote code execution. Even if deserialization flaws do not allow for remote code execution, they can be used to launch attacks such as replay attacks, injection attacks, and privilege escalation attacks.
Insecure deserialization provides hackers with an attack vector that is most commonly used for remote code execution but can also be used to perform injection attacks, replay attacks, and privilege escalation attacks. The serialized information about the logged-in user is stored inside the supercookie, an example of insecure deserialization. An attacker could deserialize the cookie, modify it to grant himself/herself administrative privileges, and then serialize it again.
9. Using Components with Known Vulnerabilities
Open-source components such as libraries and frameworks are frequently used in modern distributed web applications. Any component with a known vulnerability becomes a weak link, compromising the application’s overall security. Although open-source components with known vulnerabilities rank low in terms of security problem severity, it ranks first in the OWASP Top 10 by how frequently a vulnerability was the actual cause of a data breach.
Libraries, frameworks, and other software modules, for example, run with the same privileges as the application. An attack that takes advantage of a vulnerable component can result in significant data loss or server takeover. Applications and APIs that use known vulnerable components may undermine application defenses and enable various attacks and impacts.
10. Insufficient Logging & Monitoring
Inadequate logging and monitoring, combined with missing or ineffective integration with incident response, enables attackers to continue attacking systems, maintain persistence, pivot to new systems, and tamper, extract, or destroy data. Most breach studies show that it takes more than 200 days to detect a breach, typically detected by third parties rather than internal processes or monitoring.