When posting with Jforum configured to use csrf, a parameter is added to the POST in the form of "?OWASP_CSRFTOKEN=token" .When the post is redirected to display the posted message, the new URL is in the form of "http://server/jforum/list/topic-id.page#post-id?OWASP_CSRFTOKEN=token". As a result, the anchor does not go to the newly-posted message, but rather the top of the page. If the order of the parameters were changed, to be:
"http://server/jforum/list/topic-id.page?OWASP_CSRFTOKEN=token#post-id"
The message would load correctly. However, I haven't been able to figure out how to make this change. Perhaps someone here can help?
I hadn't encountered this problem, but a quick look at the source code leads me to believe that the OWASP_CSRFTOKEN parameter is added to URLs inside the CsrfGuard library. In particular, the InterceptRedirectResponse.sendRedirect method does not seem to consider that the URL might contain an anchor, instead blindly appending the CSRF token at the end.
https://github.com/esheri3/OWASP-CSRFGuard/blob/master/csrfguard/src/main/java/org/owasp/csrfguard/http/InterceptRedirectResponse.java
The code is called from within JForum's https://sourceforge.net/p/jforum2/code/HEAD/tree/trunk/src/main/java/net/jforum/csrf/CsrfFilter.java class.
That's just from a quick look, I don't have time for a detailed analysis right now. Based on that, the proper fix might be to alert the OWASP folks about this, and hope they incorporate a fix in their code.
Last edit: Ulf Dittmer 2016-09-08
Thank you for your quick response. I came to the same conclusion when I looked in to it. I'll try to open a ticket with OWASP.
If you do open a ticket, please post the URL here, so I can keep tabs on it.
There waas already a ticket open on the same issue for the past two years:
https://github.com/esheri3/OWASP-CSRFGuard/issues/67
I bumped it to see if I could generate some interest in addressing it.
Another one was opened three years ago:
https://github.com/esheri3/OWASP-CSRFGuard/issues/34
I have added a version of the CSRFGuard library which fixes this issue to the file download area; it's called csrfguard-3-latest.jar. You need to replace the csrfguard-3.1.0.jar file in WEB-INF/lib with this one, and the issue should be addressed.
Thank you very much Ulf! I really appreciate your extremely attentive and quick response to this. I will test it today.
I am running the new library and it has fixed the issue. Ulf, again, thank you for addressing this in such a timely manner. Your help is greatly appreciated. This ticket can be closed as far as I'm concerned.