[jira] [Commented] (OFBIZ-11306) POC for CSRF Token (CVE-2019-12425)
[ https://issues.apache.org/jira/browse/OFBIZ-11306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17076205#comment-17076205 ] ASF subversion and git services commented on OFBIZ-11306: - Commit 5c534a9f9824c5bac1c8312a8d50063ca8b5e766 in ofbiz-framework's branch refs/heads/trunk from Jacques Le Roux [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=5c534a9 ] Fixed: POC for CSRF Token (OFBIZ-11306) Fixes missing default NoCsrfDefenseStrategy in Header.ftl files > POC for CSRF Token (CVE-2019-12425) > --- > > Key: OFBIZ-11306 > URL: https://issues.apache.org/jira/browse/OFBIZ-11306 > Project: OFBiz > Issue Type: Sub-task > Components: ALL APPLICATIONS >Affects Versions: Upcoming Branch >Reporter: James Yong >Assignee: Jacques Le Roux >Priority: Minor > Labels: CSRF > Fix For: Upcoming Branch > > Attachments: CsrfTokenAjaxTransform.java, CsrfTokenTransform.java, > CsrfUtil.java, OFBIZ-11306-alternative merged with James's.patch, > OFBIZ-11306-alternative merged with James's.patch, OFBIZ-11306-alternative > merged with James's.patch, OFBIZ-11306-alternative.patch, > OFBIZ-11306-alternative.patch, OFBIZ-11306-alternative.patch, > OFBIZ-11306-alternative.patch, OFBIZ-11306-alternative.patch, > OFBIZ-11306-alternative.patch, OFBIZ-11306-alternative.patch, > OFBIZ-11306-alternative.patch, OFBIZ-11306-alternative.patch, > OFBIZ-11306-v2.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > partyTokenMap.webtools.txt > > > CRSF tokens are generated using SecureRandom class (maybe later a JWT with a > "time out"). > They are stored in the user sessions (for AJAX calls and unauthenticated HTTP > calls) or OFBiz UtilCache (for authenticated HTTP calls), and verified during > POST request. > # In *controllers* a new csrf-token attribute is added to the security tag to > exempt or force CSRF token check. > # In *Widget Forms* a hidden token field is auto-generated. > # In *FTL form* a CSRF token is passed through <@ofbizUrl> to automatise the > change. Using <@ofbizUrl> macro to generate the CSRF token means there is no > need to manually add the CSRF token field to each form in the ftl files. It > will save time for users doing custom implementation and maintenance. While > there is CSRF token in the form URL, the token is invalidated during form > submission. So it's unique and harmless even though the CSRF token of the > form submission is shown in the browser address bar. > # For *Ajax calls* an ajaxPrefilter function (observer on DOM ready) is added > through OfbizUtil.js (itself called at start in decorators and such) > # The html metadata is storing the csrf token used by JQuery AJAX. This token > will not change to another value after it is consumed > # Csrf tokens for the user are removed from the UtilCache when the user logs > out or session invalidated. > The general rule are as follows: > * RequestMap configured with 'get' method will be exempted from CSRF token > check. > * RequestMap configured with 'post' or 'all' method will be subjected to CSRF > token check. (Note there are discussions that RequestMap with ‘all’ method > should also not be subjected to CSRF token check. This will be done after > ensuring a separate uri is used when posting changes.) > * "main" request URIs are exempted from CSRF token check. > * Setting csrf-token to false or true on the Request Map will override the > general rules above. > To Discuss: > * Invalidate authenticated user session when CSRF token check fails. > * Configure the general rules in a Service method (which will be run inside > the constructor of RequestMap class) when determining the final > securityCsrfToken value. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11306) POC for CSRF Token (CVE-2019-12425)
[ https://issues.apache.org/jira/browse/OFBIZ-11306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17075768#comment-17075768 ] ASF subversion and git services commented on OFBIZ-11306: - Commit 0add8bedbca231ffd839eb733f1041ce5487e9d6 in ofbiz-framework's branch refs/heads/release18.12 from Jacques Le Roux [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=0add8be ] Merge branch 'JacquesLeRoux-POC-for-CSRF-Token-OFBIZ-11306' into trunk Because of GitHub message on PR56: This branch cannot be rebased due to conflicts Conflicts handled by hand RequestHandler.java > POC for CSRF Token (CVE-2019-12425) > --- > > Key: OFBIZ-11306 > URL: https://issues.apache.org/jira/browse/OFBIZ-11306 > Project: OFBiz > Issue Type: Sub-task > Components: ALL APPLICATIONS >Affects Versions: Upcoming Branch >Reporter: James Yong >Assignee: Jacques Le Roux >Priority: Minor > Labels: CSRF > Fix For: Upcoming Branch > > Attachments: CsrfTokenAjaxTransform.java, CsrfTokenTransform.java, > CsrfUtil.java, OFBIZ-11306-alternative merged with James's.patch, > OFBIZ-11306-alternative merged with James's.patch, OFBIZ-11306-alternative > merged with James's.patch, OFBIZ-11306-alternative.patch, > OFBIZ-11306-alternative.patch, OFBIZ-11306-alternative.patch, > OFBIZ-11306-alternative.patch, OFBIZ-11306-alternative.patch, > OFBIZ-11306-alternative.patch, OFBIZ-11306-alternative.patch, > OFBIZ-11306-alternative.patch, OFBIZ-11306-alternative.patch, > OFBIZ-11306-v2.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > partyTokenMap.webtools.txt > > > CRSF tokens are generated using SecureRandom class (maybe later a JWT with a > "time out"). > They are stored in the user sessions (for AJAX calls and unauthenticated HTTP > calls) or OFBiz UtilCache (for authenticated HTTP calls), and verified during > POST request. > # In *controllers* a new csrf-token attribute is added to the security tag to > exempt or force CSRF token check. > # In *Widget Forms* a hidden token field is auto-generated. > # In *FTL form* a CSRF token is passed through <@ofbizUrl> to automatise the > change. Using <@ofbizUrl> macro to generate the CSRF token means there is no > need to manually add the CSRF token field to each form in the ftl files. It > will save time for users doing custom implementation and maintenance. While > there is CSRF token in the form URL, the token is invalidated during form > submission. So it's unique and harmless even though the CSRF token of the > form submission is shown in the browser address bar. > # For *Ajax calls* an ajaxPrefilter function (observer on DOM ready) is added > through OfbizUtil.js (itself called at start in decorators and such) > # The html metadata is storing the csrf token used by JQuery AJAX. This token > will not change to another value after it is consumed > # Csrf tokens for the user are removed from the UtilCache when the user logs > out or session invalidated. > The general rule are as follows: > * RequestMap configured with 'get' method will be exempted from CSRF token > check. > * RequestMap configured with 'post' or 'all' method will be subjected to CSRF > token check. (Note there are discussions that RequestMap with ‘all’ method > should also not be subjected to CSRF token check. This will be done after > ensuring a separate uri is used when posting changes.) > * "main" request URIs are exempted from CSRF token check. > * Setting csrf-token to false or true on the Request Map will override the > general rules above. > To Discuss: > * Invalidate authenticated user session when CSRF token check fails. > * Configure the general rules in a Service method (which will be run inside > the constructor of RequestMap class) when determining the final > securityCsrfToken value. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11306) POC for CSRF Token (CVE-2019-12425)
[ https://issues.apache.org/jira/browse/OFBIZ-11306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17075765#comment-17075765 ] ASF subversion and git services commented on OFBIZ-11306: - Commit 27e57522b15d71352c61919befc6eb451ed4e864 in ofbiz-framework's branch refs/heads/release17.12 from Jacques Le Roux [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=27e5752 ] Merge branch 'JacquesLeRoux-POC-for-CSRF-Token-OFBIZ-11306' into trunk Because of GitHub message on PR56: This branch cannot be rebased due to conflicts Much Conflicts, but that should be OK > POC for CSRF Token (CVE-2019-12425) > --- > > Key: OFBIZ-11306 > URL: https://issues.apache.org/jira/browse/OFBIZ-11306 > Project: OFBiz > Issue Type: Sub-task > Components: ALL APPLICATIONS >Affects Versions: Upcoming Branch >Reporter: James Yong >Assignee: Jacques Le Roux >Priority: Minor > Labels: CSRF > Fix For: Upcoming Branch > > Attachments: CsrfTokenAjaxTransform.java, CsrfTokenTransform.java, > CsrfUtil.java, OFBIZ-11306-alternative merged with James's.patch, > OFBIZ-11306-alternative merged with James's.patch, OFBIZ-11306-alternative > merged with James's.patch, OFBIZ-11306-alternative.patch, > OFBIZ-11306-alternative.patch, OFBIZ-11306-alternative.patch, > OFBIZ-11306-alternative.patch, OFBIZ-11306-alternative.patch, > OFBIZ-11306-alternative.patch, OFBIZ-11306-alternative.patch, > OFBIZ-11306-alternative.patch, OFBIZ-11306-alternative.patch, > OFBIZ-11306-v2.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > partyTokenMap.webtools.txt > > > CRSF tokens are generated using SecureRandom class (maybe later a JWT with a > "time out"). > They are stored in the user sessions (for AJAX calls and unauthenticated HTTP > calls) or OFBiz UtilCache (for authenticated HTTP calls), and verified during > POST request. > # In *controllers* a new csrf-token attribute is added to the security tag to > exempt or force CSRF token check. > # In *Widget Forms* a hidden token field is auto-generated. > # In *FTL form* a CSRF token is passed through <@ofbizUrl> to automatise the > change. Using <@ofbizUrl> macro to generate the CSRF token means there is no > need to manually add the CSRF token field to each form in the ftl files. It > will save time for users doing custom implementation and maintenance. While > there is CSRF token in the form URL, the token is invalidated during form > submission. So it's unique and harmless even though the CSRF token of the > form submission is shown in the browser address bar. > # For *Ajax calls* an ajaxPrefilter function (observer on DOM ready) is added > through OfbizUtil.js (itself called at start in decorators and such) > # The html metadata is storing the csrf token used by JQuery AJAX. This token > will not change to another value after it is consumed > # Csrf tokens for the user are removed from the UtilCache when the user logs > out or session invalidated. > The general rule are as follows: > * RequestMap configured with 'get' method will be exempted from CSRF token > check. > * RequestMap configured with 'post' or 'all' method will be subjected to CSRF > token check. (Note there are discussions that RequestMap with ‘all’ method > should also not be subjected to CSRF token check. This will be done after > ensuring a separate uri is used when posting changes.) > * "main" request URIs are exempted from CSRF token check. > * Setting csrf-token to false or true on the Request Map will override the > general rules above. > To Discuss: > * Invalidate authenticated user session when CSRF token check fails. > * Configure the general rules in a Service method (which will be run inside > the constructor of RequestMap class) when determining the final > securityCsrfToken value. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11306) POC for CSRF Token (CVE-2019-12425)
[ https://issues.apache.org/jira/browse/OFBIZ-11306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17075769#comment-17075769 ] ASF subversion and git services commented on OFBIZ-11306: - Commit 9fa3dbe1eaaff766cf92c8f6f8e9913b0e8f5091 in ofbiz-framework's branch refs/heads/release18.12 from Jacques Le Roux [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=9fa3dbe ] Revert "Merge branch 'JacquesLeRoux-POC-for-CSRF-Token-OFBIZ-11306' into trunk" This reverts commit 0add8bedbca231ffd839eb733f1041ce5487e9d6. > POC for CSRF Token (CVE-2019-12425) > --- > > Key: OFBIZ-11306 > URL: https://issues.apache.org/jira/browse/OFBIZ-11306 > Project: OFBiz > Issue Type: Sub-task > Components: ALL APPLICATIONS >Affects Versions: Upcoming Branch >Reporter: James Yong >Assignee: Jacques Le Roux >Priority: Minor > Labels: CSRF > Fix For: Upcoming Branch > > Attachments: CsrfTokenAjaxTransform.java, CsrfTokenTransform.java, > CsrfUtil.java, OFBIZ-11306-alternative merged with James's.patch, > OFBIZ-11306-alternative merged with James's.patch, OFBIZ-11306-alternative > merged with James's.patch, OFBIZ-11306-alternative.patch, > OFBIZ-11306-alternative.patch, OFBIZ-11306-alternative.patch, > OFBIZ-11306-alternative.patch, OFBIZ-11306-alternative.patch, > OFBIZ-11306-alternative.patch, OFBIZ-11306-alternative.patch, > OFBIZ-11306-alternative.patch, OFBIZ-11306-alternative.patch, > OFBIZ-11306-v2.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > partyTokenMap.webtools.txt > > > CRSF tokens are generated using SecureRandom class (maybe later a JWT with a > "time out"). > They are stored in the user sessions (for AJAX calls and unauthenticated HTTP > calls) or OFBiz UtilCache (for authenticated HTTP calls), and verified during > POST request. > # In *controllers* a new csrf-token attribute is added to the security tag to > exempt or force CSRF token check. > # In *Widget Forms* a hidden token field is auto-generated. > # In *FTL form* a CSRF token is passed through <@ofbizUrl> to automatise the > change. Using <@ofbizUrl> macro to generate the CSRF token means there is no > need to manually add the CSRF token field to each form in the ftl files. It > will save time for users doing custom implementation and maintenance. While > there is CSRF token in the form URL, the token is invalidated during form > submission. So it's unique and harmless even though the CSRF token of the > form submission is shown in the browser address bar. > # For *Ajax calls* an ajaxPrefilter function (observer on DOM ready) is added > through OfbizUtil.js (itself called at start in decorators and such) > # The html metadata is storing the csrf token used by JQuery AJAX. This token > will not change to another value after it is consumed > # Csrf tokens for the user are removed from the UtilCache when the user logs > out or session invalidated. > The general rule are as follows: > * RequestMap configured with 'get' method will be exempted from CSRF token > check. > * RequestMap configured with 'post' or 'all' method will be subjected to CSRF > token check. (Note there are discussions that RequestMap with ‘all’ method > should also not be subjected to CSRF token check. This will be done after > ensuring a separate uri is used when posting changes.) > * "main" request URIs are exempted from CSRF token check. > * Setting csrf-token to false or true on the Request Map will override the > general rules above. > To Discuss: > * Invalidate authenticated user session when CSRF token check fails. > * Configure the general rules in a Service method (which will be run inside > the constructor of RequestMap class) when determining the final > securityCsrfToken value. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11306) POC for CSRF Token (CVE-2019-12425)
[ https://issues.apache.org/jira/browse/OFBIZ-11306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17075766#comment-17075766 ] ASF subversion and git services commented on OFBIZ-11306: - Commit 84e102a6a12f64687c54fe2635681b38ee8555a7 in ofbiz-framework's branch refs/heads/release17.12 from Jacques Le Roux [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=84e102a ] Revert "Merge branch 'JacquesLeRoux-POC-for-CSRF-Token-OFBIZ-11306' into trunk" This reverts commit 27e57522b15d71352c61919befc6eb451ed4e864. > POC for CSRF Token (CVE-2019-12425) > --- > > Key: OFBIZ-11306 > URL: https://issues.apache.org/jira/browse/OFBIZ-11306 > Project: OFBiz > Issue Type: Sub-task > Components: ALL APPLICATIONS >Affects Versions: Upcoming Branch >Reporter: James Yong >Assignee: Jacques Le Roux >Priority: Minor > Labels: CSRF > Fix For: Upcoming Branch > > Attachments: CsrfTokenAjaxTransform.java, CsrfTokenTransform.java, > CsrfUtil.java, OFBIZ-11306-alternative merged with James's.patch, > OFBIZ-11306-alternative merged with James's.patch, OFBIZ-11306-alternative > merged with James's.patch, OFBIZ-11306-alternative.patch, > OFBIZ-11306-alternative.patch, OFBIZ-11306-alternative.patch, > OFBIZ-11306-alternative.patch, OFBIZ-11306-alternative.patch, > OFBIZ-11306-alternative.patch, OFBIZ-11306-alternative.patch, > OFBIZ-11306-alternative.patch, OFBIZ-11306-alternative.patch, > OFBIZ-11306-v2.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > partyTokenMap.webtools.txt > > > CRSF tokens are generated using SecureRandom class (maybe later a JWT with a > "time out"). > They are stored in the user sessions (for AJAX calls and unauthenticated HTTP > calls) or OFBiz UtilCache (for authenticated HTTP calls), and verified during > POST request. > # In *controllers* a new csrf-token attribute is added to the security tag to > exempt or force CSRF token check. > # In *Widget Forms* a hidden token field is auto-generated. > # In *FTL form* a CSRF token is passed through <@ofbizUrl> to automatise the > change. Using <@ofbizUrl> macro to generate the CSRF token means there is no > need to manually add the CSRF token field to each form in the ftl files. It > will save time for users doing custom implementation and maintenance. While > there is CSRF token in the form URL, the token is invalidated during form > submission. So it's unique and harmless even though the CSRF token of the > form submission is shown in the browser address bar. > # For *Ajax calls* an ajaxPrefilter function (observer on DOM ready) is added > through OfbizUtil.js (itself called at start in decorators and such) > # The html metadata is storing the csrf token used by JQuery AJAX. This token > will not change to another value after it is consumed > # Csrf tokens for the user are removed from the UtilCache when the user logs > out or session invalidated. > The general rule are as follows: > * RequestMap configured with 'get' method will be exempted from CSRF token > check. > * RequestMap configured with 'post' or 'all' method will be subjected to CSRF > token check. (Note there are discussions that RequestMap with ‘all’ method > should also not be subjected to CSRF token check. This will be done after > ensuring a separate uri is used when posting changes.) > * "main" request URIs are exempted from CSRF token check. > * Setting csrf-token to false or true on the Request Map will override the > general rules above. > To Discuss: > * Invalidate authenticated user session when CSRF token check fails. > * Configure the general rules in a Service method (which will be run inside > the constructor of RequestMap class) when determining the final > securityCsrfToken value. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11306) POC for CSRF Token (CVE-2019-12425)
[ https://issues.apache.org/jira/browse/OFBIZ-11306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17075763#comment-17075763 ] ASF subversion and git services commented on OFBIZ-11306: - Commit ba707d45be6b2db77649a5e7695c089c36a0e8c5 in ofbiz-framework's branch refs/heads/trunk from Jacques Le Roux [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=ba707d4 ] Implemented: POC for CSRF Token (OFBIZ-11306) Simple strategy is to rely on SameSite 'strict' value in SameSiteFilter in all supported branches. No backport needed with the changes here. Thanks: James for all the good work we did together :) > POC for CSRF Token (CVE-2019-12425) > --- > > Key: OFBIZ-11306 > URL: https://issues.apache.org/jira/browse/OFBIZ-11306 > Project: OFBiz > Issue Type: Sub-task > Components: ALL APPLICATIONS >Affects Versions: Upcoming Branch >Reporter: James Yong >Assignee: Jacques Le Roux >Priority: Minor > Labels: CSRF > Fix For: Upcoming Branch > > Attachments: CsrfTokenAjaxTransform.java, CsrfTokenTransform.java, > CsrfUtil.java, OFBIZ-11306-alternative merged with James's.patch, > OFBIZ-11306-alternative merged with James's.patch, OFBIZ-11306-alternative > merged with James's.patch, OFBIZ-11306-alternative.patch, > OFBIZ-11306-alternative.patch, OFBIZ-11306-alternative.patch, > OFBIZ-11306-alternative.patch, OFBIZ-11306-alternative.patch, > OFBIZ-11306-alternative.patch, OFBIZ-11306-alternative.patch, > OFBIZ-11306-alternative.patch, OFBIZ-11306-alternative.patch, > OFBIZ-11306-v2.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > partyTokenMap.webtools.txt > > > CRSF tokens are generated using SecureRandom class (maybe later a JWT with a > "time out"). > They are stored in the user sessions (for AJAX calls and unauthenticated HTTP > calls) or OFBiz UtilCache (for authenticated HTTP calls), and verified during > POST request. > # In *controllers* a new csrf-token attribute is added to the security tag to > exempt or force CSRF token check. > # In *Widget Forms* a hidden token field is auto-generated. > # In *FTL form* a CSRF token is passed through <@ofbizUrl> to automatise the > change. Using <@ofbizUrl> macro to generate the CSRF token means there is no > need to manually add the CSRF token field to each form in the ftl files. It > will save time for users doing custom implementation and maintenance. While > there is CSRF token in the form URL, the token is invalidated during form > submission. So it's unique and harmless even though the CSRF token of the > form submission is shown in the browser address bar. > # For *Ajax calls* an ajaxPrefilter function (observer on DOM ready) is added > through OfbizUtil.js (itself called at start in decorators and such) > # The html metadata is storing the csrf token used by JQuery AJAX. This token > will not change to another value after it is consumed > # Csrf tokens for the user are removed from the UtilCache when the user logs > out or session invalidated. > The general rule are as follows: > * RequestMap configured with 'get' method will be exempted from CSRF token > check. > * RequestMap configured with 'post' or 'all' method will be subjected to CSRF > token check. (Note there are discussions that RequestMap with ‘all’ method > should also not be subjected to CSRF token check. This will be done after > ensuring a separate uri is used when posting changes.) > * "main" request URIs are exempted from CSRF token check. > * Setting csrf-token to false or true on the Request Map will override the > general rules above. > To Discuss: > * Invalidate authenticated user session when CSRF token check fails. > * Configure the general rules in a Service method (which will be run inside > the constructor of RequestMap class) when determining the final > securityCsrfToken value. -- This message was sent by Atlassian Jira (v8.3.4#803005)
