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