What is OWASP?
According to the OWASP website, “the Open Web Application Security Project® (OWASP) is a nonprofit foundation that works to improve the security of software. Through community-led open-source software projects, hundreds of local chapters worldwide, tens of thousands of members, and leading educational and training conferences, the OWASP Foundation is the source for developers and technologists to secure the web.”
With over two decades of experience in web application security guidance, OWASP is considered a highly credible voice for the industry, providing informative tools and resources, community and networking and educational training for its members worldwide.
What is the OWASP Top 10 list?
The OWASP top 10 list has become a significant awareness and educational tool for the web application security community. The list highlights the most common web application security risks and vulnerabilities so that businesses can understand which risks they need to focus on.
The list also delves into the potential impact each vulnerability could have on your organisation, as well as advice on how best to avoid them.
To build their list, OWASP utilises informational sources from across the industry, including from vendors and security teams and consultants from companies of all sizes.
Whilst the list was set up in 2003 for industry awareness, it has become to be known as the industry standard for application security.
10 Web Application Security Risks You Should Know About Now
The latest iteration of OWASP’s top 10 list was released on 24th September 2021. We have broken down the list below.
- Broken Access Control
- Cryptographic Failures
- Injection
- Insecure Design
- Security Misconfiguration
- Vulnerable and Outdated Components
- Identification and Authentication Failures
- Software and Data Integrity Failures
- Security Logging and Monitoring Failures
- Server-Side Request Forgery
We will now delve a bit deeper into each of the vulnerabilities listed in the OWASP list including recommendations on how you can mitigate the risk of each one.
Broken Access Control
OWASP stipulates access control as enforcing “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.”
It is important that web applications limit access to certain pages or sections based on the type of user. For example, an administrator should have different permissions than a regular user.
If an attacker is able to exploit broken access controls, they could gain access to pages or data that they are not supposed to have access to, leading to information being leaked or tampered with. A common example of this is via a website content management system (CMS).
Recommendations
- Assign as low-level access as possible to each individuals role so that they can still complete their responsibilities successfully
- Accounts that are no longer needed or active should be deleted
- Perform regular audits on your web applications and servers to keep abreast of all user activity
- Audit activity on servers and websites so that you are aware of who is doing what (and when).
- Disable access points that are not required
- Always shut down unnecessary services to help optimise your servers.
Cryptographic Failures
“The first thing is to determine the protection needs of data in transit and at rest.”
Sensitive information such as passwords, credit card numbers, health records, personal information or business intellectual property may require extra protection due to the potential for cryptographic failures (sensitive data exposures). This also applies if the information falls under privacy laws in certain jurisdictions. The EU’s General Data Protection Regulation (GDPR) is a good example of this. Financial data may also be required to be protected by PCI Data Security Standards (PCI DSS).
Companies should consider – is any data transmitted in clear text? 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?
Recommendations
- Do not use autocomplete on forms that collect data
- Always use the most up-to-date encryption techniques
- Reduce/minimize the size of the data surface area.
- Make sure to encrypt all sensitive data at rest.
- Disable caching for responses that contain sensitive data
- Store passwords using strong adaptive and salted hashing functions.
Injection
Injection vulnerabilities can occur when user input is not properly validated and sanitized before being used by web applications. This can allow attackers to insert malicious code that is executed by the web application.
According to OWASP, “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.”
Recommendations
- Use a safe API, which avoids using the interpreter entirely
- Use positive server-side input validation
- For any residual dynamic queries, escape special characters using the specific escape syntax for that interpreter.
Insecure Design
OWASP defines insecure design as “missing or ineffective control design.”
New categories for the 2021 OWASP top 10 report include threat modelling, secure design patterns, and reference architectures, with a call for more use of risk analysis, safe design patterns and reference architecture. As a community, it is agreed we must go beyond “shift left” coding to pre-code activities that are essential to Secure by Design principles.
Recommendations
- To evaluate and build security and privacy-related controls, talk with AppSec specialists about establishing and running a secure development lifecycle.
- Establish and use a library of secure design patterns or paved road ready-to-use components
- Use threat modelling to assess the security of critical functions such as authentication, access control, business logic, and key flows.
- Integrate security language and controls into user stories
- Integrate plausibility checks at each level of your application (from frontend to backend)
- Validate that all crucial flows are protected against the risk model by writing unit and integration tests. For each level of your application, compile use-cases and misuse-cases.
- Depending on the exposure and protection requirements, separate tier layers on the system and network layers.
- Limit resource consumption by user or service.
Security Misconfiguration
There are a variety of types of misconfiguration that may put a firm at risk, including:
- Accepting insecure default settings
- Configurations that are incomplete
- Out-of-date software.
Recommendations
- Configure development, test, and production environments that are based on the organisation’s security policies.
- Minimise the risk from an insecurely configured element by using segmented application architectures; maintain a library of correctly provisioned container images.
- Remove unused features and frameworks.
- Automate workflows whenever feasible to continuously monitor cloud resources, applications, and servers for security misconfigurations.
Vulnerable and Outdated Components
Many of today’s distributed web applications rely on open source components such as frameworks and libraries. Any component with a known security issue becomes a weak link in the security of the application.
According to OWASP, it is likely you are vulnerable to this web application security risk if you are unaware of all of the components you use, or if the software you use is now out of date or has become unsupported. It is important you scan for vulnerabilities regularly to ensure you keep abreast with the most up-to-date information for your web applications, always fixing and upgrading where applicable.
Recommendations
- All parts of the company’s frameworks should be under configuration management.
- Scanning must be capable of detecting all the components to be monitored automatically
- Automate patch management workflows to reduce operational risk
Identification and Authentication Failures
Authentication, identification, and session management are all important to avoid authentication-related attacks. Passwords, security keys, and session tokens may all be downloaded by threat actors in order to temporarily impersonate other users’ identities and permissions, making this a severe threat to the security of applications.
If your application permits weak or well-known passwords, has not got multi-factor authentication enabled or uses ineffective password recovery processes, you are at risk of identification and authentication failures.
Recommendations
- Deploy multi-factor authentication
- Do not deploy with default credentials, particularly for admin users
- Strong passwords should be a minimum requirement
- Failed login attempts should be closely monitored
- Use a server-side session manager that generates a new random session ID after logins.
Software and Data Integrity Failures
This category is a new inclusion for the 2021 report. OWASP defines this as “code and infrastructure that does not protect against integrity violations.”
For example, when an application needs plugins, libraries or modules from untrusted sources.
Many applications now have auto-update functionality built-in, meaning they can be updated without the required integrity checks. This is something threat actors could exploit, running their own updates across systems, increasing the risk and size of potential system damage.
Recommendations
- Use digital signatures or similar to verify the software or data is from the expected source and that no changes have been made.
- Ensure that untrustworthy clients do not receive unsigned or unencrypted serialised data unless there is some sort of integrity check or digital signature to detect modification
- Make certain that you have a code and configuration review procedure in place to minimise the risk of harmful code or configurations being introduced into your development pipeline.
Security Logging and Monitoring Failures
Ransomware attacks involve huge undetected dwell times. A recent IBM study found the average time to detect and contain a data breach is 287 days (212 to detect, 75 to contain).
This gives threat actors more than enough time to ensure they are inflicting maximum damage on servers and critical enterprise systems.
Without appropriate logging and monitoring, the time it takes to detect breaches will only increase.
Recommendations
Suitable logging and monitoring software should be deployed as soon as possible to help decrease the time taken to detect suspicious behaviour or unauthorised web application access.
Even if an attack has failed, monitoring and logging provide crucial tools for analysing the source and vector of the attack, helping to guide organisations on how to strengthen their security policies for future instances.
Server-Side Request Forgery
According to OWASP, Server-side request forgery “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).”
This is most common when a web application retrieves a remote resource without validating a user-supplied URL for example, meaning an SSRF fault occurs.
Complex system and network architectures as well as an increase in the use of cloud services are increasing the frequency and severity of server-side request forgery.
Recommendations
- Sanitise and validate all client-supplied input data
- Only accept intended IP address formats such as IPv4 or IPv6
- Use the method/output library’s value as the IP address to compare against the allow list
- Validate incoming Domain Names.
Schedule a Meeting
LoughTec is committed to preventing threats and zero-day attacks for secure data transfer across your network, applications, and customer operations.
With almost two decades of experience in securing critical infrastructure systems, our technologies integrate advanced malware protection and detection into your IT solutions and applications.
MetaDefender – our advanced threat prevention solution for file uploads is used by organisations that require the highest level of security, including critical infrastructure, government agencies, and financial institutions.
Use a web application security solution that works – schedule a meeting with one of our Technical experts today and explore how we can help you protect your infrastructure from advanced sophisticated threats. Let us help you implement good web application security for your organisation.
Call us on +44 (0) 28 8225 2445 or email our team at info@loughtec.com.
Check out our other resources regarding Web Application Security here:
Web Application Security Policy
Web Application Security Checklist
Web Application Security Audit
8 Web Application Security Threats
Web Application Security Solutions from LoughTec
