You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Testing a way to mitigate the FlatPress cookies on an HTTP connection without leaving the door open to fools and charlatans.
It is also noticeable that the cookie does not deserve the "samesite" attribute for an HTTP connection, as a secure origin cannot be guaranteed.
Console output of the browser:
Cookie has been rejected because a non-HTTPS cookie can't be set as "secure"
Some cookies are misusing the recommended "samesite" attribute
However, the following points speak against such a measure:
1.) Login to a security-relevant area should only take place via a secure HTTPS connection. The cookies therefore require a secure cookie.
2.) Web servers can be accessible via HTTP or HTTPS connections or both. Although HTTPS is recommended in such a case, an attacker could use HTTP to abuse weakened security.
I am therefore of the opinion that the mitigation measures should be communicated in individual cases if only http is possible and/or the admin is aware of the risk.
I do not consider automatic mitigation for http requests to be sensible.
Notes:
A cookie that comes via an HTTP connection cannot have the "secure" flag and the "__secure-" attribute.
A cookie that comes via an HTTP connection must not have the "samesite" value "None", "Lax" or "Strict".
Cookies with the "secure" and "HTTPONLY" attribute are only permitted to be sent via HTTPS.
This raises the question of whether we still want to support HTTP connections at all.
How should FlatPress react if a query is possible via HTTP and HTTPS because there is no redirection to HTTPS?
If you want to do this balancing act, the following change would have to be made in the defaults.php file:
Testing a way to mitigate the FlatPress cookies on an HTTP connection without leaving the door open to fools and charlatans.
It is also noticeable that the cookie does not deserve the "samesite" attribute for an HTTP connection, as a secure origin cannot be guaranteed.
Console output of the browser:
Reason: #371
However, the following points speak against such a measure:
1.) Login to a security-relevant area should only take place via a secure HTTPS connection. The cookies therefore require a secure cookie.
2.) Web servers can be accessible via HTTP or HTTPS connections or both. Although HTTPS is recommended in such a case, an attacker could use HTTP to abuse weakened security.
I am therefore of the opinion that the mitigation measures should be communicated in individual cases if only http is possible and/or the admin is aware of the risk.
I do not consider automatic mitigation for http requests to be sensible.
Notes:
A cookie that comes via an HTTP connection cannot have the "secure" flag and the "__secure-" attribute.
A cookie that comes via an HTTP connection must not have the "samesite" value "None", "Lax" or "Strict".
Cookies with the "secure" and "HTTPONLY" attribute are only permitted to be sent via HTTPS.
Source references:
https://developers.google.com/search/blog/2020/01/get-ready-for-new-samesitenone-secure?hl=en
https://support.google.com/webmasters/thread/237722961/cookies-with-the-secure-and-httponly-attribute-are-only-permitted-to-be-sent-via-https?hl=en
This raises the question of whether we still want to support HTTP connections at all.
How should FlatPress react if a query is possible via HTTP and HTTPS because there is no redirection to HTTPS?
If you want to do this balancing act, the following change would have to be made in the defaults.php file:
From:
flatpress/defaults.php
Line 131 in c2cca73
To:
In order to integrate the "__secure-" prefix, the core.cookie.php file would also have to be adapted.
From:
flatpress/fp-includes/core/core.cookie.php
Line 11 in c2cca73
To:
The text was updated successfully, but these errors were encountered: