Thanks. Looks very useful.
bookmarked the questions.
- Nasir
On Thu, Jun 5, 2014 at 4:32 PM, cowwoc <cowwoc_at_bbs.darktech.org> wrote:
> 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> 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>
> 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> 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
>>
>>
>
>
>
>