I think I will end up going with the Double Submit Cookie mechanism. See
http://security.stackexchange.com/q/59411/5002 and
http://security.stackexchange.com/questions/59470/double-submit-cookies-vulnerabilities
In summary: If you control all sub-domains, then I believe the Double
Submit Cookie mechanism is safe, scalable and the easiest to implement.
Otherwise,
http://security.stackexchange.com/a/59413/5002 might be the
only way to go.
Gili
On 05/06/2014 12:48 PM, cowwoc wrote:
> Hi Mira and Nasir,
>
> Two points:
>
> 1. Agreed, you only need CSRF protection for "unsafe" methods
> (meaning HTTP GET does not need protection).
> 2. Protecting against normal CSRF attacks is "easy". The hard part is
> making your solution also protect against login attacks:
> http://security.stackexchange.com/q/59411/5002
>
> I am still investigating a solution. I'll let you know once I settle
> on something.
>
> Gili
>
> On 05/06/2014 9:02 AM, Miroslav Fuksa wrote:
>> Hi Nasir, all,
>>
>> yes, this is what I have understood too but may be was not so precise
>> in my description. If we make subsequent requests we will only make
>> one additional request at the first time to get the first token.
>> Jersey CSRF filter now checks presence of headers only for operations
>> that changes the state. I have few points:
>>
>> - should we generate new token for each request? I mean: can token
>> be reused?
>> - if not, then if we always wait for new token this would mean we
>> can’t just send thousand of async requests to the server as we must
>> do it asynchronously and wait always for token. This is even worse
>> than Digest authentication when client is sending nonce values but
>> can create new values by just simply incrementing the “nonce”.
>> - is there any proposal (resource) for this? I have not searched for
>> that yet.
>>
>> Thanks
>> Mira
>>
>>
>> On Jun 5, 2014, at 2:01 PM, Nasir Rasul <nasir.rasul_at_gmail.com
>> <mailto:nasir.rasul_at_gmail.com>> wrote:
>>
>>> Hi Mira,
>>> I understood it a little differently.
>>> >his would mean that we will need to refuse every request without
>>> the header and send back the token
>>> not every request needs to have it. Only places where you could
>>> potentially have a POST/PUT/state change. A simple GET with no
>>> possible further actions does not require XSRF.
>>> If XSRF is required and there is no XSRF token and/or it is invalid,
>>> correct response would be to signal an error.
>>>
>>> client : GET --- > server sends form with XSRF token
>>> client POST --> server verifies form. If errors, a new xsrf token is
>>> sent instead of old (which I gather is the problem based on the
>>> question).
>>> client POST again in case of errors --> server verifies newtoken
>>> instead of old.
>>>
>>> no real extra set of requests.
>>>
>>> Granted that I haven't used jersey yet, just lurking here on the
>>> mailing lists for enlightenment :), I don't really know how Jersey
>>> behaves first hand.
>>>
>>> Cheers
>>> Nasir
>>>
>>> - Nasir
>>>
>>>
>>> On Thu, Jun 5, 2014 at 7:44 AM, Miroslav Fuksa
>>> <miroslav.fuksa_at_oracle.com <mailto:miroslav.fuksa_at_oracle.com>> wrote:
>>>
>>> Hi Gili,
>>>
>>> what enhancements do you suggest? Answers to the question below
>>> suggests to use random generated token with value send
>>> previously by the server in response. This would mean that we
>>> will need to refuse every request without the header and send
>>> back the token. Then in the subsequent request the token could
>>> be used. This would increase the number of requests needed to
>>> get the resource. Or did I misunderstand something?
>>>
>>> Javadoc of CsrfProtectionFilter precisely describes the
>>> implementation and points to resources. We can add some notice
>>> but in this case it would be good to know what is the correct
>>> implementation. Or at least to point to some resources that
>>> describe problem of this solution.
>>>
>>> Thanks
>>> Mira
>>>
>>> On Jun 5, 2014, at 2:33 AM, cowwoc <cowwoc_at_bbs.darktech.org
>>> <mailto:cowwoc_at_bbs.darktech.org>> wrote:
>>>
>>> > According to http://security.stackexchange.com/a/23373/5002
>>> the CSRF filter that ships with Jersey might not be safe, or not
>>> very much longer. Perhaps it's worth adding a warning to the
>>> Javadoc and/or enhancing the implementation?
>>> >
>>> > Gili
>>>
>>>
>>
>