[Owasp-csrfguard] CSRF Guard implementation inconsistencies

Igor Trivunic igor.trivunic at ze.com
Wed Jul 18 15:03:48 UTC 2012


I've been trying to implement CSRFGuard3 it into our application for some time now and have run into several problems. Since I was not successful in finding a solution online, I thought I would contact you with a couple of questions. Perhaps you can shed some light on a couple of problem areas that seem quite difficult to debug due to their inconsistencies.  I am not asking for help in debugging my application, just want to see whether you've observed similar behavior anywhere and if you're aware of what the correct approach to resolution was.

The problem that I have is that behavior is very different between FireFox and IE, as well as between localhost and server it is deployed on. For example, http://localhost:8080/zema works fine on both browsers. However, IE will not let you log in if you use the machine name instead, so http://wrk-it-72:8080/zema
will not let you log in. So, for IE you cannot log in to the deployed version on the server either, only localhost.

Debugging into any of the Action classes shows valid CSRF tokens being passed around just fine as does inspecting the forms on the page source.

The inconsistency part stems from the fact that certain links will work fine on FireFox, but after the next scheduled build they will start to produce CSRF attack errors and redirect me to the error page. Since this does not happen on my local machine it proves quite difficult to debug. I have accessed my local machine from others' computers and was not able to replicate the problems; Everything worked fine. I've attached a screenshot from Fiddler of this happening. As you can see the CSRF security token has suddenly changed, and the link no longer works. This is sometimes a problem, and sometimes works just fine. I should mention that the session ID has not changed, just the CSRF security token has.  In this particular case javascript generates the link and I inject the token manually as follows:

function startCurveDebugger(curveId, ownerId, effectiveDate) {
  var url = '<html:rewrite page='/curve/curveDebugger.jsp'/>';
  if (curveId != null && ownerId != null && effectiveDate != null) {
    url += "?curveId=" + curveId + "&ownerId=" + ownerId + "&effectiveDate=" + effectiveDate;
  var OWASP_CSRFTOKEN = document.getElementsByName("OWASP_CSRFTOKEN")[0].value;
  if(url.indexOf("?") == -1) {
    url += "?";
  else {
    url += "&";

  window.top.inputWin = window.top;
  window.open(url, '_new');

Furthermore, logging in on IE to application running on localhost is inconsistent in that it always reports javascript errors and they are always different. Almost like some part of CSRF is preventing javascript from running fully. This causes parts of the application to not load properly, or causes broken links etc. This is probably the biggest issue I am facing as it renders the application completely useless in Internet Explorer.

Our application uses struts and navigation is mostly done between JSP and struts Action classes with JavaScript generating some of the links as well (as shown above). I'm assuming a CSRF implementation on a similar setup has been performed with success before?

To implement this I have configured things as follows:

*         The filter mapping for CSRFGuard has been set to <url-pattern>*.jsp</url-pattern> and <url-pattern>*.do</url-pattern>

*         Inject into forms/attributes are both 'true' and domain-strict is 'false'

*         The referrer-pattern was alternated between using localhost, machine name, and having it removed entirely with varying results, but no conclusive solution.

*         The unprotected pages are: JavaScriptServlet, index.jsp (home page and same page designated as new token landing page), error page, /zema/images*, /zema/styles* (The last two were added as CSS was causing CSRF errors and I had to modify your JavaScript as follows to fix this: )

      /** inject tokens as query string parameters into url **/
      function injectTokenAttribute(element, attr, tokenName, tokenValue, pageTokens) {
            var location = element.getAttribute(attr);

            // skip over any images and CSS urls
            var skip = false;
            if(location != null && (location.indexOf('/styles/') != -1 || location.indexOf('images/') != -1)) {
              skip = true;

            if(location != null && isValidUrl(location)) {
                  var uri = parseUri(location);
                  var value = (pageTokens[uri] != null ? pageTokens[uri] : tokenValue);

                  if(!skip) {
                  if(location.indexOf('?') != -1) {
                        location = location + '&' + tokenName + '=' + value;
                  } else {
                        location = location + '?' + tokenName + '=' + value;

                  try {
                        element.setAttribute(attr, location);
                  } catch (e) {
                        // attempted to set/update unsupported attribute

*         The 'TokenPerPage' and 'TokenPerPagePrecreate' properties are both set to 'false'.

*         The propery 'org.owasp.csrfguard.Protect'is currently commented out, but un-commenting and setting to 'false' did not make a difference.

*         The remaining properties were left unchanged from default.

If you have seen or heard of similar behavior I would be interested in hearing more on what kind of steps were taken to resolve it!

Thanks in advance,

Igor Trivunic
Application Developer
ZE PowerGroup Inc.
#170-5920 No. 2 Road
Richmond, BC, Canada, V7C-4R9
Phone: (604) 244-1475 Ext. 306
Emai: igor.trivunic at ze.com<mailto:igor.trivunic at ze.com> Website: www.ze.com<http://www.ze.com/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-csrfguard/attachments/20120718/efca25c5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: csrf_token_changing.png
Type: image/png
Size: 152050 bytes
Desc: csrf_token_changing.png
URL: <http://lists.owasp.org/pipermail/owasp-csrfguard/attachments/20120718/efca25c5/attachment-0001.png>

More information about the Owasp-csrfguard mailing list