CSRF attack and prevention

[grv]

Hi All

     It looks like there is no mechanism to prevent CSRF attack in ofbiz. If I am logged in to ofbiz instance on my local and create a sample standalone HTML page and try to submit to either a GET or a POST ofbiz URL, I am successfully through and various cookies (applicable to the domain) are also sent by the browser to Ofbiz instance. That essentially is CSRF. This can be reproduced with a script tag with a valid ofbiz URL as src and you can actually see in the developer console the request made through and response is received.

Of course this attack has a context - that the user is logged in and happens on the victim's browser.

I replaced ofbiz URL with gmail and made sure I am logged in to my gmail account. I saw a vague/obsure response from gmail in the console meaning it prevented itself.

 I feel we can handle it in multiple ways and one of the ways is adding SameSite cookie which is a fairly new concept and per latest information Chrome already supports it and FireFox has also added support for the same. Browsers supporting this Cookie will not send JSESSIONID or any other SameSite cookie to the request if the request is cross-site. Each cookie needs to be flagged with SameSite with possible values being strict or lax.
Here's its IETF draft - https://tools.ietf.org/html/draft-west-first-party-cookies-07

 I also think we should not rely on this as the sole prevention mechanism and should also do something on the server side in the sense that we should not rely on the browser support. Tomcat does support a filter - org.apache.catalina.filters.CsrfPreventionFilter that appends a nonce for every request and stores the same in session.

We should also add support for checking Origin and Referrer headers. I think there is a lot we can do.

I have not seen any reference in the current trunk code for both SameSite cookie and CsrfPreventionFilter filter. If we can make everyone on the same page on CSRF, I would like to propose we go ahead with this change. I think we will need to handle it in multiple ways.

I can create a JIRA with all details provided we have the necessary concord.


Thanks and Best regards,
Girish Vasmatkar
HotWax Systems

[Nicolas Malin-2]

Hi Girish,

Thanks for your warm. If you want to detail your please prefer send an
email to [hidden email] instead of open an issue to JIRA.

Nicolas


On 02/09/2018 17:36, [hidden email] wrote:

> Hi All
>
>       It looks like there is no mechanism to prevent CSRF attack in ofbiz. If I am logged in to ofbiz instance on my local and create a sample standalone HTML page and try to submit to either a GET or a POST ofbiz URL, I am successfully through and various cookies (applicable to the domain) are also sent by the browser to Ofbiz instance. That essentially is CSRF. This can be reproduced with a script tag with a valid ofbiz URL as src and you can actually see in the developer console the request made through and response is received.
>
> Of course this attack has a context - that the user is logged in and happens on the victim's browser.
>
> I replaced ofbiz URL with gmail and made sure I am logged in to my gmail account. I saw a vague/obsure response from gmail in the console meaning it prevented itself.
>
>   I feel we can handle it in multiple ways and one of the ways is adding SameSite cookie which is a fairly new concept and per latest information Chrome already supports it and FireFox has also added support for the same. Browsers supporting this Cookie will not send JSESSIONID or any other SameSite cookie to the request if the request is cross-site. Each cookie needs to be flagged with SameSite with possible values being strict or lax.
> Here's its IETF draft - https://tools.ietf.org/html/draft-west-first-party-cookies-07
>
>   I also think we should not rely on this as the sole prevention mechanism and should also do something on the server side in the sense that we should not rely on the browser support. Tomcat does support a filter - org.apache.catalina.filters.CsrfPreventionFilter that appends a nonce for every request and stores the same in session.
>
> We should also add support for checking Origin and Referrer headers. I think there is a lot we can do.
>
> I have not seen any reference in the current trunk code for both SameSite cookie and CsrfPreventionFilter filter. If we can make everyone on the same page on CSRF, I would like to propose we go ahead with this change. I think we will need to handle it in multiple ways.
>
> I can create a JIRA with all details provided we have the necessary concord.
>
>
> Thanks and Best regards,
> Girish Vasmatkar
> HotWax Systems
>

[Jacques Le Roux]

Hi Girish,

Nicolas is right, I just want to say that I already tried to use the CsrfPreventionFilter Tomcat Filter (wrongly noted RestCsrfPreventionFilter in the
link below) without success, please refer to

https://markmail.org/message/r245yie623cdo3wz

Your help is welcome :)

Jacques


Le 02/09/2018 à 21:15, Nicolas Malin a écrit :

> Hi Girish,
>
> Thanks for your warm. If you want to detail your please prefer send an email to [hidden email] instead of open an issue to JIRA.
>
> Nicolas
>
>
> On 02/09/2018 17:36, [hidden email] wrote:
>> Hi All
>>
>>       It looks like there is no mechanism to prevent CSRF attack in ofbiz. If I am logged in to ofbiz instance on my local and create a sample
>> standalone HTML page and try to submit to either a GET or a POST ofbiz URL, I am successfully through and various cookies (applicable to the
>> domain) are also sent by the browser to Ofbiz instance. That essentially is CSRF. This can be reproduced with a script tag with a valid ofbiz URL
>> as src and you can actually see in the developer console the request made through and response is received.
>>
>> Of course this attack has a context - that the user is logged in and happens on the victim's browser.
>>
>> I replaced ofbiz URL with gmail and made sure I am logged in to my gmail account. I saw a vague/obsure response from gmail in the console meaning
>> it prevented itself.
>>
>>   I feel we can handle it in multiple ways and one of the ways is adding SameSite cookie which is a fairly new concept and per latest information
>> Chrome already supports it and FireFox has also added support for the same. Browsers supporting this Cookie will not send JSESSIONID or any other
>> SameSite cookie to the request if the request is cross-site. Each cookie needs to be flagged with SameSite with possible values being strict or lax.
>> Here's its IETF draft - https://tools.ietf.org/html/draft-west-first-party-cookies-07
>>
>>   I also think we should not rely on this as the sole prevention mechanism and should also do something on the server side in the sense that we
>> should not rely on the browser support. Tomcat does support a filter - org.apache.catalina.filters.CsrfPreventionFilter that appends a nonce for
>> every request and stores the same in session.
>>
>> We should also add support for checking Origin and Referrer headers. I think there is a lot we can do.
>>
>> I have not seen any reference in the current trunk code for both SameSite cookie and CsrfPreventionFilter filter. If we can make everyone on the
>> same page on CSRF, I would like to propose we go ahead with this change. I think we will need to handle it in multiple ways.
>>
>> I can create a JIRA with all details provided we have the necessary concord.
>>
>>
>> Thanks and Best regards,
>> Girish Vasmatkar
>> HotWax Systems
>>
>
>

[grv]

Thanks Jacques and Nicolas. I will take this further in the security group
and will soon have updates there. My bad I didn't realise we need to take
it up over there.

Thanks and Best Regards,
Girish Vasmatkar
HotWax Systems

On Mon, Sep 3, 2018 at 1:21 PM Jacques Le Roux <[hidden email]>
wrote:

> Hi Girish,
>
> Nicolas is right, I just want to say that I already tried to use the
> CsrfPreventionFilter Tomcat Filter (wrongly noted RestCsrfPreventionFilter
> in the
> link below) without success, please refer to
>
> https://markmail.org/message/r245yie623cdo3wz
>
> Your help is welcome :)
>
> Jacques
>
>
> Le 02/09/2018 à 21:15, Nicolas Malin a écrit :
> > Hi Girish,
> >
> > Thanks for your warm. If you want to detail your please prefer send an
> email to [hidden email] instead of open an issue to JIRA.
> >
> > Nicolas
> >
> >
> > On 02/09/2018 17:36, [hidden email] wrote:
> >> Hi All
> >>
> >>       It looks like there is no mechanism to prevent CSRF attack in
> ofbiz. If I am logged in to ofbiz instance on my local and create a sample
> >> standalone HTML page and try to submit to either a GET or a POST ofbiz
> URL, I am successfully through and various cookies (applicable to the
> >> domain) are also sent by the browser to Ofbiz instance. That
> essentially is CSRF. This can be reproduced with a script tag with a valid
> ofbiz URL
> >> as src and you can actually see in the developer console the request
> made through and response is received.
> >>
> >> Of course this attack has a context - that the user is logged in and
> happens on the victim's browser.
> >>
> >> I replaced ofbiz URL with gmail and made sure I am logged in to my
> gmail account. I saw a vague/obsure response from gmail in the console
> meaning
> >> it prevented itself.
> >>
> >>   I feel we can handle it in multiple ways and one of the ways is
> adding SameSite cookie which is a fairly new concept and per latest
> information
> >> Chrome already supports it and FireFox has also added support for the
> same. Browsers supporting this Cookie will not send JSESSIONID or any other
> >> SameSite cookie to the request if the request is cross-site. Each
> cookie needs to be flagged with SameSite with possible values being strict
> or lax.
> >> Here's its IETF draft -
> https://tools.ietf.org/html/draft-west-first-party-cookies-07
> >>
> >>   I also think we should not rely on this as the sole prevention
> mechanism and should also do something on the server side in the sense that
> we
> >> should not rely on the browser support. Tomcat does support a filter -
> org.apache.catalina.filters.CsrfPreventionFilter that appends a nonce for
> >> every request and stores the same in session.
> >>
> >> We should also add support for checking Origin and Referrer headers. I
> think there is a lot we can do.
> >>
> >> I have not seen any reference in the current trunk code for both
> SameSite cookie and CsrfPreventionFilter filter. If we can make everyone on
> the
> >> same page on CSRF, I would like to propose we go ahead with this
> change. I think we will need to handle it in multiple ways.
> >>
> >> I can create a JIRA with all details provided we have the necessary
> concord.
> >>
> >>
> >> Thanks and Best regards,
> >> Girish Vasmatkar
> >> HotWax Systems
> >>
> >
> >
>
>

[Jacques Le Roux]

Hi Girish,

Sorry, I completely forgot I worked later on that. Please see OFBIZ-10427 where I again tried the Tomcat CSRF filter w/o success.

It was suggested in the OFBiz security ML by Gregory Draperi (OFBiz committer specialised in security) that we could handle that ourselves.

    "generate an unpredictable value that is sent at the beginning of the session of the user and then should be checked on any sensitive actions."

We could create a nonce at the beginning of the session and then send it with any request.

We could also use a token in header, a JWT as in OFBIZ-9833, for each request as suggested at

    https://security.stackexchange.com/questions/170388/do-i-need-csrf-token-if-im-using-bearer-jwt

HTH

Jacques


Le 03/09/2018 à 09:59, Girish Vasmatkar a écrit :

> Thanks Jacques and Nicolas. I will take this further in the security group
> and will soon have updates there. My bad I didn't realise we need to take
> it up over there.
>
> Thanks and Best Regards,
> Girish Vasmatkar
> HotWax Systems
>
> On Mon, Sep 3, 2018 at 1:21 PM Jacques Le Roux <[hidden email]>
> wrote:
>
>> Hi Girish,
>>
>> Nicolas is right, I just want to say that I already tried to use the
>> CsrfPreventionFilter Tomcat Filter (wrongly noted RestCsrfPreventionFilter
>> in the
>> link below) without success, please refer to
>>
>> https://markmail.org/message/r245yie623cdo3wz
>>
>> Your help is welcome :)
>>
>> Jacques
>>
>>
>> Le 02/09/2018 à 21:15, Nicolas Malin a écrit :
>>> Hi Girish,
>>>
>>> Thanks for your warm. If you want to detail your please prefer send an
>> email to [hidden email] instead of open an issue to JIRA.
>>> Nicolas
>>>
>>>
>>> On 02/09/2018 17:36, [hidden email] wrote:
>>>> Hi All
>>>>
>>>>        It looks like there is no mechanism to prevent CSRF attack in
>> ofbiz. If I am logged in to ofbiz instance on my local and create a sample
>>>> standalone HTML page and try to submit to either a GET or a POST ofbiz
>> URL, I am successfully through and various cookies (applicable to the
>>>> domain) are also sent by the browser to Ofbiz instance. That
>> essentially is CSRF. This can be reproduced with a script tag with a valid
>> ofbiz URL
>>>> as src and you can actually see in the developer console the request
>> made through and response is received.
>>>> Of course this attack has a context - that the user is logged in and
>> happens on the victim's browser.
>>>> I replaced ofbiz URL with gmail and made sure I am logged in to my
>> gmail account. I saw a vague/obsure response from gmail in the console
>> meaning
>>>> it prevented itself.
>>>>
>>>>    I feel we can handle it in multiple ways and one of the ways is
>> adding SameSite cookie which is a fairly new concept and per latest
>> information
>>>> Chrome already supports it and FireFox has also added support for the
>> same. Browsers supporting this Cookie will not send JSESSIONID or any other
>>>> SameSite cookie to the request if the request is cross-site. Each
>> cookie needs to be flagged with SameSite with possible values being strict
>> or lax.
>>>> Here's its IETF draft -
>> https://tools.ietf.org/html/draft-west-first-party-cookies-07
>>>>    I also think we should not rely on this as the sole prevention
>> mechanism and should also do something on the server side in the sense that
>> we
>>>> should not rely on the browser support. Tomcat does support a filter -
>> org.apache.catalina.filters.CsrfPreventionFilter that appends a nonce for
>>>> every request and stores the same in session.
>>>>
>>>> We should also add support for checking Origin and Referrer headers. I
>> think there is a lot we can do.
>>>> I have not seen any reference in the current trunk code for both
>> SameSite cookie and CsrfPreventionFilter filter. If we can make everyone on
>> the
>>>> same page on CSRF, I would like to propose we go ahead with this
>> change. I think we will need to handle it in multiple ways.
>>>> I can create a JIRA with all details provided we have the necessary
>> concord.
>>>>
>>>> Thanks and Best regards,
>>>> Girish Vasmatkar
>>>> HotWax Systems
>>>>
>>>
>>

[grv]

Hi Jacques,

Thanks for your reply. I will certainly take a look at the JIRA and will
also try to see we can successfully implement CSRF filter. I will provide
my inputs on the JIRA as well.

Best,
Girish Vasmatkar
HotWax Systems


On Thu, Sep 6, 2018 at 7:19 PM Jacques Le Roux <[hidden email]>
wrote:

> Hi Girish,
>
> Sorry, I completely forgot I worked later on that. Please see OFBIZ-10427
> where I again tried the Tomcat CSRF filter w/o success.
>
> It was suggested in the OFBiz security ML by Gregory Draperi (OFBiz
> committer specialised in security) that we could handle that ourselves.
>
>     "generate an unpredictable value that is sent at the beginning of the
> session of the user and then should be checked on any sensitive actions."
>
> We could create a nonce at the beginning of the session and then send it
> with any request.
>
> We could also use a token in header, a JWT as in OFBIZ-9833, for each
> request as suggested at
>
>
> https://security.stackexchange.com/questions/170388/do-i-need-csrf-token-if-im-using-bearer-jwt
>
> HTH
>
> Jacques
>
>
> Le 03/09/2018 à 09:59, Girish Vasmatkar a écrit :
> > Thanks Jacques and Nicolas. I will take this further in the security
> group
> > and will soon have updates there. My bad I didn't realise we need to take
> > it up over there.
> >
> > Thanks and Best Regards,
> > Girish Vasmatkar
> > HotWax Systems
> >
> > On Mon, Sep 3, 2018 at 1:21 PM Jacques Le Roux <
> [hidden email]>
> > wrote:
> >
> >> Hi Girish,
> >>
> >> Nicolas is right, I just want to say that I already tried to use the
> >> CsrfPreventionFilter Tomcat Filter (wrongly noted
> RestCsrfPreventionFilter
> >> in the
> >> link below) without success, please refer to
> >>
> >> https://markmail.org/message/r245yie623cdo3wz
> >>
> >> Your help is welcome :)
> >>
> >> Jacques
> >>
> >>
> >> Le 02/09/2018 à 21:15, Nicolas Malin a écrit :
> >>> Hi Girish,
> >>>
> >>> Thanks for your warm. If you want to detail your please prefer send an
> >> email to [hidden email] instead of open an issue to JIRA.
> >>> Nicolas
> >>>
> >>>
> >>> On 02/09/2018 17:36, [hidden email] wrote:
> >>>> Hi All
> >>>>
> >>>>        It looks like there is no mechanism to prevent CSRF attack in
> >> ofbiz. If I am logged in to ofbiz instance on my local and create a
> sample
> >>>> standalone HTML page and try to submit to either a GET or a POST ofbiz
> >> URL, I am successfully through and various cookies (applicable to the
> >>>> domain) are also sent by the browser to Ofbiz instance. That
> >> essentially is CSRF. This can be reproduced with a script tag with a
> valid
> >> ofbiz URL
> >>>> as src and you can actually see in the developer console the request
> >> made through and response is received.
> >>>> Of course this attack has a context - that the user is logged in and
> >> happens on the victim's browser.
> >>>> I replaced ofbiz URL with gmail and made sure I am logged in to my
> >> gmail account. I saw a vague/obsure response from gmail in the console
> >> meaning
> >>>> it prevented itself.
> >>>>
> >>>>    I feel we can handle it in multiple ways and one of the ways is
> >> adding SameSite cookie which is a fairly new concept and per latest
> >> information
> >>>> Chrome already supports it and FireFox has also added support for the
> >> same. Browsers supporting this Cookie will not send JSESSIONID or any
> other
> >>>> SameSite cookie to the request if the request is cross-site. Each
> >> cookie needs to be flagged with SameSite with possible values being
> strict
> >> or lax.
> >>>> Here's its IETF draft -
> >> https://tools.ietf.org/html/draft-west-first-party-cookies-07
> >>>>    I also think we should not rely on this as the sole prevention
> >> mechanism and should also do something on the server side in the sense
> that
> >> we
> >>>> should not rely on the browser support. Tomcat does support a filter -
> >> org.apache.catalina.filters.CsrfPreventionFilter that appends a nonce
> for
> >>>> every request and stores the same in session.
> >>>>
> >>>> We should also add support for checking Origin and Referrer headers. I
> >> think there is a lot we can do.
> >>>> I have not seen any reference in the current trunk code for both
> >> SameSite cookie and CsrfPreventionFilter filter. If we can make
> everyone on
> >> the
> >>>> same page on CSRF, I would like to propose we go ahead with this
> >> change. I think we will need to handle it in multiple ways.
> >>>> I can create a JIRA with all details provided we have the necessary
> >> concord.
> >>>>
> >>>> Thanks and Best regards,
> >>>> Girish Vasmatkar
> >>>> HotWax Systems
> >>>>
> >>>
> >>
>
>