Web Security
Various technologies that can be used by organizations to achieve web security include; web application firewalls (WAFs), password-cracking tools, black and white box testing tools, security or vulnerability scanners', etc.
Web applications firewalls for instance protect web applications by monitoring and filtering internet traffic that flows between an application and the internet. It provides protection as a secure web gateway against attacks like cross-site scripting, cross-site forgery, Structured Query Language Injection and so on.
Security professionals consider various factors when establishing security strategies for their applications to comply with internal policies, government-imposed criteria and Open Web Application Security Project Standards. These factors may include the threats and tactics of cyber attackers that are emerging frequently.
Therefore, the security posture of an application must be able to adapt and protect applications and its resources.
Open Web Security Project (OWASP) Explained
OWASP is a nonprofit foundation that works to improve the security of software. They are an open source community that enables organisations to conceive, develop and acquire, operate and maintain applications that can be trusted.
OWASP was launched in December 2001, and became a United State non-profit charity in April 2004. They provide project tools, and forums documents for free to individuals who are interested in improving security of applications.
OWASP raises concerns regarding web application security risk and helps developers, security personnels and organizations understand cyber threats and the best practices involved in securing web applications.
What is OWASP Top 10?
OWASP Top 10 is a report that outlines security concerns for web applications, it is regularly updated and gives insights on the 10 critical risks to help organizations identify risks within software applications.
OWASP updates the Top 10 LIST every three to four years and the next update would be in 2025. The last update shows the changes in security risks and also how the threats have evolved. The reason for the gap is to ensure that information presented on the list is thoroughly researched and revised so that it captures the trends in web application security.
Let's look at the risk in the OWASP Top 10 2021 report;
Moving up from the fifth position, 94% of applications were tested for various forms of broken access control. There are 34 common weakness enumerations (CWEs) mapped to broken access control, highlighting ways that access control can fail. This type of security weakness appeared more frequently than other security weaknesses.
Access control ensures that users cannot act outside their permissions or perform actions they're not authorized to do. For instance, customers may be able to view but may not be able to edit their accounts.
Users' actions are restricted by their roles; failures in access control may give users the ability to access sensitive information they shouldn't see, or modify sensitive data.
Example of access control vulnerabilities include;
Users can bypass access control checks by modifying the URL (Parameter tampering - like query strings) to manipulate how the server responds or use an attack tool to intercept and modify API requests.
Users or attackers can elevate their privileges by bypassing the authentication process and interact with the system as if they are a legitimate user. This allows them to exploit the system and perform operations like accessing sensitive data or delegating tasks to other users.
Access control is effective when it's enforced on the trusted server-side code or server-less API where the attacker cannot tamper with logic that enforced control easily.
There are best practices for implementing access control in applications. To mention a few;
Moving up to the #2 position, and previously known as Sensitive Data Exposure which was considered a larger symptom rather than the root cause, the focus became failures related to the application of cryptography that leads to system compromise or sensitive data exposure.
Data transmitted over the network (in transit) and data stored (at rest) needs specific protection. For instance, sensitive data like password, health records, credit card details require strong protection especially dealing with data that falls under privacy laws like EU's General Data Protection Regulation (GDPR) and regulatory standards like Payment Card Industry Data Security Standards (PCI DSS).
Failure to protect these data results in legal consequences such as fines or penalties.
The use of weak encryption methods or protocols can be exploited by attackers.
Default crypto keys, weak crypto keys, re-used keys or lack of proper key management and rotation can create vulnerabilities that can be exploited by attackers.
There are various ways to prevent cryptographic failures including;
Encrypt all sensitive data at rest or where it is stored.
Classify data in transit or at rest by an application. Identify which data is sensitive based on privacy laws, regulatory standards or business needs that require extra protection.
Injection attacks moved to the third position. 94% of applications were tested for some form of injection and 33 common weakness enumerations (CWEs) were mapped into this category showing that CWE had the second-highest number of occurrences in applications.
Cross-site Scripting has also been grouped in this category. Common injections include SQL, NoSQL, OS command, object relational mapping (ORM), and object graph navigation library (OGNL) injection.
There are many reasons why applications become vulnerable to attacks. For instance;
User-supplied data is not validated, and filtered by the application.
Malicious data is used within object-relational mapping (ORM- allows developers to pass search criteria into queries through parameters) search parameters to extract sensitive information.
There are different practices for securing web applications against SQL injection and other injection vulnerabilities including;
Validating data on the server where the application is more secure ensures that malicious input is filtered before it can be processed by the application.
Additionally, the use of parameterized queries can protect applications from SQL injection.
This is a new category added to the 2021 list that focuses on risks related to design and architecture flaws.
It calls for the use of threat modelling, secure design patterns and reference architectures, encouraging the community to move beyond "shift-left" in the coding space or integrating security in the early stage of development to pre-code activities necessary for creating applications that are Secure by Design.
Secure design involves establishing design patterns that include security considerations such as constantly evaluating threats and ensuring code is robustly designed and tested to prevent known attack methods.
A secure development cycle involves a structured approach that incorporates strategies and tools at various stages of the development process. Frameworks like OWASP SAMM (Software Assurance Maturity Model) can help guide and improve security practices, ensuring security is an essential part of the development cycle.
A few methods to prevent insecure design include;
Create and implement a secure development lifecycle with AppSec (Application Security) professionals to evaluate and design security and privacy-related controls.
Limit consumption of resources by users or services to prevent abuse.
Create and maintain a library of secure design patterns and ready to use components to reduce vulnerabilities.
Security misconfiguration moved up from the #6 spot in the previous edition to #5 in the 2021 OWASP Top 10. 90% of applications were tested for some form of misconfiguration with an average incidence rate of 4% misconfiguration found. There were over 208k occurrences of common weakness enumeration (CWE) in this risk category.
A few reasons why an application might become vulnerable includes;
No appropriate hardening across any part of the application stack, or misconfigured permissions on cloud services.
Installing or enabling unnecessary features such as privileges, ports
Secure settings in application server, application servers, libraries, databases are not set to secure values.
A secure installation process can be achieved by the following;
A repeatable process for securing systems makes it fast and easy to set up and deploy a new secure environment. Development, QA, and production environments should have the same configuration, but utilize different credentials. Automating the process minimizes the effort required to set up a new secure environment.
Use a minimal system with necessary features, components, documentations and remove or avoid installing unused features, and frameworks.
Ranked #2 by the community survey, with sufficient data to make it to OWASP Top 10 list vulnerable components are issues that can be difficult to test. In other words, identifying risk posed by vulnerable and outdated components in an application can be difficult.
Vulnerable components don't have common weakness enumerations which are identifiers for known security vulnerabilities which makes it difficult to track this risk. However, common weakness enumeration (CWEs) is highlighted such as the use of unmaintained third-party components and CWEs from OWASP Top 10 list from 2013 and 2017.
Examples of how applications can become vulnerable includes;
If you do not know the versions of all components both client-side and server-side, including components used directly and nested components.
The software is vulnerable, and out of date. This includes the OS, application server, database management system (DBMS) APIs and all components, libraries and runtime environment.
Examples of how you can prevent this risk include;
Remove unused dependencies, unnecessary features, files, components and documentation.
Obtain components from official sources via secure links
Previously called Broken authentication, identification and authentication failures moved from the #2 position and now includes common weakness enumerations related to identification failures.
To protect applications from authentication-related attacks it's essential to confirm users' identity, authentication and session management.
Authentication weaknesses may occur if the application does the following;
Permits automated attacks like credential stuffing where the attacker has a list of legitimate usernames and passwords.
Permits default, weak or easy to guess passwords like "admin/admin"
The use of weak credentials recovery and forgotten password processes
To prevent against identification and authentication failure risk, the following can be done;
Implement multi-factor authentication where it's necessary to prevent automated credential stuffing, stolen credential reuse attacks and brute force.
Do not ship or deploy with default credentials especially for admin uses
This category was newly added in 2021, and it focuses on making assumptions related to software updates, CI/CD pipelines, and sensitive data without confirming integrity. It involves failures related to code and infrastructure that does not protect against integrity violations.
If an application relies on libraries or plugins from untrusted sources an insecure CI/CD pipeline can introduce vulnerabilities for malicious code, or unauthorized access.
Preventing software and data integrity failures involves;
The use of digital signatures or other mechanisms to verify the integrity of software or data.
Consuming libraries and dependencies only from trusted repositories.
Ensuring that the software security tool like OWASP dependency check or OWASP CycloneDX is used to verify components are free of known vulnerabilities.
This risk moved up from #10 in the 2017 OWASP Top 10 to #3 in the community survey. Logging and monitoring can be difficult to test, and it often involves interviewing and asking to see if attacks are detected.
This category can help detect, escalate and respond to active breaches. Exempting logging and monitoring will lead to breaches that cannot be detected.
Ineffective logging, detection and monitoring can occur if:
Events such as logins, failed logins, high-value transactions are not logged
Warning and errors generate no message or unclear log messages.
Alert thresholds and response escalation processes are not in place or inactive.
To prevent security logging and monitoring failures developers can implement the following:
Ensure that logs are generated in a format that can be easily consumed by log management solutions.
Ensure log data is encoded to prevent injections or attacks on logging
Ensure high-value transactions have audit trail with integrity controls to prevent tampering
This is last on the list because data from the Top 10 community survey shows a relatively low incidence rate with above average testing coverage and above-average exploit and impact potential rating.
SSRF faults occur when a web application is fetching remote resources without validating the URL supplied by a user. Attackers can coerce the application to send a crafted request to an unexpected destination even when it's protected by firewall, VPN or other network access control list (ACL)
Fetching URL is common in modern web-applications which increases SSRF incidence.
SSRF can be prevented by implementing the following;
Disable HTTP redirections.
Enforce "deny by default" firewall policies to block unessential internet traffic.
Divide remote resource access functionality in separate networks to reduce the impact of SSRF.
Impose URL schema, port and destination with positive allow list.
