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
>>
>>
>