Closed Bug 1567573 Opened 5 years ago Closed 5 years ago

Referrer-Policy header ignored for HTTP 302

Categories

(Core :: DOM: Security, defect, P1)

68 Branch
defect

Tracking

()

RESOLVED FIXED
mozilla70
Tracking Status
firefox70 --- fixed

People

(Reporter: mike, Assigned: tnguyen)

References

Details

(Whiteboard: [domsecurity-active])

Attachments

(1 file)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.1.1 Safari/605.1.15

Steps to reproduce:

On a single sign-on application the user is redirected to my application and passes a secret as a GET parameter. The application then returns an HTTP 302 response with a Referrer-Policy: origin header to prevent the secret from being passed to the third party service.

HTTP/1.1 302 Found
Date: Fri, 19 Jul 2019 17:41:13 GMT
Content-Type: text/html; charset=utf-8
Connection: close
Location: https://thirdparty.com/access/jwt?jwt={secret2}
Referrer-Policy: origin

Actual results:

Firefox sent the full Referer header to the third party, including the secret:

GET /access/jwt?jwt={secret2} HTTP/1.1
Host: thirdparty.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Firefox/68.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://mysite.com/auth?jwt={secret1}

Expected results:

By the spec this should have only sent a Referer of https://mysite.com. Google Chrome exhibits the correct behavior.

Component: Untriaged → DOM: Security
Product: Firefox → Core
Assignee: nobody → tnguyen
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

Thomas, can you please find out if this was regressed by one of your patches? If so, we would need to uplift the fix.

Flags: needinfo?(tnguyen)

(In reply to Christoph Kerschbaumer [:ckerschb] from comment #1)

Thomas, can you please find out if this was regressed by one of your patches? If so, we would need to uplift the fix.

No. It has been for a while, but let me see how much we should change and if it's worth doing uplift

Flags: needinfo?(tnguyen)

(In reply to Thomas Nguyen from comment #2)

(In reply to Christoph Kerschbaumer [:ckerschb] from comment #1)

Thomas, can you please find out if this was regressed by one of your patches? If so, we would need to uplift the fix.

No. It has been for a while, but let me see how much we should change and if it's worth doing uplift

How long? Can you find out when the stopped working? Or did it never work?

Flags: needinfo?(tnguyen)

I think it has never worked before. We supported update 302 referrer-policy only in fetch API but it seems to be not enough

Flags: needinfo?(tnguyen)
Priority: -- → P1
Attachment #9079749 - Attachment description: Bug 1567573 - Apply new Referrer-Policy header from 302 redirect → Bug 1567573 - Apply Referrer-Policy header from 302 redirect
Attachment #9079749 - Attachment description: Bug 1567573 - Apply Referrer-Policy header from 302 redirect → Bug 1567573 - Apply Referrer-Policy header from redirect response
Whiteboard: [domsecurity-active]
Pushed by tnguyen@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/3aba5cc510f7
Apply Referrer-Policy header from redirect response r=michal
Regressions: 1569711
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla70
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: