The new OWASP Top 10 helps to keep your Web Applications secure.

What is OWASP?

The Open Web Application Security Project, or OWASP, is an international non-profit organization dedicated to web application security. One of OWASP’s core principles is that all of their materials be freely available and easily accessible on their website, making it possible for anyone to improve their own web application security. The materials they offer include documentation, tools, videos, and forums. Perhaps their best-known project is the OWASP Top 10.

What is the OWASP Top 10?

The OWASP Top 10 is a regularly-updated report outlining security concerns for web application security, focusing on the 10 most critical risks. The report is put together by a team of security experts from all over the world. OWASP refers to the Top 10 as an ‘awareness document’ and they recommend that all companies incorporate the report into their processes in order to minimize and/or mitigate security risks.

OWASP Top 10 -2021

Below are the security risks reported in the OWASP Top 10 2021 report:

1. Broken Access Control

Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification, or destruction of all data or performing a business function outside the user’s limits. Common access control vulnerabilities include:

  • Violation of the principle of least privilege or denial by default, where access should only be granted for particular capabilities, roles, or users, but is available to anyone.
  • Bypassing access control checks by modifying the URL (parameter tampering or force browsing), internal application state, or the HTML page, or by using an attack tool to modify API requests.
  • Permitting viewing or editing someone else’s account, by providing its unique identifier (insecure direct object references)
  • Accessing API with missing access controls for POST, PUT and DELETE.
  • Elevation of privilege. Acting as a user without being logged in or acting as an admin when logged in as a user.
  • Metadata manipulation, such as replaying or tampering with a JSON Web Token (JWT) access control token, or a cookie or hidden field manipulated to elevate privileges or abusing JWT invalidation.
  • CORS misconfiguration allows API access from unauthorized/untrusted origins.
  • Force browsing to authenticated pages as an unauthenticated user or to privileged pages as a standard user.

2. Cryptographic Failures

The first thing is to determine the protection needs of data in transit and at rest. For example, passwords, credit card numbers, health records, personal information, and business secrets require extra protection, mainly if that data falls under privacy laws, e.g., EU’s General Data Protection Regulation (GDPR), or regulations, e.g., financial data protection such as PCI Data Security Standard (PCI DSS). For all such data:

  • Is any data transmitted in clear text? This concerns protocols such as HTTP, SMTP, and FTP also using TLS upgrades like STARTTLS. External internet traffic is hazardous. Verify all internal traffic, e.g., between load balancers, web servers, or back-end systems.
  • Are any old or weak cryptographic algorithms or protocols used either by default or in older code?
  • Are default crypto keys in use, weak crypto keys generated or re-used, or is proper key management or rotation missing? Are crypto keys checked into source code repositories?
  • Is encryption not enforced, e.g., are any HTTP headers (browser) security directives or headers missing?
  • Are the received server certificate and the trust chain properly validated?
  • Are initialization vectors ignored, reused, or not generated sufficiently secure for the cryptographic mode of operation? Is an insecure mode of operation such as ECB in use? Is encryption used when authenticated encryption is more appropriate?
  • Are passwords being used as cryptographic keys in absence of a password-based key derivation function?
  • Is randomness used for cryptographic purposes that were not designed to meet cryptographic requirements? Even if the correct function is chosen, does it need to be seeded by the developer, and if not, has the developer over-written the strong seeding functionality built into it with a seed that lacks sufficient entropy/unpredictability?
  • Are deprecated hash functions such as MD5 or SHA1 in use, or are non-cryptographic hash functions used when cryptographic hash functions are needed?
  • Are deprecated cryptographic padding methods such as PKCS number 1 v1.5 in use?
  • Are cryptographic error messages or side-channel information exploitable, for example in the form of padding oracle attacks?

3. Injection

An application is vulnerable to attack 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.

Some of the more common injections are SQL, NoSQL, OS command, Object Relational Mapping (ORM), LDAP, and Expression Language (EL) or Object Graph Navigation Library (OGNL) injection. The concept is identical among all interpreters. Source code review is the best method of detecting if applications are vulnerable to injections. Automated testing of all parameters, headers, URL, cookies, JSON, SOAP, and XML data inputs is strongly encouraged. Organizations can include static (SAST), dynamic (DAST), and interactive (IAST) application security testing tools into the CI/CD pipeline to identify introduced injection flaws before production deployment.

4. Insecure Design

Insecure design is a broad category representing different weaknesses, expressed as “missing or ineffective control design.” Insecure design is not the source for all other Top 10 risk categories. There is a difference between insecure design and insecure implementation. We differentiate between design flaws and implementation defects for a reason, they have different root causes and remediation. A secure design can still have implementation defects leading to vulnerabilities that may be exploited. An insecure design cannot be fixed by a perfect implementation as by definition, needed security controls were never created to defend against specific attacks. One of the factors that contribute to insecure design is the lack of business risk profiling inherent in the software or system being developed, and thus the failure to determine what level of security design is required.

Requirements and Resource Management

Collect and negotiate the business requirements for an application with the business, including the protection requirements concerning confidentiality, integrity, availability, and authenticity of all data assets and the expected business logic. Take into account how exposed your application will be and if you need segregation of tenants (additionally to access control). Compile the technical requirements, including functional and non-functional security requirements. Plan and negotiate the budget covering all design, build, testing, and operation, including security activities.

Secure Design

Secure design is a culture and methodology that constantly evaluates threats and ensures that code is robustly designed and tested to prevent known attack methods. Threat modeling should be integrated into refinement sessions (or similar activities); look for changes in data flows and access control or other security controls. In the user story development determine the correct flow and failure states, and ensure they are well understood and agreed upon by responsible and impacted parties. Analyze assumptions and conditions for expected and failure flows, and ensure they are still accurate and desirable. Determine how to validate the assumptions and enforce conditions needed for proper behaviors. Ensure the results are documented in the user story. Learn from mistakes and offer positive incentives to promote improvements. Secure design is neither an add-on nor a tool that you can add to the software.

Secure Development Lifecycle

Secure software requires a secure development lifecycle, some form of secure design pattern, paved road methodology, secured component library, tooling, and threat modeling. Reach out to your security specialists at the beginning of a software project throughout the whole project and maintenance of your software. Consider leveraging the OWASP Software Assurance Maturity Model (SAMM) to help structure your secure software development efforts.

5. Security Misconfiguration

The application might be vulnerable if the application is:

  • 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 software is out of date or vulnerable.

Without a concerted, repeatable application security configuration process, systems are at a higher risk.

6. Vulnerable and Outdated Components

You are likely vulnerable:

  • If you do not know the versions of all components you use (both client-side and server-side). This includes components you directly use as well as nested dependencies.
  • If the software is vulnerable, unsupported, or out of date. This includes the OS, web/application server, database management system (DBMS), applications, APIs and all components, runtime environments, and libraries.
  • If you do not scan for vulnerabilities regularly and subscribe to security bulletins related to the components you use.
  • If you do not fix or upgrade the underlying platform, frameworks, and dependencies in a risk-based, timely fashion. This commonly happens in environments when patching is a monthly or quarterly task under change control, leaving organizations open to days or months of unnecessary exposure to fixed vulnerabilities.
  • If software developers do not test the compatibility of updated, upgraded, or patched libraries.
  • If you do not secure the components’ configurations.

7. Identification and Authentication Failures

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, where the attacker has a list of valid usernames and passwords.
  • Permits brute force or other automated attacks.
  • Permits default, weak, or well-known passwords, such as “Password1” or “admin/admin”.
  • 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. User sessions or authentication tokens (mainly single sign-on (SSO) tokens) aren’t properly invalidated during logout or a period of inactivity.

8. Software and Data Integrity Failures

Software and data integrity failures relate to code and infrastructure that do not protect against integrity violations. An example of this is where an application relies upon plugins, libraries, or modules from untrusted sources, repositories, and content delivery networks (CDNs). An insecure CI/CD pipeline can introduce the potential for unauthorized access, malicious code, or system compromise. Lastly, 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 updates to be distributed and run on all installations. Another example is where objects or data are encoded or serialized into a structure that an attacker can see and modify is vulnerable to insecure deserialization.

9. Security Logging and Monitoring Failures

Security Logging and Monitoring Failures are to help detect, escalate, and respond to active breaches. Without logging and monitoring, breaches cannot be detected. Insufficient logging, detection, monitoring, and active response occurs at any time:

  • Auditable events, such as logins, failed logins, and high-value transactions, are not logged.
  • Warnings and errors generate no, inadequate, or unclear log messages.
  • Logs of applications and APIs are not monitored for suspicious activity.
  • Logs are only stored locally.
  • Appropriate alerting thresholds and response escalation processes are not in place or effective.
  • Penetration testing and scans by dynamic application security testing (DAST) tools (such as OWASP ZAP) do not trigger alerts.
  • The application cannot detect, escalate, or alert for active attacks in real-time or near real-time.

You are vulnerable to information leakage by making logging and alerting events visible to a user or an attacker

10. Server-Side Request Forgery (SSRF)

SSRF flaws occur whenever a web application is fetching a remote resource without validating the user-supplied URL. It allows an attacker to coerce the application to send a crafted request to an unexpected destination, even when protected by a firewall, VPN, or another type of network access control list (ACL).

As modern web applications provide end-users with convenient features, fetching a URL becomes a common scenario. As a result, the incidence of SSRF is increasing. Also, the severity of SSRF is becoming higher due to cloud services and the complexity of architectures.

If you would like to learn more about web security please check the website of OWASP.

Related Posts

Leave a Reply

Your email address will not be published.

Newsletter

Subscribe to our newsletter and stay updated to our offers and deals!

We are committed to protecting your privacy

Popular Post