Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Can't get CSRF protection to work on CXF #202
I'm trying to get CSRF protection to work on my controller. It looks like this:
If I read the spec correctly, the default for
I have a page that submits an HTML form to this controller method using POST, and it lacks the CSRF token parameter. I would expect the form submission to be rejected, but my controller method is hit.
Browsing through Ozark source code, I expect it is the responsibility of the
Again, reproduction repo is https://github.com/mthmulders/openliberty-mvc. Any clues?
added a commit
Sep 6, 2018
Yes, you are correct. The method should actually be processed by
Could you please check if the interceptor registration works by confirming that this code gets executed:
There is also some special handling for CXF here:
But my guess is that this CXF workaround isn't the cause of your issues.
My only other guess is that the name binding isn't working as expected for some reason. I ran into issues regarding the name binding before, so this is just a wild guess, but it may be possible.
I can confirm that DefaultConfigProvider.java#L45 is being hit. Also, inside
Thanks for confirming. Looks like we need to do some more debugging to solve this. Unfortunately there are a few weird issues with CXF like #168 for example.
I'll try to setup some test environment with plain Tomcat + CXF + Ozark to see if I can find the root cause for this.
Of course any kind of help is welcome!
changed the title from
Can't get CSRF protection to work
Can't get CSRF protection to work on CXF
Sep 8, 2018
Ok, great! Any kind of help is welcome.
My current guess is that the name binding
Just to make sure... does it work in other JAX-RS implementations? I've found RESTful Java with JAX-RS 2.0 (Second Edition), that says:
If that was true, I'd expect that other JAX-RS implementations also suffer from this. In this particular case, the controller method isn't reading Java objects directly from the HTTP message body.
Well, of course I hoped that it would work in other JAX-RS implementations :-). The document I referred to isn't a specification, so I don't know it's status. I interpreted it as "when a message body is read to a POJO" - like when a JSON structure is sent and the controller method has a method argument of a corresponding Java structure.
I'll try a bit more debugging when/how these interceptors are invoked in CXF in the coming days.
Thanks for the clarification. Well, actually it may be possible that different JAX-RS implementations handle
The exact wording in the JAX-RS spec is:
It would be interesting to know how CXF handles this requirement.
Also, it may be worth a try to add a parameter of type
Bingo! Adding an
By the way, paragraph 18.104.22.168 of the JAX-RS 2.1 spec suggests that a
I did a quick search in the CXF issue tracker, but can't find anything related to this issue.
What would be the way to go here? File an issue with CXF and see if they agree upon our interpretation of the spec at this point?