Hi Jacques, all,
Haven't look into the POC yet. Please see the following updates:
1. Not a good practice to allow state-changing request via GET method without a
token to check for CSRF.
2. Not a good practice to expose CSRF token in url. See [1]. Moreover, token in
url may also be exposed via if user posts screenshots.
3. CSRF is not a concern for GET request if we avoid point 1 & 2.
4. In OFBiz, the same request handler generally can process both GET and POST
requests. The checkSecureParameter in service events would check for no query
string and as a result, state-changing operation is restricted to a POST method
when service event was used.
5. Propose to revert the removal of checkSecureParameter, but add new code to
allow exceptions to query-string check in service events. Exception can be made
by setting a new attribute, allow-query-string-for-event = true | false
(default), in security tag within request-map tag. Also extend
checkSecureParameter to other event types.
6. Propose to add new attribute, csrfToken = true | false (default), to
security tag to support anti-csrf for post request:
a) For forms: if true, will generate hidden token field value using CSRF
Guard library ( see [3] ) for every rendered form and store this token inside
session map variable. Support may be added for token name to be randomized.
b) For login form: There is a need to prevent Login CSRF. Token will also
be created using pre-session. See [2] for Login CSRF.
c) For XMLHTTPRequest: Use default value for same-origin policy. 1 token
generated per user session for ajax call. Support may be added for token name
to be randomized for each session.
7. The service.http.parameters.require.encrypted property that was removed,
seems related to encrypting sensitive parameter values but wasn't implemented.
May look into this at a later time.
8. For implementations that aren't using OFBiz screens, a property may be added
to disable the check for CSRF token.
Reference:
[1]
https://danielmiessler.com/blog/sensitive-information-sent-in-the-url-over-https.
[2]
https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html
[3] https://www.owasp.org/index.php?title=CSRF_Guard&redirect=no
Regards,
James
On 2019/11/10 10:22:05, Jacques Le Roux <[email protected]> wrote:
> Hi James,
>
> I see no reasons for you to not open a Jira and provide a patch, other
> opinions may vary...
>
> Jacques
>
> Le 08/11/2019 à 17:46, James Yong a écrit :
> > Hi Jacques,
> >
> > Inline...
> >
> > On 2019/11/06 18:28:26, Jacques Le Roux <[email protected]>
> > wrote:
> >> Hi James,
> >>
> >> Inline...
> >>
> >> Le 06/11/2019 à 17:53, James Yong a écrit :
> >>> Hi Jacques,
> >>>
> >>> Understand the intent of checkSecureParameter function is to avoid
> >>> sensitive information
> >>> in the URL during POST method.
> >> Was ;) It does not exist anymore, in trunk at least, after OFBIZ-11260.
> > [James] Thanks for pointing it out. Still need to discuss the
> > checkSecureParameter method below..
> >
> >>
> >>> A proposal is made to provide an attribute (i.e.
> >>> allow-query-string-for-service-event) to allow url parameters / query
> >>> string for certain request. Shouldn't the value for this attribute be
> >>> false, instead of true, when no value is specified for the attribute?
> >> Depends, if we want to have the same behaviour than in trunk after
> >> OFBIZ-11260 then it should be false by default. Note that we "never" get
> >> back from
> >> changes, except in case of regression.
> > [James] I am ok with either way. The new attribute will be an interim
> > solution if we were to remove the checkSecureParameter function after
> > implementing CSRF protection.
> >
> >>
> >>> The property service.http.parameters.require.encrypted is also not
> >>> required for the proposed change.
> >> Yes, re-introducing will need to revert work done with OFBIZ-11260
> >>
> > [James] From the comments inside the removed checkSecureParameter method,
> > original intent of service.http.parameters.require.encrypted is to allow
> > existing code to work after checkSecureParameter was implemented. Don't see
> > a need to get this property back.
> >
> >>> As a side note, checkSecureParameter function restricts CSRF attack to a
> >>> POST method but doesn't prevent CSRF entirely. Maybe can explore the
> >>> feasibility of supporting CSRF token for OFBiz form in future..
> >> Yes, we already do: https://issues.apache.org/jira/browse/OFBIZ-10427
> > [James] Thanks for the info. CSRF protection needs to be implemented for
> > OFBiz form since checkSecureParameter is already removed.
> >
> >> Jacques
> >>
> >>> Regards,
> >>> James
> >>>
> >>>
> >>>
> >>> On 2019/11/05 07:47:19, Jacques Le Roux <[email protected]>
> >>> wrote:
> >>>> Hi James,
> >>>>
> >>>> We had service.http.parameters.require.encrypted in url.properties. It's
> >>>> was the same but an all or nothing. It's now removed.
> >>>>
> >>>> I'm not against your late proposition. It now means to revert changes
> >>>> from OFBIZ-11260!
> >>>>
> >>>> But then it should be reversed. By default
> >>>> allow-query-string-for-service-event would be true and if someone wants
> >>>> to prevent a query string for a
> >>>> particular event then false can be used.
> >>>>
> >>>> I'm not sure much people will care of that, not sure what others think...
> >>>>
> >>>> Jacques
> >>>>
> >>>> Le 05/11/2019 à 01:28, James Yong a écrit :
> >>>>> Hi Jacques, Samuel, all,
> >>>>>
> >>>>> I think the security concerns raised are valid.
> >>>>>
> >>>>> However we can look into adding an attribute when the url parameter
> >>>>> check isn’t required.
> >>>>> For example,
> >>>>> <request-map … >
>
> >>>>> <security https="true" auth=“true”
> >>>>> allow-query-string-for-service-event=“true”/>
>
> >>>>> …
> >>>>>
> >>>>> Regards,
> >>>>> James
> >>>>>
> >>>>> On 2019/10/31 14:20:11, Jacques Le Roux <[email protected]>
> >>>>> wrote:
> >>>>>> Hi Samuel,
> >>>>>>
> >>>>>> You can go ahead. I became entangled with non ending issues while
> >>>>>> working on this and this change will not change anything about those
> >>>>>> unrelated issues.
> >>>>>>
> >>>>>> Jacques
> >>>>>>
> >>>>>> Le 30/10/2019 à 17:01, Jacques Le Roux a écrit :
> >>>>>>> Le 30/10/2019 à 15:34, Samuel a écrit :
> >>>>>>>> Hi Jacques,
> >>>>>>>>
> >>>>>>>> On 27/10/2019 17:42, Jacques Le Roux wrote:
> >>>>>>>>
> >>>>>>>>> … So I have no problem removing this method... and closing
> >>>>>>>>> OFBIZ-2330, maybe after "fixing" OFBIZ-9804...
> >>>>>>>> I'm not sure to get your point with OFBIZ-9804, if we simply remove
> >>>>>>>> `checkSecureParameter` we fix this issue, don't we ?
> >>>>>>>>
> >>>>>>>> Samuel
> >>>>>>>>
> >>>>>>> Yes, kinda. I prefer to have all calls to
> >>>>>>> updateContactListPartyNoUserLogin similar. Please wait a bit before I
> >>>>>>> close OFBIZ-9804...
> >>>>>>>
> >>>>>>> Jacques
> >>>>>>>
> >>>>>>>
>
