If you’re building web apps in Ruby on Rails, you’re probably familiar with the redirect_to helper. But did you know that up until recently, it had a surprising bug? CVE-2023-28362 revealed that redirect_to could allow invalid characters through, which could break strict HTTP proxies or load balancers.

Let’s dive into what happened, check out some code, and see exactly how this could be abused in the wild.

What is CVE-2023-28362?

This vulnerability affects Rails, specifically the redirect_to method. In short, Rails didn’t fully sanitize the URLs provided to redirect_to, allowing illegal characters (like newlines or carriage returns) in the Location header.

While most browsers are forgiving, some HTTP proxies, load balancers, or gateways strictly validate headers according to RFC 723 or RFC 911. If they spot those illegal characters, they might strip the Location header from the response entirely. The result? Your users don’t get redirected as you planned, and—worse—a malicious actor could potentially exploit this for strange effects or even attacks.

Here’s a classic example in a Rails controller

# Vulnerable Rails Controller (prior to the fix)

class PostsController < ApplicationController
  def show
    url = params[:redirect_url]
    redirect_to url
  end
end

If someone hits /posts/1?redirect_url=https://example.com, this works fine. But imagine an attacker trying:

/posts/1?redirect_url=https://attacker.com%d%aX-Injected-Header:malicious

The %d%a are URL-encoded representations of carriage return (CR) and line feed (LF)—together, these can break HTTP headers.

Rails would decode this and produce a header like

Location: https://attacker.com
X-Injected-Header:malicious

Some systems would panic, tossing out the header, or potentially misinterpreting the request. It can even enable HTTP response splitting in rare cases, which can be used for phishing or session fixation.

Digging Deeper: The Real-World Exploit

Imagine this vulnerable Rails app sitting behind a proxy that enforces RFC compliance (e.g., AWS ALB, Cloudflare, or an enterprise gateway). When the header is malformed, the proxy strips it. Instead of a redirect, the user gets the original page, or a confusing error instead.

Cause the app to behave unexpectedly.

That’s why it’s a *serious* issue, even though it might seem like a harmless “oops” at first glance.

How Do You Fix It?

The official Rails patch ensures that the redirect_to helper only accepts valid URLs and does proper sanitization on all inputs.

DON’T

# UNSAFE: Don't pass user input directly to redirect_to
redirect_to params[:url]

Validate and sanitize incoming URLs — or, even better, whitelist only certain URLs/domains

# Safer: Only allow relative paths
def safe_redirect
  target = params[:url]
  if target.present? && target.start_with?('/')
    redirect_to target
  else
    redirect_to root_path
  end
end

And make sure your Rails version is at least:
6..6.1, 6.1.7.3, or 7..4.3 (or newer)!
See the Rails security advisory for more.
Official CVE entry: CVE-2023-28362

Bottom Line

CVE-2023-28362 is about how a little carelessness with input validation can cause problems further downstream—sometimes far beyond your own app. Especially if your app is sitting in a complex cloud or enterprise setup, the impact could vary.

Want to play with this? Here’s a minimal test case for older Rails, using curl

curl -v "http://localhost:300/posts/1?redirect_url=https://example.com%d%aX-Injected-Header:evil"

Check your app and upgrade your gems.
Security is everyone’s job — even for simple helpers like redirect_to.

References & Further Reading

- Rails Security Advisory: CVE-2023-28362
- National Vulnerability Database: CVE-2023-28362
- OWASP: HTTP Response Splitting

Timeline

Published on: 01/09/2025 01:15:07 UTC
Last modified on: 01/09/2025 22:15:26 UTC