Top Ten Web Application Vulnerabilities Pt. 2

Although this is sixth on OWASP’s list, vulnerable and outdated components play a large role in how most attackers get into a system. The longer a system remains unpatched or not upgraded, the more likely it is that vulnerabilities exist in that system. 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.

Maintaining up-to-date versions of all components in your infrastructure is the best way to prevent attackers from using this attack vector.

Confirmation of the user's identity, authentication, and session management is critical to protect against authentication-related attacks. If attackers can get credentials for your site, they may be able to leverage that access to gain a foothold on your network. Your application may have Identification or Authentication issues if:

• The application allows automated attacks such as credential stuffing, brute-forcing, or allows the use of default, weak or well-known passwords.
• Uses weak or ineffective credential recovery and forgot-password processes, such as "knowledge-based answers," which cannot be made safe.
• 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.

The best way to prevent these attacks is the use of Multi-Factor Authentication. Even if weak, default, or easily guessable passwords are in use, an attacker would be unable to gain access if MFA is in place.

Software and data integrity failures relate to code and infrastructure that does 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) and does not check to verify the integrity of these sources. 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. The best ways to prevent flaws like this are:

• Use digital signatures or similar mechanisms to verify the software or data is from the expected source and has not been altered.
• Ensure libraries and dependencies, such as npm or Maven, are consuming trusted repositories. If you have a higher risk profile, consider hosting an internal known-good repository that's vetted.
• Ensure that there is a review process for code and configuration changes to minimize the chance that malicious code or configuration could be introduced into your software pipeline.
• Ensure that your CI/CD pipeline has proper segregation, configuration, and access control to ensure the integrity of the code flowing through the build and deploy processes.
• Ensure that unsigned or unencrypted serialized data is not sent to untrusted clients without some form of integrity check or digital signature to detect tampering or replay of the serialized data

Without logging and monitoring, breaches cannot be detected. Insufficient logging, detection, monitoring, and active response occurs any time Auditable events, such as logins, failed logins, and high-value transactions, are not logged or when warnings and errors generate no, inadequate, or unclear log messages. To prevent these issues Security teams should consider implementing some or all the following controls:

• Ensure all login, access control, and server-side input validation failures can be logged with sufficient user context to identify suspicious or malicious accounts and held for enough time to allow delayed forensic analysis.
• Ensure that logs are generated in a format that log management solutions can easily consume.
• Ensure log data is encoded correctly to prevent injections or attacks on the logging or monitoring systems.
• Ensure high-value transactions have an audit trail with integrity controls to prevent tampering or deletion, such as append-only database tables or similar.
• Establish or adopt an incident response and recovery plan, such as National Institute of Standards and Technology (NIST) 800-61r2 or later.

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.

At the network layer SSRF can be mitigated by:

• Segmenting remote resource access functionality in separate networks to reduce the impact of Server-Side Request Forgery
• Enforce “deny by default” firewall policies or network access control rules to block all but essential intranet traffic.

At the Application layer SSRF can be mitigated by: