Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Response header filtering does not work (set-cookie) #2552

Open
5 tasks done
ngoclong19 opened this issue Mar 20, 2023 · 11 comments
Open
5 tasks done

Response header filtering does not work (set-cookie) #2552

ngoclong19 opened this issue Mar 20, 2023 · 11 comments
Labels
bug Something isn't working

Comments

@ngoclong19
Copy link

ngoclong19 commented Mar 20, 2023

Prerequisites

  • I performed a cursory search of the issue tracker to avoid opening a duplicate issue.
  • The issue is not present after disabling uBO in the browser.
  • I checked the documentation to understand that the issue I am reporting is not normal behavior.

I tried to reproduce the issue when...

  • uBO is the only extension.
  • using a new, unmodified browser profile.

Description

I want to block a specific cookie on medium.com.
So, I try to delete the specific cookie in Firefox, then use uBlock to prevent the server from setting this cookie.
This cookie has attribute HttpOnly.

I could use the feature block all cookies for a website in Firefox.
But it seems that some website hosted by Medium will break with this setting.
I don't remember which website is broken though.

A specific URL where the issue occurs.

https://medium.com

Steps to Reproduce

  1. Open the URL
  2. Add this filter rule
    medium.com##^responseheader(set-cookie)
  3. Clear all cookie for medium.com
  4. Refresh the page.

Expected behavior

The response from server does not have a set-cookie header, no cookie will be set.

Actual behavior

The set-cookie header still exists, and cookie will be set.

Configuration

uBlock Origin: 1.47.4
Firefox: 111
filterset (summary):
  network: 0
  cosmetic: 0
  scriptlet: 0
  html: 0
listset (total-discarded, last-updated):
  removed:
    ublock-filters: null
    ublock-badware: null
    ublock-privacy: null
    ublock-abuse: null
    ublock-unbreak: null
    ublock-quick-fixes: null
    easylist: null
    easyprivacy: null
    urlhaus-1: null
    plowe-0: null
    VIE-1: null
  default:
    user-filters: 1-0, never
filterset (user): [array of 1 redacted]
modifiedUserSettings: [none]
modifiedHiddenSettings: [none]
supportStats:
  allReadyAfter: 562 ms (selfie)
  maxAssetCacheWait: 232 ms
@mapx-
Copy link
Contributor

mapx- commented Mar 20, 2023

I get no such set-cookie header on medium
I see one but arriving from https://play.google.com/log?format=json&hasfast=true&authuser=0

@ngoclong19
Copy link
Author

@mapx-, could you try again after clearing all cookies for medium.com?
I tried with Edge 111.0.1661.44 and the behavior is the same as Firefox.

When I start a new private browsing window, on first request to Medium, the server responses with two cookies, __cfruid and uid.
In the same browsing session, on subsequent requests, these two cookies are sent back, and they are not expired yet, it seems that the server will not issue a set-cookie header.

@mapx-
Copy link
Contributor

mapx- commented Mar 21, 2023

yes, you are right.

@uBlock-user uBlock-user added the bug Something isn't working label Mar 21, 2023
gorhill added a commit to gorhill/uBlock that referenced this issue Mar 21, 2023
@gwarser
Copy link

gwarser commented Mar 21, 2023

I see no difference. Does the fix work?

@gorhill
Copy link
Member

gorhill commented Mar 21, 2023

I fixed the filtering, it was broken since changes in static filtering parser. The issue here though won't fix filtering on Chromium-based browsers -- I haven't decided whether it's a wontfix for Chromium-based browsers.

Additionally, for any browser, the filtering will not occur when set-cookie is set on anything else than main_frame or sub_frame, response header filtering occurs only for main_frame/sub_frame, and I have to decide if I want to expand to cover all network requests.

@uBlock-user
Copy link
Contributor

I see no difference. Does the fix work?

Same here, no change whatsoever. "cfuid" is still being set by set-cookie header

@gorhill
Copy link
Member

gorhill commented Mar 21, 2023

If you block JS, the cookies won't be set, this means the set-cookie header is used on network requests other than main_frame/sub_frame.

@gorhill
Copy link
Member

gorhill commented Mar 21, 2023

To be clear, what I fixed with my commit above is not specifically the issue here. I fixed ^responseheader() being completely broken, not just set-cookie (regression).

There are two separate issues here which are not regression, and which I will address in the next dev cycle, I didn't want to hold any longer publishing the stable release:

  • Chromium requires using extraHeaders flag to allow removing set-cookie headers. It's not currently set. That flag is not needed on Firefox. I lean toward not using the flag and accepting that removing set-cookie does not work on Chromium-based browser.
  • The filtering occurs only for main_frame/sub_frame requests. I need to make a decision regarding this.

@MasterKia

This comment was marked as off-topic.

@gorhill

This comment was marked as off-topic.

@ngoclong19
Copy link
Author

The filtering occurs only for main_frame/sub_frame requests. I need to make a decision regarding this.

I think that only filtering on main request will not keep the cookie from being set.

For testing, I set Firefox to block all cookie from medium.com.
When I navigate to https://medium.com, I could observe the server is trying to set cookie in two requests here:

  • https://medium.com/ (GET, html)
  • https://medium.com/_/graphql (POST, json), this request is called multiple times

So, I think that if we only filter on main, the server can still set cookie on subsequent graphql requests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

6 participants