Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Referrer header missing from video (and audio) requests

RESOLVED FIXED

Status

()

Core
Audio/Video
--
major
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: Remy Sharp, Assigned: cajbir)

Tracking

Trunk
x86
All
Points:
---
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(blocking2.0 final+, status2.0 wanted, status1.9.2 wanted, status1.9.1 wanted)

Details

(Whiteboard: [sg:want] server dos-prevention, URL)

Attachments

(1 attachment, 3 obsolete attachments)

(Reporter)

Description

7 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_3; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.125 Safari/533.4
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6

All http in the browser send a referrer header, except the new video, source and audio elements.  This means that we can't prevent someone from hotlinking the content from a site by using a simple referral check technique.

This recently took down my server because a very high traffic site was linking directly to the video and the server couldn't cope.  I should have been able to prevent it from continuing by preventing hotlinking, but there's no referrer header being sent (all other headers are fine).  Opera does this correctly and sends the headers.

The result was I had to remove the video entirely from http://html5demos.com/video

Reproducible: Always

Steps to Reproduce:
Run this HTML and inspect the request headers in Firebug - a plain image and script are there for reference:

<!DOCTYPE html> 
<title>video refer test</title> 
<body>
<img src="image-for-reference" /> 
<video src="video-via-src-attribute"></video> 
<video> 
  <source src="video-via-src-element"></source> 
</video> 
<script src="script-for-reference"></script>
</body>
Actual Results:  
No referrer headers on the video, but we do have them on the image and script.

Expected Results:  
Correct referrers for media elements.
This is a valid bug and an important anti-abuse feature as described above.
Blocks: 61660
Status: UNCONFIRMED → NEW
blocking2.0: --- → ?
status1.9.1: --- → wanted
status1.9.2: --- → wanted
status2.0: --- → wanted
Component: General → Video/Audio
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → video.audio
Whiteboard: [sg:want] server dos-prevention
Version: unspecified → Trunk
OS: Mac OS X → All
(Assignee)

Updated

7 years ago
Assignee: nobody → chris.double
(Assignee)

Comment 2

7 years ago
Created attachment 465058 [details] [diff] [review]
Send Referer header with media requests
Attachment #465058 - Flags: review?(roc)
Comment on attachment 465058 [details] [diff] [review]
Send Referer header with media requests

Could use a test
Attachment #465058 - Flags: review?(roc) → review+
blocking2.0: ? → final+
Flags: in-testsuite?
(Assignee)

Comment 4

7 years ago
Created attachment 475592 [details] [diff] [review]
Test that referer is sent

For the test I have an sjs that checks the referer. If it exists then it returns a video otherwise it returns a 404.
Attachment #475592 - Flags: review?(roc)
The test is only going to work if Ogg is enabled. I think you could take the filename as a query parameter in the URL, then the test JS can select a file name that's supported and pass that to the sjs.
(Assignee)

Comment 6

7 years ago
Yeah I did it this way because we took the same approach in another bug after discussion that we always have ogg enabled in our test machines.
(Assignee)

Comment 7

7 years ago
I'll change it to not need any specific backend.
(Assignee)

Comment 8

7 years ago
Created attachment 475705 [details] [diff] [review]
Test that referer is sent

Changes test to iterate through one of the manifest list of files, looks for only those we can play and tests referer on them.
Attachment #475592 - Attachment is obsolete: true
Attachment #475705 - Flags: review?(roc)
Attachment #475592 - Flags: review?(roc)
Attachment #475705 - Flags: review?(roc) → review+
(Assignee)

Comment 9

7 years ago
Created attachment 475898 [details] [diff] [review]
Rolled up and rebased patch

Rolled up patch and rebased to trunk. Carried r+ forward.
Attachment #465058 - Attachment is obsolete: true
Attachment #475705 - Attachment is obsolete: true
Attachment #475898 - Flags: review+

Comment 10

7 years ago
http://hg.mozilla.org/mozilla-central/rev/bd0adbe793f3
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.