Samuel Trégouët commented on OFBIZ-11306:

Hi James,

thanks for your POC, csrf is an important security topic when authentification 
is based on cookie!

Here are few questions/observations:
 * why did you choose csrfguard ? and how did you choose configuration (token 
length of 32 and algorithm SHA1PRNG)?
 * why do you add a map into session? tokenMap is a mapping to empty string, 
maybe it is better to use a Set in this case ? But actually multiple tokens in 
session at one time seems to me a mistake. I think that if we have multiple 
forms on one page it's enough to reuse the same token. Because if a user asks a 
page with a form but never submits this form, then asks another page with 
another form and again never submits this second form, we will end up with an 
ever growing tokenMap


> 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.patch, OFBIZ-11306.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

Reply via email to