Closed Bug 1824551 Opened 2 years ago Closed 2 years ago

Same Origin Policy doesn't block the response from the request made with a different origin ( different port number)

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Version:
Firefox 111
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1751105

People

(Reporter: rafal.zebrowski2, Unassigned)

Details

Attachments

(4 files)

two GET requests from 127.0.0.1:5700 to 127.0.0.0.1:8000/api/users
703.65 KB, application/octet-stream
Details
log2.txt-main.7156.moz_log the same two requests
693.66 KB, application/octet-stream
Details
fastapi.zip
1.61 KB, application/zip
Details
nightly-cmslog.log
3.18 KB, text/plain
Details

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/111.0

Steps to reproduce:

I made a simple request from http://127.0.0.1:5500/ (Visual Code Studio Live Server):

const button2 = document.getElementById("button2");
button2.addEventListener("click", () => {
  fetch("http://127.0.0.1:8000/")
    .then((response) => {
      return response.json();
    })
    .then((data) => console.log(data));
});

to the simple FastAPI/Uvicorn server running on http://127.0.0.1:8000/:

# main.py
from fastapi import FastAPI

app = FastAPI()

@app.get("/")
async def root():
    return {"message": "Hello World"}

Kubuntu 22.04, Firefox 111.0.1

Actual results:

Console printed response data Object { message: "Hello World" }, request/response in network tab is showed as not blocked (green status code).

Expected results:

Console should print Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://127.0.0.1:8000/. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing). Status code: 200. . and the request/response in the network tab should be red

Every other browser blocks access to the response from http://127.0.0.1:8000/ to http://127.0.0.1:5500/ including Firefox 111.0.1 on Windows 10.
Firefox 107.0 running on Linux Mint doesn't block it either.

More details:
https://www.reddit.com/r/firefox/comments/11zg1g7/11101_same_origin_policy_ignores_a_different_port/
https://www.reddit.com/r/firefox/comments/121km58/11101_linux_potential_security_issue_related_to/

Setting this to Core > Networking, so that our engineers could take a closer look at this issue. If this is not the right component, please assign a more suitable one.
Thanks!

Component: Untriaged → Networking
Product: Firefox → Core

Thank you for your report.
I'm unable to reproduce this locally with 2 simple nodejs servers.
I assume this is something caused by the VS code live server. Could you serve your web page from a regular web server instead and see if it's still behaving incorrectly? (Also check if you have any installed extensions)

Flags: needinfo?(rafal.zebrowski2)

Here is a video in which I'm making a request from VSCode Server and from node server to show what's going on https://streamable.com/8a6wzu (I also noticed a 2nd bug while recording).
Sorry for quality, I guess streamable offers 720p for free.

2nd bug - around 1:40 you can see that if I click fast on a button some requests are not blocked even from localhost:5500, but hey don't show anything in the console.

Flags: needinfo?(rafal.zebrowski2)

I should also add that the same thing is happening i regular mode (not private browsing).

(In reply to Valentin Gosu [:valentin] (he/him) from comment #2)

I assume this is something caused by the VS code live server. Could you serve your web page from a regular web server instead and see if it's still behaving incorrectly? (Also check if you have any installed extensions)

I disabled extensions (and the same thing is happening on freshly installed Firefox 107.0 on Linux Mint).

Last comment as I can't find an edit button. This behavior (reading response from 127.0.0.1:8000) is only happening on Firefox on Linux no other browser does that (even mentioned Firefox on Windows 10) so the type of server should not play a role here.

I haven't managed to reproduce this bug, but hiding it just in case.

2nd bug - around 1:40 you can see that if I click fast on a button some requests are not blocked even from localhost:5500, but hey don't show anything in the console.

I think that's just a race with the devtools UI.
I'll file a different one once I figure this out.

I strongly suspect the VSCode injection has an effect here so I'll try with that.

Group: network-core-security

I had no luck reproducing this. I don't think I was doing anything differently from what I could see in your screen capture.
Would you be able to capture some logs while reproducing the logs?
https://firefox-source-docs.mozilla.org/networking/http/logging.html

Thank you!

Flags: needinfo?(rafal.zebrowski2)

Log module selection: timestamp,sync,nsHttp:5,cache2:5,nsSocketTransport:5,nsHostResolver:5

Flags: needinfo?(rafal.zebrowski2)

Another video this time to the Django Dev Server running on :8000 from the node frontend running on :5700- same request that I made while creating a logfile, https://streamable.com/sek7mr (log file has turned off extensions).

Thank you for the logs. It is quite odd that this is happening. It's still not obvious why the CORS check isn't failing.

Could you check once more with a few changes?
Add CSMLog:5 to the list of log modules.
Set the network.http.rcwn.enabled pref to false in about:config.

It's pretty clear by now that Firefox is doing something wrong, so you can probably stop recording the Chrome version.
Additionally, could you paste the contents of about:support here? Thanks!

Flags: needinfo?(rafal.zebrowski2)

timestamp,sync,nsHttp:5,cache2:5,nsSocketTransport:5,nsHostResolver:5,CSMLog:5

network.http.rcwn.enabled set to false

Flags: needinfo?(rafal.zebrowski2)

Additionally, could you paste the contents of about:support here? Thanks!

Keep in mind that I had the same behavior on a different PC (laptop) that had a freshly installed Linux MInt and not updated Firefox 107.0

Attached file fastapi.zip —

I could reproduce

With the attached test server:

$ ./main.py

Accessing it from http://127.0.0.1:8000/index.html and clicking on the second button leads to no CORS errors. http://localhost:8000/index.html also doesn't show the CORS error when changing the fetch to fetch("http://localhost:5500/") in static/main.js.

Attached file nightly-cmslog.log —
Interestingly I can't reproduce with my local build. Only with nightly: CSMLog:5 has one difference, but doesn't look related ```diff $ diff local nightly 23c23 < [Child 470787: Main Thread]: V/CSMLog - HTTPS_ONLY_EXEMPT --- > [Child 470787: Main Thread]: V/CSMLog - HTTPS_ONLY_TOP_LEVEL_LOAD_IN_PROGRESS 48c48 < [Parent 470295: Main Thread]: V/CSMLog - HTTPS_ONLY_EXEMPT --- > [Parent 470295: Main Thread]: V/CSMLog - HTTPS_ONLY_TOP_LEVEL_LOAD_IN_PROGRESS ```

(In reply to Manuel Bucher [:manuel] from comment #16)

Interestingly I can't reproduce with my local build. Only with nightly:
CSMLog:5 has one difference, but doesn't look related

$ diff local nightly
23c23
< [Child 470787: Main Thread]: V/CSMLog     - HTTPS_ONLY_EXEMPT
---
> [Child 470787: Main Thread]: V/CSMLog     - HTTPS_ONLY_TOP_LEVEL_LOAD_IN_PROGRESS
48c48
< [Parent 470295: Main Thread]: V/CSMLog     - HTTPS_ONLY_EXEMPT
---
> [Parent 470295: Main Thread]: V/CSMLog     - HTTPS_ONLY_TOP_LEVEL_LOAD_IN_PROGRESS

AIUI your local build thinks the request is exempt from https only mode, and your nightly doesn't. Is the https only config different between them?

I don't know this code at all, but I noticed in comment 13 that the reporter has https only mode enabled in both normal and private mode. This isn't the case by default. I wonder if this issue only reproduces with https only mode enabled?

I wonder if this issue only reproduces with https only mode enabled?

with HTTPS-Only Mode set to Don’t enable HTTPS-Only Mode
response is blocked on my end.

Dupe of bug 1751105?

Ah, yes. That seems to be the case. Thank you all for helping figure this out.

Group: network-core-security
Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Duplicate of bug: 1751105
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: