www.computerbase.de/einstellungen - Cross-Site-Request-Forgery Fehlalarm

For support with specific websites

Moderator: trava90

Forum rules
Please always mention the name/domain of the website in question in your topic title.
Please one website per topic thread (to help keep things organized). While behavior on different sites might at first glance seem similar, they are not necessarily caused by the same.

Please try to include any relevant output from the Toolkit Error Console or the Developer Tools Web Console using the following procedure:
  1. Clear any current output
  2. Navigate or refresh the page in question
  3. Copy and paste Errors or seemingly relevant Warnings into a single [ code ] block.
User avatar
rthxch
New to the forum
New to the forum
Posts: 2
Joined: 2021-04-28, 13:16

www.computerbase.de/einstellungen - Cross-Site-Request-Forgery Fehlalarm

Unread post by rthxch » 2025-01-22, 12:54

https://www.computerbase.de/einstellungen/
1. Setzen von:
Header absolut anstatt fix positionieren („kein Mitscrollen“)
2. dann Button
Speichern

es kommt:

Code: Select all

403 Forbidden (CSRF)

Wir haben die von deinem Browser gesendete Anfrage vorsichtshalber abgewiesen. Denn es gibt Anzeichen dafür, dass diese Anfrage nicht von Dir selbst, sondern von einem Dritten initiiert wurde – eine sogenannte Cross-Site-Request-Forgery.

Dieser Dritte könnte versucht haben, auf ComputerBase eine Aktion in Deinem Namen auszuführen. Das haben wir unterbunden. Falls Du einen Fehlalarm vermutest, dann beschreibe bitte in einer E-Mail an technik@computerbase.de, wie genau es zu diesem Fehler gekommen ist: Welche Seiten hast Du aufgerufen? Auf welche Links/Buttons hast Du geklickt?
Speichern der Einstellungen somit nicht mehr möglich.

Browser
PaleMoon 33.5.1 (32-bit) (2025-01-15)
Nach dem Update (von v33.5.0) auf diese Version waren die zuvor eingestellten Settings der Webseite weg - mit einer früheren Version von PaleMoon ging das, ist aber schon einen längere Zeit her - kann also nicht sagen abe welcher Version das nicht mehr funktionierte.
Ein Speichern ist nach dem Update mit PaleMoon nicht mehr möglich.
Es wurde zum Test auch extra ein neues, clean Profil angelegt -> gleiches Problem

Keine Probleme in anderen Browsern wie Firefox, Vivaldi, Edge, Brave.

Antwort vom Seiten-Betreiber
das passiert dann, wenn ein Browser bei POST-Requests
1) den Header "Sec-Fetch-Site" nicht sendet _und_
2) den Header "Origin" nicht sendet _und_
3) dann auch noch den "Referer"-Header fälscht/unterdrückt.
Das ist ein Bug in Palemoon, melde das bitte dort.

-----
English translation
https://www.computerbase.de/einstellungen/
1. Set by:
Absolutely position the header instead of fixed ("no scroll")
2. Then button
Save

It comes:

Code: Select all

403 Forbidden (CSRF)

As a precaution, we have rejected the request sent by your browser. Because there are signs that this request was not initiated by yourself, but by a third party-a so-called cross-site request-forery.

This third might have tried to carry out an action in your name on computer base. We prevented that. If you suspect a false alarm, please describe in an email to Technik@computerbase.de how exactly this error happened: Which pages did you call? Which links/buttons did you click on?
Save the settings anymore.

Browser
Palemoon 33.5.1 (32-bit) (2025-01-15)
After the update (from V33.5.0) on this version, the previously set settings on the website - with an earlier version of Palemoon, was possible, but it was a long time ago - so it cannot say from which version it no longer worked.
Saving is no longer possible after the update with Palemoon.
A new, clean profile was also created for the test -> same problem

No problems in other browsers such as Firefox, Vivaldi, Edge, Brave.

Answer by the page operator
This happens when a browser at Post-Requests
1) Not sending the "Sec-Fetch-Site" header _und_
2) Not sending the "Origin" header _und_
3) Then also falsified/suppressed the "speaker" header.
This is a bug in Palemoon, please report it there.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 36968
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: www.computerbase.de/einstellungen - Cross-Site-Request-Forgery Fehlalarm

Unread post by Moonchild » 2025-01-22, 15:46

They are wrong. This is a server-side problem.
We are sending both the sec-fetch-site and origin headers. I don't know what this "speaker" is supposed to be, but according to their response it should pass with any of the three present.
Also, yes, sec-fetch-site="none" is correct for document navigation according to the spec I followed when implementing sec-fetch-*.
Proof:
computerbase1.png
"The world will not be destroyed by those who do evil, but by those who watch them without doing anything." - Albert Einstein
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

User avatar
Steffen
Newbie
Newbie
Posts: 3
Joined: 2025-01-23, 14:20

Re: www.computerbase.de/einstellungen - Cross-Site-Request-Forgery Fehlalarm

Unread post by Steffen » 2025-01-23, 14:33

Hi,

I'm the web developer of ComputerBase and asked @rthxch as a Pale Moon user to submit this as a bug to the Pale Moon developers.

Pale Moon indeed does send correct "Origin" and "Referer" headers, sorry for getting this wrong! However, it sends a "Sec-Fetch-Site" header with a wrong value "none". The correct value according to web standards and MDN documentation (and what all other browsers like Chrome, Edge, Firefox, Safari, etc. send) is "same-origin".
  • same-origin: "The request initiator and the server hosting the resource have the same origin (same scheme, host and port)."
  • none: "This request is a user-originated operation. For example: entering a URL into the address bar, opening a bookmark, or dragging-and-dropping a file into the browser window."
I'm pretty sure that this is a bug in Pale Moon. If not then it would be a bug (and probably security) issue in all other browsers. Can you please have a look?

Thanks,
Steffen
Last edited by Steffen on 2025-01-23, 15:41, edited 1 time in total.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 36968
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: www.computerbase.de/einstellungen - Cross-Site-Request-Forgery Fehlalarm

Unread post by Moonchild » 2025-01-23, 15:09

Thanks for reaching out directly! I disagree with your assessment, though:

The web standard clearly says it should be "none" for a "navigation request" that was initiated by the user, see sec-fetch 2.3 step 4.
Pressing a button to trigger a POST is a user-initiated navigation request, so the standard clearly says that the headers that have to be sent must be Sec-Fetch-Mode: navigate and Sec-Fetch-Site: none. There is a note in the spec about what is considered "user-initiated":
Each user agent is likely to have a distinct set of interactions which might fall into one or the other category, ...
So even in the spec, there is a clear note that different browsers behave differently, and may determine user-initiated actions differently. We looked into this and discussed it at the time of implementation, specifically when looking at when to add Sec-Fetch-User headers. That granularity and trust level should be clear from the (rather messy) spec at the root of this.

That aside, it should also be noted that "navigate"/"none" should always be given a higher trust level than any of the other Sec-Fetch-Site header values, and your site is doing the opposite, blocking the navigation in a higher trust level situation. See sec-fetch 4.3 (my emphasis):
The former [sic: "webby" navigations] will be delivered with a Sec-Fetch-Site header whose value is same-origin, same-site, or cross-site, as appropriate. The latter [sic: user-initiated] will be distinguished with a value of none, as no specific site is actually responsible for the request, and it makes sense to allow servers to treat them as trusted, as they somehow represent a user’s direct intent.
I'd say that a user clicking a "save" button is indeed "direct intent". Please consider changing your behaviour.
"The world will not be destroyed by those who do evil, but by those who watch them without doing anything." - Albert Einstein
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

User avatar
satrow
Forum staff
Forum staff
Posts: 1910
Joined: 2011-09-08, 11:27

Re: www.computerbase.de/einstellungen - Cross-Site-Request-Forgery Fehlalarm

Unread post by satrow » 2025-01-23, 16:09

Just a heads up that Steffen's original Reply has been logged as Edited a short time after posting.

User avatar
Steffen
Newbie
Newbie
Posts: 3
Joined: 2025-01-23, 14:20

Re: www.computerbase.de/einstellungen - Cross-Site-Request-Forgery Fehlalarm

Unread post by Steffen » 2025-01-23, 16:14

Thanks again for the reply!

I'm not convinced that sending "none" for same-origin POST forms is correct but I agree that we should accept "same-site" and in particular "none" as valid values. This approach is used in these examples, too: https://web.dev/articles/fetch-metadata ... in_attacks

I have just deployed these changes, so this issue should be fixed!

Out of curiosity, in which cases _does_ Pale Moon use "same-origin"/"same-site" instead of "none"?

User avatar
Steffen
Newbie
Newbie
Posts: 3
Joined: 2025-01-23, 14:20

Re: www.computerbase.de/einstellungen - Cross-Site-Request-Forgery Fehlalarm

Unread post by Steffen » 2025-01-23, 16:17

satrow wrote:
2025-01-23, 16:09
Just a heads up that Steffen's original Reply has been logged as Edited a short time after posting.
Yes, initially I accidentally copy-pasted the "same-site" docs instead of the "same-origin" docs. Nothing else has changed (as you might be able to verify).

User avatar
RealityRipple
Keeps coming back
Keeps coming back
Posts: 810
Joined: 2018-05-17, 02:34
Location: Los Berros Canyon, California
Contact:

Re: www.computerbase.de/einstellungen - Cross-Site-Request-Forgery Fehlalarm

Unread post by RealityRipple » 2025-01-24, 18:05

I believe the two are mostly only seen for requests for resources from a site, not for the base html file. Even iframes are "sec-fetch-site: none" for the base file. However, if an HTML file is loaded via XHR or Fetch to be inserted into the existing page, it should be treated like a resource, iirc.

We had a small discussion about the bad organization of this standard in the bug report. I don't think MC's code went quite as strict as my interpretation, though, as on-page link clicking will not set "sec-fetch-user: !1" but it will keep "sec-fetch-site" set to "none" for the next page's request. Once again, the "purpose" rule in Section 4.3 kind of muddles up what should count as user-initiated and what should be kept secret from potentially automated requests.

Post Reply