Fix #10249 cookies do not set samesite
attribute required by current browsers
#10374
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fix #10249 and salesagility/SuiteCRM-Core#447
samesite
default parameter toSugarApplication::setCookie()
. Required in modern web applications and current browsers.samesite
, inphp.ini
session.cookie_samesite
, to make this value upgrade safe. Without upgrade safe, every upgrade to the application could result in failure to login, when the deployment environment requires a default value other thanStrict
forsamesite
on the login related cookies.Description
Adds optional parameter
samesite
to the functionSugarApplication::setCookie()
.Default value is set to
Strict
.Default value can be changed in
php.ini
session.cookie_samesite
, to make this setting be upgrade safe. Some users who embed Suite in an iFrame of another web application on the top browser tab (e.g. call center) must useNone
for the application to load, because Suite's URL in its iFrame is a different domain than the main browser tab address URL.Motivation and Context
See RFC. To prevent Cross Site Request Forgery (CSRF), a hacking technique used to steal Suite and other web application user accounts, current browsers now expect
samesite
attribute on cookies, or else they'll be set to the default valueLax
. Setting this toStrict
by default, allows only the Suite application domain to access application cookies while the browser URL is the same as the cookie's. Third parties must not obtain user login cookies, otherwise they could steal user login session, and access private data in the system, etc.How To Test This
Before this change. Browse in the application in Chrome and Firefox. You'll see console warnings about soon ending support for cookies that do no have the attribute
samesite
. Checking with an extension "Cookies and Headers Analyzer" should show many cookies used by the application which have "secure" set to "false", and "samesite" unset.After the change. Those browser console warnings should be cleared. Cookies used by the application should be all "
secure
" set to "true
" and "samesite
" set to "Strict
".NOTE: for those running Suite on Apache in
http
mode behind a TLS proxy, this should continue to work, because the attribute "secure
" is only set to "true
" when the functionisSSL()
returnstrue
, which should be when the Suite Apache server is set to secure (SSL or TLS) mode, running onhttps
.NOTE 2: There may be scenarios where setting cookie attribute "
samesite
" to "Strict
" may break third party code, however, there must be other ways of passing information rather than allowing a third party application to have access to the application's user login cookies and have the ability to hijack user login sessions, steal user accounts, and obtain sensitive data stored by the application.Types of changes
Final checklist