Cookies set by web pages, loaded by HTTPS, are also sent back to the server on request to the same hostname with HTTP. That gives a person with evil intent the ability to steal information and even hijack a login session.
Recently Mozilla Firefox started complaining, in the developer console, about cookies being vulnerable:
Cookie "return_to" will be soon rejected because it has the "SameSite" attribute set to "None" or an invalid value, without the "secure" attribute.
The default SameSite handling can be changed in Firefox Advanced Preferences, by writing
about:configin the addressbar and then search for:
This is good for testing, but it is not a solution. The solution has to be done server-side.
Google Chrome has also implemented a similar cookie protection solution.
Set secure cookies in DominoSetting a cookie from a Notes form, is done by calling:
The secure solution is:
@SetHTTPHeader("Set-Cookie"; "name=value; SameSite=Strict; Secure")
Securing Dominos multi server LtpaToken cookieIf you are using Dominos multiple servers session based login, it needs some tweaking too. In the Domino Directory, the SSO configuration is found in the Internet Sites view.
On the Basic tab you need to change:
"Require SSL protected communication (HTTPS)" to "Enabled".
"Restrict use of the SSO token to HTTP/HTTPS" to "Enabled".
ValidationAfter restarting the Domino HTTP task, the LtpaToken cookie is secured:
Cookie shown in the Firefox developer tools.
Securing Dominos single server DomAuthSessId cookieIf you are using Dominos single server session based login, it needs some tweaking too. In the Domino Directory, the website configuration is found in the Internet Sites view.
The validation is the same as with the multi server LtpaToken cookie.
- SameSite cookie - MDN
- Reject insecure SameSite=None cookies - Chrome Platform Status
- RFC 6265 HTTP State Management Mechanism