The Open Web Application Security Project (OWASP) is a non-profit organization that provides guidelines to protect web applications from risks.
They also released a list of the top 10 vulnerabilities, the OWASP Top 10, which describes the major threats to web applications in detail.
The OWASP Top 10 is a common security and developer awareness guide for online applications. It represents a universal consensus on the most critical web application security threats.
Furthermore, companies should use this document to mitigate the risks associated with their online applications.
The OWASP Top 10 is probably the most effective initial step toward converting the organization’s software development culture to one that creates more secure code.
A1: Broken Access Control
Access control refers to the enforcing of constraints on authenticating users performing actions outside of their level of authorization.
Access control is broken when such constraints are not correctly imposed. Unauthorized access to sensitive information, as well as its manipulation or deletion, is a result of this.
How does it break?
- Providing unrestricted access to the data that is restricted and denied by default under the principle of least privilege.
- To evade access control checks, tampering with parameters and forcing browsing (i.e. changing a URL or HTML page) or manipulating API requests.
Prevention
- Make sure there are no metadata (git) or backup files in the site root.
- Also, disable the listing of web server directories.
- Use multi-factor authentication at all access points and disable any that aren’t needed.
- Ensure that the concept of least privilege is followed (PoLP) and remove unwanted services.
A2: Cryptographic Failures
Cryptographic failures are issues with cryptography or the complete lack of cryptographic algorithms. Sensitive Data Exposure was the previous term for this issue.
However, it wasn’t completely correct because it represented a symptom and result, rather than a cause. Data may be exposed because of cryptographic failure, which happens frequently.
The confidentiality of data in transit and at rest is compromised by this type of failure.
It generally includes authentication parameters like usernames and passwords, as well as personally identifiable information (PII) and other sensitive data.
How does it break?
- Non-implementation of Encryption.
- Use cryptography techniques and protocols that are obsolete or insecure.
- Keeping or sharing sensitive information in plain text.
- The server certificate and the trust chain were not correctly validated.
Prevention
- Encrypt all data in transit using the Transport Layer Security (TLS) protocol with forwarding secrecy.
- Encrypt with the HTTP Strict Transport Security (HSTS) directive or anything equivalent.
- To save passwords, use functions that always salt and hash passwords and have a work factor, such as brcrypt, scrypt, Argon2, and PBKDF2.
- Always use strong hashing, and encryption algorithms such as MD5, SHA-2, AES-256, RSA, etc.
A3: Injection
When an application accepts untrusted data and is compelled to execute commands, this is known as an injection attack.
Such data or malicious code is inserted by an attacker, putting data or the entire application at risk.
The most common injection attacks are SQL injections and cross-site scripting (XSS), while others include code injections, command injections, CCS injections, and others.
How does it break?
- To extract more sensitive records, hostile data is used directly, concatenated, or within ORM search criteria.
- The user’s data is not validated, checked, or verified before being used.
- Without a context-aware escape, the interpreter performs dynamic queries or non-parameterized calls directly.
Prevention
- Positive input validation (whitelist) on the server — this is just a partial precaution because many apps require special characters.
- The simplest solution is to provide a secure API that avoids using the interpreter and instead uses parameterized queries or migrates to Object Relational Mapping.
- Use an atomized vulnerability tool like Crashtest Security Suite to run an SQL Injection Test or XSS Test, which will alert you to all the defects and attack vectors detected in your web project or API.
A4: Insecure Design
The threats connected with design and building flaws are the subject of this vulnerability category. According to OWASP, these are distinct from the risks associated with implementation errors.
Even if an unsafe design is well implemented, it is vulnerable to attacks.
How does it break?
- Lack of security controls.
- Business risk profiling in software development.
- Lack of adequate identification of the level of security design.
Prevention
- Establish a secure development lifecycle with application security experts to evaluate design security and privacy requirements.
- Likewise, use threat modeling techniques to analyze crucial authentication, access control, business logic, and key flow scenarios.
- At each stage of the system, enforce plausibility checks from the front end to the back end.
A5: Security Misconfiguration
Security measures that are not secured or configured correctly are referred to as security misconfiguration.
How does it break?
- Any component of an application that lacks security hardening.
- Permissions on cloud services are incorrectly configured.
- Ports, services, pages, accounts, and privileges that aren’t needed are permitted or installed.
- The security settings on the server, framework, libraries, or databases are not set to secure levels.
- It’s been a long time since the software was updated.
Prevention
- Use a “minimal platform” with no extraneous features, components, documentation, or samples. Unnecessary features and frameworks should not be installed or removed.
- Use segmentation, containerization, or cloud security groups to create a segmented application architecture.
- Clients should get security directives, such as security headers.
- As part of the patch management process, evaluate and update the configurations of all security notes, updates, and patches.
A6: Vulnerable and Outdated Components
“Using Components with Known Vulnerabilities” was the previous name for this category.
If you don’t know the versions of all the components you use, you’re in trouble (both client-side and server-side). This covers both directly used components and deep dependencies., and so on.
How does it break?
- If the software is unsupported, vulnerable, or out of date. All OSs, web/application servers, database management systems (DBMS), applications, APIs, and other components, as well as runtime environments and libraries, are covered.
- You will be susceptible if you do not fix or upgrade your platform, framework, and dependencies when patches are published.
- If you’re not scanning for vulnerabilities regularly and keeping up with security news concerning the components you use, you’re at risk.
Prevention
- When patches are released, you must correct or upgrade your platform, framework, and dependencies.
- Remove any dependencies, features, components, files, or documentation that are no longer in use.
A7: Identification and Authentication Failures
Previously, this set of flaws was known as “Broken Authentication.”
Unauthorized persons can steal a user’s login details or fabricate session data, such as cookies, to obtain unauthorized access to websites using broken authentication.
Unauthorized persons can intercept the authentication techniques used by a web application by exploiting vulnerabilities in the authentication.
How does it break?
- Is vulnerable to automated attacks like credential stuffing.
- Insufficient password policy.
- Submit credentials over an unprotected channel.
- Insecure system for accessing passwords.
- Leakage of details while logging in failed.
- Unlimited log-in attempts.
Prevention
- Where possible, enforce multi-factor authentication(2 FA) to prevent attacks.
- Section 5.1.1 of NIST 800-63 B’s guidelines should be used to align password length, complexity, and rotation rules.
- Limits the number of failed login attempts. Also, when credential stuffing, brute force, or other attacks are detected, all vulnerabilities are monitored and administrators are notified.
- After logging in, use a server-side, stable, built-in session manager to develop a new, high-entropy random session ID. Session IDs should not be in the URL after logging out, idle, and total timeouts, and should be safely kept and invalidated.
A8: Software and Data Integrity Failures
The OWASP list now includes a new category for vulnerabilities in software updates, critical data, and CI/CD pipelines whose integrity isn’t confirmed.
In the 2017 list, this category now included what was formerly referred to as “Insecure Deserialization.”
Failures occur when objects or data are encoded or serialized into a structure that is visible to and modifiable by an attacker.
How does it break?
The auto-update functionality of most apps, which does not always involve a comprehensive integrity check, could be a similar source of failure.
As a result, attackers will be able to disseminate upgrades that are designed to exploit security flaws.
Prevention
- Verify that software or data from a source has not been tampered by using measures such as digital signatures.
- If you have a higher risk profile, make sure libraries and dependencies only use trustworthy repositories or consider hosting an internal known-good repository.
- To avoid data tampering or replay, make sure that no unsigned or unencrypted serialized data is given to untrustworthy clients without a prior integrity check or digital signature.
A9: Security Logging and Monitoring Failures
This category, which was formerly known as “Insufficient Logging and Monitoring,” has been broadened to encompass more sorts of failures.
While testing logging and monitoring is difficult, it is necessary because failures can affect accountability, visibility, incident alerting, and forensics.
How does it break?
- Login attempts, failed login attempts, high-value transactions, and other auditable events are not logged.
- Warnings and errors send out insufficient, confusing, or no messages.
- Suspicious activities are not investigated in API and application logs.
- Thresholds for alerting and response escalation have yet to be implemented or are ineffective.
- Similarly, active threats cannot be detected, escalated, or alerted in real-time or near real-time by the application.
Prevention
- All login, access control, and server-side input validation failures should be logged, together with adequate user context to identify suspect or fraudulent accounts.
- By appropriately encrypting log data, you can avoid injections or attacks on your logging or monitoring systems.
- To avoid manipulation or deletion, create an audit trail with integrity constraints for high-value transactions like append-only database tables.
- Establish excellent monitoring and alerting to detect and respond to suspicious actions quickly.
A10: Server Side Request Forgery (SSRF)
When a web application fetches a remote resource, server-side request forgery occurs when the user-supplied URL is not validated.
Even if the application is secure by a firewall, VPN, or other sorts of network access control list, attackers can compel it to send a forged request to an unexpected location (ACL).
How does it break?
The ability to fetch a URL is a frequent feature of current web applications, which leads to a rise in SSRF cases.
Furthermore, due to the rising complexity of architectures and cloud services, problems are becoming more severe.
Prevention
- By implementing “deny by default” network policies or network access control rules, you can block all but critical traffic. Depending on the application, assign ownership and a lifecycle to firewall rules. Log all permitted and denied network flows on firewalls.
- To protect against SSRF, don’t use a deny list or regular expression; these can be circumvented in a variety of ways.
- Use network encryption on separate systems with frontend that have dedicated and managed user groups for very high-security needs.
Conclusion
Web application security is a major concern these days, and the implications of such vulnerabilities can be severe.
Overall, implementing an effective coding system is a preferable way to avoid these attacks.
Check out Magento 2 Security Extension for your eCommerce store, which can also be customized to fit your needs.
Need Support?
Thank You for reading this Blog!
For further more interesting blogs, keep in touch with us. If you need any kind of support, simply raise a ticket at https://webkul.uvdesk.com/en/.
You may also visit our Odoo development services and quality Odoo Extensions.
For further help or queries, please contact us or raise a ticket.