If a threat actor is successful, the speed at which they can access a company’s sensitive information means the priority should immediately be on damage control.
Companies must respond to these new web application security threats to help protect their critical data and assets.
Don’t miss our article on the 8 Web Application Security Threats you should know about now here.
This list and information within it has been curated from OWASPs latest list, which was published on 24th September 2021.
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.”
- 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.
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.
- 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.
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).
- 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.
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.
- 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.
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.
- 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
“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?
- 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.
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.
- 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.
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.
- 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.
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 firstname.lastname@example.org.
Check out our other resources regarding Web Application Security here:
Web Application Security Policy
Web Application Security Risks
Web Application Security Checklist
Web Application Security Audit
Web Application Security Solutions from LoughTec