We've isolated the top 3 critical web application security vulnerabilities that Aikido users face. This guide outlines what they are, why they're so common, and how to fix them - along with some risky runner-ups we couldn't ignore.
Address these early and effectively, and you'll already be well ahead in the fight to keep your web application secure against cybercrime.
1. Most common and critical code vulnerability (SAST)
Static Application Security Testing (SAST) is a testing method that scans source code for vulnerabilities early in the development cycle. It's called a white-box method because the workings of the application are known to the tester.
NoSQL injection attacks (code vulnerability: SAST)
NoSQL injection can lead to leaked data, corrupted databases, and even complete system compromise. Sadly, it's a critical web application security vulnerability and we've seen a lot of Aikido user accounts exposed to it.
What is NoSQL injection?
NoSQL injection is a type of attack where hackers use malicious code to manipulate or gain unauthorized access to a NoSQL database. Unlike SQL injections, which target SQL databases, NoSQL injections exploit vulnerabilities in NoSQL databases like MongoDB. It can lead to data leaks, corruption, or even full control over the database.
Why is this vulnerability so common?
NoSQL injection is common partly because of the increasing popularity of NoSQL databases, especially MongoDB. These databases offer performance benefits, but they come with unique security challenges.
On top of this, NoSQL databases are flexible in that they accept various formats like XML and JSON. This flexibility is great, but it can lead to web application security vulnerabilities, as standard security checks might not catch malicious inputs tailored to these formats.
And the vast array of NoSQL databases, each with its own syntax and structure, also makes it harder to create universal safeguards. Security professionals must understand the specific details of each database and that adds complexity to the prevention process.
Even worse, and unlike traditional SQL injections, NoSQL injections can occur in different parts of an application. This makes them even harder to detect.
How can you easily fix this vulnerability?
Use input validation and parameterized queries. Input validation ensures user inputs match expected types and formats, rejecting unsafe values. Parameterized queries prevent the embedding of unvalidated inputs.
In general, always implement database security features like authentication and encryption. Stay updated with the latest patches. And make sure you conduct regular audits of code and configurations to identify and fix this and other vulnerabilities.
Runner-up: Leaving dangerous debug functions in code (code vulnerability: SAST)
Exposed debug functions allow reconnaissance that assists attackers in exploiting systems - sometimes with significant security risk.
What are dangerous debug functions?
Debug functions like phpinfo() can expose sensitive information about your server and environment. This includes the PHP version, OS details, server information, and even environment variables that might contain secret keys (although we definitely don't recommend putting secret keys there in the first place!).
As a result, detecting the structure of your filesystem through these debug functions might allow hackers to carry out directory traversal attacks if your site is vulnerable. Exposing phpinfo() on its own isn't necessarily a high risk, but it can make it slightly easier for attackers. The principle is clear: the less specific info hackers have about your system, the better.
Why is this vulnerability so common?
This web application security vulnerability often occurs because developers use these functions for debugging and sometimes even push them to production for troubleshooting. Rushed releases, lack of code review, and underestimating risks all contribute to these functions being left exposed.
How can you easily fix this vulnerability?
- Code review: regularly check your code to identify and remove debug functions before deploying to production.
- Automated scanning tools: use a tool, like Aikido, that can detect dangerous debug functions.
- Environment-specific configurations: make sure you disable debug functions in the production environment.
2. Most common and critical DAST vulnerability
Dynamic Application Security Testing (DAST) is a testing technique that identifies vulnerabilities in running applications. It's called a black-box method because it focuses only on observable behavior. DAST shows you what the system might look like to an attacker.
Forgetting major security headers: HSTS and CSP (cloud vulnerability: DAST)
A lack of proper HSTS and CSP implementation leaves web applications vulnerable to major attacks like XSS and information disclosure.
What is CSP?
Content Security Policy (CSP) is a security mechanism that helps defeat various browser-based attacks like cross-site scripting and clickjacking. It does this by restricting risky behaviors in web pages such as inline JavaScript and unsafe eval() functions. CSP enforces safer defaults to maintain the integrity and confidentiality of content. The key benefit is protecting against malicious injection of scripts.
Why is this DAST vulnerability so common?
It’s very common to neglect HSTS and CSP, especially CSP and developers often prioritize functionality over these headers.
You should plan CSP early in development, but it often gets overlooked. And when devs try to implement or retrofit it later it causes conflicts, so they skip CSP entirely to get on with other work. This leaves apps unprotected and subject to a range of web application security vulnerabilities.
How can you easily fix this DAST vulnerability?
- Implement HSTS to force HTTPS only connections. Enable on the server through configuration files or a WAF.
- Define and apply a strict CSP tailored to your app by restricting unsafe practices like inline scripts. Carefully test for compatibility.
- Continuously monitor and update headers as the app evolves to maintain protection.
3. Most common and critical cloud vulnerability (CSPM)
Cloud Security Posture Management (CSPM) tools continuously monitor cloud-based environments to ensure compliance with security standards and best practices. CSPM tools look for security misconfigurations and are aimed at mitigating risks.
Leaving EC2 IAM roles vulnerable to SSRF attacks (cloud: CSPM)
Open EC2 IAM roles frequently can enable attackers to move laterally and gain unauthorized access across cloud environments. The potential impact of this kind of attack can be devastating.
What are EC2 IAM roles?
EC2 IAM (Identity and Access Management) roles in Amazon Web Services (AWS) delegate permissions to determine allowed actions on specific resources. They enable EC2 instances to securely interact with other AWS services without having to store credentials directly on the instances themselves.
What is an SSRF attack?
A Server Side Request Forgery (SSRF) attack is where an attacker forces the server to make requests to internal resources as if it's the server itself asking. The attacker can potentially access unauthorized systems this way, bypass controls, or even execute commands. Check out this terrifying example of how an SSRF attack took over a startup’s cloud via a simple form to send an email.
Why is this CSPM vulnerability so common?
EC2 IAM roles are usually left vulnerable to SSRF attacks because of security misconfigurations or overly permissive roles. Juggling complex cloud permissions is hard and some developers might not fully understand the risks. On top of this, wanting services to work smoothly together can often nudge teams to grant more access than is really needed.
How can you easily fix this CSPM vulnerability?
There are some solid ways to tackle EC2 roles and mitigate SSRF web application security vulnerabilities. First off, stick to the principle of least privilege - only allow the exact access that's absolutely needed and nothing more. Overly permissive roles are asking for trouble.
Next up, make use of built-in AWS tools like security groups and network ACLs to lock down traffic and reduce the potential openings for SSRF attacks. The more you can limit access, the better.
It's also important to regularly review and audit roles to catch any unnecessary access that might be creeping in over time as things change. Stay on top of it.
And lastly, implement AWS security tools focused specifically on detecting and preventing SSRF attacks before they cause harm. The more layers of protection, the more secure you'll be.
Runner-up: Outdated cloud lambda runtimes (cloud: CSPM)
When these runtime environments become outdated, they may expose the lambda functions to attackers.
What are outdated lambda runtimes?
Outdated lambda runtimes refer to using older versions of programming languages or environments in serverless functions (lambdas). These outdated runtimes may lack the latest security patches or feature updates, potentially exposing applications to known web application security vulnerabilities.
Why is this CSPM vulnerability so common?
The vulnerability often arises from a “set and forget” mentality. Developers may deploy lambdas with a specific runtime and neglect to update them as new versions are released. They can also make the mistake of assuming that cloud providers handle all maintenance. Even though AWS and Google Cloud Functions will maintain runtimes for you with minor OS patches, they won’t do major language upgrades. On top of all that, the complexity of managing multiple lambdas makes it easy for outdated runtimes to fall through the cracks and create extra risk.
How can you easily fix this CSPM vulnerability?
You can mitigate the risk by following three simple rules:
- Regularly review which runtimes are used and check for updates.
- Upgrade to the latest supported versions with security patches.
- Use automation tools to manage and update runtimes where possible.
Web application security vulnerabilities and best practices
Understanding these web application security vulnerabilities is essential for system security, but remember to follow best security practices. Stay up to date, apply the appropriate fixes, and maintain regular monitoring to keep your environment safe and secure.
Scan your environment with Aikido right now to find out if you're exposed to any of these vulnerabilities.
Check out Aikido’s 2024 SaaS CTO Security Checklist to get concise advice on 40+ ways to improve security across your people, processes, code, infrastructure, and more.
Top comments (0)