The Top Security Issues You Don't Think About

Cyber security is a vast landscape, with specific vulnerabilities that have become all too familiar to us, such as SQL injection and Cross-Site Scripting (XSS). However, various security issues often fly under the radar despite their potential for severe damage. Today, we delve into five such vulnerabilities. We'll explore these vulnerabilities at their core, how they occur, and most importantly, how you can remediate them.

Number 5: Unrestricted File Upload

What is it? Unrestricted File Upload is when a threat actor can upload files that are not restricted based on the type or have insufficient filtering, if any at all. The impact of this vulnerability is extensive, from simple defacement to Remote Code Execution (RCE). In the worst-case scenario, if RCE is achieved, threat actors could compromise the server's security, steal sensitive data, or impact the application's availability. Additionally, the attacker could use the server to launch further attacks, such as phishing campaigns or malware distribution. This vulnerability could have other impacts: overloading a filesystem or database, forwarding attacks to back-end systems, or even directory traversal.

How does it occur? It occurs primarily in three different areas: the file's metadata, like the file name or path, the permitted file types, and the content within the file. Let’s explore a few scenarios and what can occur when security teams and developers overlook this.

File metadata such as file name or path: Take, for instance, a website that allows you to upload your own images or avatar. Let’s take a look at this code example here:

This script demonstrates some vulnerable PHP that could lead to RCE because it doesn’t correctly validate uploads. A threat actor can prepare a PHP file named config.php containing malicious code. The file could contain code to create a backdoor, modify the application's behavior, or extract sensitive data.

File size or content: The script below demonstrates vulnerable PHP that can lead to unrestricted file uploads based on size. A threat actor can use this to damage systems, such as overloading a file system or even a database, which could cause downtime or a lack of availability of information necessary for websites or companies to operate.

Remediation: 

1. Validate and Sanitize File Names: Using an allowlist approach, you should validate file names and extensions. Only allow specific, safe file types.

2. Generate New File Names: In order to prevent overwriting existing files, you should generate a new, unique filename for each upload, such as a UUID or a hash of the file's contents.

3. Restrict File Access: Restricting file access is crucial to ensure RCE isn’t achieved. Store uploaded files outside the web root when possible and set correct file permissions to prevent execution.

4. File Content Verification: Verify the file's MIME type server-side to ensure it matches the expected types for the upload.

Number 4: Missing Authorization (Broken Access Control)

What is it? Missing authorization is often confused with missing authentication. However, similar in nature, we’re focusing specifically on missing access control checks for a given identity when they try to access a privileged resource. When there is missing authorization, the user could access information they shouldn’t access, such as an admin dashboard or privileged data. Authentication doesn’t immediately provide authorization.

Real-world scenario: Let’s say you’re logging into a patient portal (authentication), where you can access all the medical files of your doctor’s or medical practitioner’s patients. This type of authorization would be reserved for your doctor. Not everyone should have access to the private medical data of a practice’s patients. Therefore, having access as a user would be a case of missing authorization. This can also occur for unauthenticated users, not just authenticated ones.

How does it occur? This can occur in several ways, from organizations not enforcing the principle of least privilege, missing access controls to other parts of your infrastructure such as APIs, to modifying the access control checks which allow for users to send a modified URL which gives them access to data they’re unauthorized to view. Below is an example in PHP that demonstrates missing authorization by manipulating the user_id

Remediation: 

1. Enforce the principle of least privilege: The principle of least privilege allows users to access only what they need to function in their job or in the application they’re using, nothing more. This prevents users from being able to escalate privileges or access items that aren’t meant for them. For example, not all users should have admin access, as this could be catastrophic if an employee is fired and decides to damage systems or infrastructure, delete critical data, or otherwise disrupt day-to-day business operations.

2. Deny by default: When a user attempts to access a resource, the application must decide whether to permit or deny the user access to the requested resource(s), either actively or passively. As access control methods become more complex, logic-based vulnerabilities and flaws that allow authorization to be bypassed are very easy to introduce. Rather than relying on these intricate rules, the default should be to deny access to the resource if conditions are not met and allow the application to exit safely.

3. Test for Authorization Logic: Testing applications for Authorization Logic flaws can help catch the low-hanging fruit that can often be quickly remediated when inspected closer. You can test for various types of Authorization Logic Flaws, such as a modified parameter in a URL allowing users to browse to new resources without being authorized, such as a patient number being assigned in the portal (a User ID), and updating the user ID to be one number higher or lower would give you access to their information. This vulnerability is called an IDOR and is covered later in this blog post.

An example of the remediated code adding authorization check to confirm whether the user is both authenticated and authorized: 

Number 3: Subdomain Takeover (Due to Dangling CNAME Record)

What is it? Subdomain takeovers due to a dangling CNAME record occur more often and lie in the fact that the CNAME record points to a non-existent cloud service, making it vulnerable to a domain takeover attack. Threat actors could exploit this vulnerability to gain control of the domain and host potentially malicious content on a website, deface it, or use it for phishing your customers. Threat actors may also gain access to sensitive data sent to the domain, leading to data breaches and exposing confidential information.

How does it occur? This vulnerability occurs when organizations or websites forget to remove DNS entries for subdomains no longer in use or when the external services those subdomains point to are decommissioned without updating the DNS, such as a nonexistent cloud service. An example is test.example.com, which points to the following CNAME record → test-sc02.westeurope.cloudapp.azure.com on the Azure Cloud App. Threat actors can then access the Azure Cloud App and claim the service.

Remediation: The remediation is relatively simple. All you have to do is remove the dangling CNAME records from the domain www.test.example.com.

Number 2: Server-Side Request Forgery (SSRF)

What is SSRF? Server-side request forgery is often a critical vulnerability that allows unauthenticated and unauthorized attackers to read or write to internal resources. Manipulated and user-supplied input allows attackers to induce the server-side application to request HTTP to an arbitrary domain of the attacker's choice.

How does it occur? SSRF usually happens when a web application accepts a user-supplied URL and retrieves the contents of the URL on the server's behalf without adequately validating the supplied URL.

Remediation: Remediation for SSRF can be tricky and often depends on where the vulnerability lies; in a general sense, it is always best practice to implement allowlists for the IP addresses or domains that the server is allowed to communicate with; however, that cannot always be achieved especially when the application needs to send 

• SSRF Protection: Employ SSRF filters to block outgoing requests to unauthorized or unexpected domains and internal IP addresses.

Number 1: Insecure Direct Object References (IDOR)

What is IDOR? As previously mentioned, Insecure Direct Object References, or IDOR for short, occur when user-supplied URLs and their parameters are manipulated to allow browsing to otherwise restricted content. This happens when access controls, like authentication or authorization, are missing, which would normally verify whether the user should access the resource to begin with.

How does it occur? IDOR typically happens due to insufficient access control checks when an application uses predictable object references.

Remediation: To prevent Insecure Direct Object References (IDOR), it's crucial to implement stringent access control checks for each object user access. Web frameworks typically offer mechanisms to ease this implementation. Utilizing complex identifiers can serve as an additional layer of security; however, robust access controls remain essential. It's advised to refrain from using identifiers in URLs and POST bodies, opting to identify the authenticated user via session information and maintain identifiers in the session for multi-step processes to avoid tampering.

When accessing objects by primary keys, ensure that queries are limited to data the user can view. For instance, in Ruby on Rails, instead of querying all projects, restrict the query to those associated with the current user. Consistently verify user permissions upon each access attempt, adhering to best practices provided by your web framework.

For an extra layer of security, consider substituting simple numeric identifiers with complex, randomly generated identifiers, such as random strings or UUIDs, used within URLs instead of numeric primary keys. This approach minimizes the risk of enumeration attacks. Encrypting identifiers is generally not recommended due to the complexities of secure implementation.

While guarding against well-known vulnerabilities is crucial, those often an afterthought can pose significant threats if overlooked. By understanding these vulnerabilities and implementing the discussed remediation strategies, organizations can enhance their security and overall posture and protect themselves against a broader range of attacks.