[jira] [Issue Comment Deleted] (OFBIZ-11306) POC for CSRF Token
[ https://issues.apache.org/jira/browse/OFBIZ-11306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-11306: Comment: was deleted (was: Hi Jacques, we should stop hijacking the issue for these discussions (I did it too here and stop it now because it is the wrong place). Maybe we should remove the comments there and discuss further in the dev mailing list. Regards, Michael ) > POC for CSRF Token > -- > > Key: OFBIZ-11306 > URL: https://issues.apache.org/jira/browse/OFBIZ-11306 > Project: OFBiz > Issue Type: Improvement > 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-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_Plugins.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch > > > 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 uniqueand 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 implement: > * -Allow token map size to be configurable in properties.- OK that's done > locally > 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] [Issue Comment Deleted] (OFBIZ-11306) POC for CSRF Token
[ https://issues.apache.org/jira/browse/OFBIZ-11306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-11306: Comment: was deleted (was: Sorry to make this issue more confusing, but since we are on it and before we write that in stone using the related wiki page. I wrote: bq. The reasons I'd privilege cloned user repositories is about responsability and proliferation of branches in official repos. That would uselessly clutter the repo and scramble things. Anyway, again that's not mine to decide but the community... Actually if you think about it these options are not contradictory. We could use both. When we agree that sufficient work has been done in a cloned repo then we can create an OFBiz repo branch before possibly committing it. What I wonder about is if we need to keep it later?) > POC for CSRF Token > -- > > Key: OFBIZ-11306 > URL: https://issues.apache.org/jira/browse/OFBIZ-11306 > Project: OFBiz > Issue Type: Improvement > 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-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_Plugins.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch > > > 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 uniqueand 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 implement: > * -Allow token map size to be configurable in properties.- OK that's done > locally > 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] [Issue Comment Deleted] (OFBIZ-11306) POC for CSRF Token
[ https://issues.apache.org/jira/browse/OFBIZ-11306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-11306: Comment: was deleted (was: bq. Yes, my main point is that we should avoid committing (portions) of a new feature into trunk directly until the feature is finished, reviewed, testet and accepted. It avoids cluttering the history, having to revert commits and also having unfinished work in trunk if the work got stuck etc. +1 bq. With git we have several ways to achieve that. Personally I have no problems with feature branches in the main repository (that's how we organize our work here at ecomify), but having it in cloned user repositories is also fine. The reasons I'd privilege cloned user repositories is about responsability and proliferation of branches in official repos. That would uselessly clutter the repo and scramble things. Anyway, again that's not mine to decide but the community... ) > POC for CSRF Token > -- > > Key: OFBIZ-11306 > URL: https://issues.apache.org/jira/browse/OFBIZ-11306 > Project: OFBiz > Issue Type: Improvement > 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-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_Plugins.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch > > > 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 uniqueand 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 implement: > * -Allow token map size to be configurable in properties.- OK that's done > locally > 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] [Issue Comment Deleted] (OFBIZ-11306) POC for CSRF Token
[ https://issues.apache.org/jira/browse/OFBIZ-11306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-11306: Comment: was deleted (was: A community member's fork from the Github repository is - in essence - not different to an organisation's fork in a private environment. Both are expected to have development/feature branches and both can have release branches and tags based on different criteria than those of the project. That is one of the key benefits of the git's approach to version control and collaboration.) > POC for CSRF Token > -- > > Key: OFBIZ-11306 > URL: https://issues.apache.org/jira/browse/OFBIZ-11306 > Project: OFBiz > Issue Type: Improvement > 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-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_Plugins.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch > > > 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 uniqueand 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 implement: > * -Allow token map size to be configurable in properties.- OK that's done > locally > 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] [Issue Comment Deleted] (OFBIZ-11306) POC for CSRF Token
[ https://issues.apache.org/jira/browse/OFBIZ-11306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-11306: Comment: was deleted (was: Yes, my main point is that we should avoid committing (portions) of a new feature into trunk directly until the feature is finished, reviewed, testet and accepted. It avoids cluttering the history, having to revert commits and also having unfinished work in trunk if the work got stuck etc. With git we have several ways to achieve that. Personally I have no problems with feature branches in the main repository (that's how we organize our work here at ecomify), but having it in cloned user repositories is also fine.) > POC for CSRF Token > -- > > Key: OFBIZ-11306 > URL: https://issues.apache.org/jira/browse/OFBIZ-11306 > Project: OFBiz > Issue Type: Improvement > 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-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_Plugins.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch > > > 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 uniqueand 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 implement: > * -Allow token map size to be configurable in properties.- OK that's done > locally > 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] [Issue Comment Deleted] (OFBIZ-11306) POC for CSRF Token
[ https://issues.apache.org/jira/browse/OFBIZ-11306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-11306: Comment: was deleted (was: I think that before possibly discussing Git workflow we need to complete OFBIZ-11301, could be part of it also.) > POC for CSRF Token > -- > > Key: OFBIZ-11306 > URL: https://issues.apache.org/jira/browse/OFBIZ-11306 > Project: OFBiz > Issue Type: Improvement > 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-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_Plugins.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch > > > 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 uniqueand 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 implement: > * -Allow token map size to be configurable in properties.- OK that's done > locally > 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] [Issue Comment Deleted] (OFBIZ-11306) POC for CSRF Token
[ https://issues.apache.org/jira/browse/OFBIZ-11306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-11306: Comment: was deleted (was: Michael, BTW maybe we don't need to discuss all that about feature branch under OFBiz repo. See's Pierre proposition in OFBIZ-10577 I seconded at https://s.apache.org/jmls7) > POC for CSRF Token > -- > > Key: OFBIZ-11306 > URL: https://issues.apache.org/jira/browse/OFBIZ-11306 > Project: OFBiz > Issue Type: Improvement > 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-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_Plugins.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch > > > 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 uniqueand 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 implement: > * -Allow token map size to be configurable in properties.- OK that's done > locally > 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] [Issue Comment Deleted] (OFBIZ-11306) POC for CSRF Token
[
https://issues.apache.org/jira/browse/OFBIZ-11306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Le Roux updated OFBIZ-11306:
Comment: was deleted
(was: Here isthe solution for SetTimeZoneFromBrowser
{noformat}
diff --git themes/common-theme/webapp/common/js/util/setUserTimeZone.js
themes/common-theme/webapp/common/js/util/setUserTimeZone.js
index 4c29928..340182f 100644
--- themes/common-theme/webapp/common/js/util/setUserTimeZone.js
+++ themes/common-theme/webapp/common/js/util/setUserTimeZone.js
@@ -24,6 +24,9 @@
$.ajax({
url: "SetTimeZoneFromBrowser",
type: "POST",
+beforeSend: function(xhr,settings) {
+xhr.setRequestHeader("X-CSRF-Token",
$("meta[name='csrf-token']").attr("content"));
+ },
async: false,
data: "localeName=" + timezone,
error: function(error) {
{noformat}
)
> POC for CSRF Token
> --
>
> Key: OFBIZ-11306
> URL: https://issues.apache.org/jira/browse/OFBIZ-11306
> Project: OFBiz
> Issue Type: Improvement
> Components: ALL APPLICATIONS
>Affects Versions: Upcoming Branch
>Reporter: James Yong
>Assignee: Jacques Le Roux
>Priority: Minor
> Labels: CSRF
> Fix For: Upcoming Branch
>
> Attachments: 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_Plugins.patch, OFBIZ-11306_Plugins.patch,
> OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch,
> OFBIZ-11306_Plugins.patch
>
>
> CRSF tokens are generated using SecureRandom class.
> 1) In widget form where a hidden token field is auto-generated.
> 2) In FTL form where a <@csrfTokenField> macro is used to generate the csrf
> token field.
> 3) In Ajax call where a <@csrfTokenAjax> macro is used to assign csrf token
> to X-CSRF-Token in request header.
> CSRF tokens are stored in the user sessions, and verified during POST request.
> A new attribute i.e. csrf-token is added to the security tag to exempt CSRF
> token check.
> Certain request path, like LookupPartyName, can be exempt from CSRF token
> check during Ajax POST call.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Issue Comment Deleted] (OFBIZ-11306) POC for CSRF Token
[
https://issues.apache.org/jira/browse/OFBIZ-11306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Le Roux updated OFBIZ-11306:
Comment: was deleted
(was: For SetTimeZoneFromBrowser we can use a get method, the same in Webpos:
{code:xml}
{code})
> POC for CSRF Token
> --
>
> Key: OFBIZ-11306
> URL: https://issues.apache.org/jira/browse/OFBIZ-11306
> Project: OFBiz
> Issue Type: Improvement
> Components: ALL APPLICATIONS
>Affects Versions: Upcoming Branch
>Reporter: James Yong
>Assignee: Jacques Le Roux
>Priority: Minor
> Labels: CSRF
> Fix For: Upcoming Branch
>
> Attachments: 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_Plugins.patch, OFBIZ-11306_Plugins.patch,
> OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch,
> OFBIZ-11306_Plugins.patch
>
>
> CRSF tokens are generated using SecureRandom class.
> 1) In widget form where a hidden token field is auto-generated.
> 2) In FTL form where a <@csrfTokenField> macro is used to generate the csrf
> token field.
> 3) In Ajax call where a <@csrfTokenAjax> macro is used to assign csrf token
> to X-CSRF-Token in request header.
> CSRF tokens are stored in the user sessions, and verified during POST request.
> A new attribute i.e. csrf-token is added to the security tag to exempt CSRF
> token check.
> Certain request path, like LookupPartyName, can be exempt from CSRF token
> check during Ajax POST call.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Issue Comment Deleted] (OFBIZ-11306) POC for CSRF Token
[ https://issues.apache.org/jira/browse/OFBIZ-11306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-11306: Comment: was deleted (was: I wrote above: bq. It's OK with me. I just want to check all possibilities offered by CSRFGuard3... I was wrong, actually the article I referred there dates from before CSRFGuard3. I think we should closely follow CSRFGuard3 recommendations rather.) > POC for CSRF Token > -- > > Key: OFBIZ-11306 > URL: https://issues.apache.org/jira/browse/OFBIZ-11306 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Affects Versions: Upcoming Branch >Reporter: James Yong >Assignee: Jacques Le Roux >Priority: Minor > Labels: CSRF > Fix For: Upcoming Branch > > Attachments: 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_Plugins.patch, OFBIZ-11306_Plugins.patch > > > CRSF tokens are generated using CSRF Guard library and used in: > 1) In widget form where a hidden token field is auto-generated. > 2) In FTL form where a <@csrfTokenField> macro is used to generate the csrf > token field. > 3) In Ajax call where a <@csrfTokenAjax> macro is used to assign csrf token > to X-CSRF-Token in request header. > CSRF tokens are stored in the user sessions, and verified during POST request. > A new attribute i.e. csrf-token is added to the security tag to exempt CSRF > token check. > Certain request path, like LookupPartyName, can be exempt from CSRF token > check during Ajax POST call. -- This message was sent by Atlassian Jira (v8.3.4#803005)
