[rt-users] Cross site request forgery

Chris O'Kelly Chris.okelly at minecorp.com.au
Mon Sep 17 22:02:36 EDT 2012


Hi Paul,

Firstly, I'll just point out this isn't my fix, it's stolen from the top answer of http://stackoverflow.com/questions/4762254/javascript-window-location-does-not-set-referer-in-the-request-header, but it is elegant and works, so there you go. Define the function navigateToUrl(url), either in an external file that you include in each page (I forget what the name of the configuration option is, but you'll find it if you grep etc/RT_Config.pm for javascript) or inline in all the pages you might use it (I would suggest the former of these).
function navigateToUrl(url) {
    var f = document.createElement("FORM");
    f.action = url;

    var indexQM = url.indexOf("?");
    if (indexQM>=0) {
        // the URL has parameters => convert them to hidden form inputs
        var params = url.substring(indexQM+1).split("&");
        for (var i=0; i<params.length; i++) {
            var keyValuePair = params[i].split("=");
            var input = document.createElement("INPUT");
            input.type="hidden";
            input.name  = keyValuePair[0];
            input.value = keyValuePair[1];
            f.appendChild(input);
        }
    }

    document.body.appendChild(f);
    f.submit();
}

navigateToUrl("http://foo.com/bar");

Note that as far as I can see this will not work if there is more than one parameter you need to pass, you may need to do a little more funky splitting of the params variable. and loop through creating inputs.

As for why, I am tempted to say "Because Microsoft, that's why!", but I dunno. I suppose an argument could be made that when the window.location property is changed it is less a referral than a redirect, and as such there should be no referrer. Considering all the other browsers handle this fine and IE9 also does, it might not be a very convincing argument.

As I write this I have been trying (in vain) to Google up any word from MS on the problem. Lots of forums suggest this behaviour is "by design", but I am not sure where MS refers to this design. About all I can find so far is that you might fix this problem by "Optimizing Internet Explorer" (http://answers.microsoft.com/en-us/ie/forum/ie8-windows_7/ie-8-fails-to-pass-the-http-referer-on-many/6f217b05-e9b8-409a-9447-78f0741d0f55) :p.




Chris O'Kelly
Web Administrator

Minecorp Australia
37 Murdoch Circuit
Acacia Ridge QLD 4110
minecorp.com.au<http://www.minecorp.com.au>


P:   07 3723 1000
M:  0450 586 190
E:  Chris.okelly at minecorp.com.au<mailto:Chris.okelly at minecorp.com.au>
S:  chris.okelly.mvs<http://skype.com>


 [http://oi46.tinypic.com/mw8nbd.jpg]

From: rt-users-bounces at lists.bestpractical.com [mailto:rt-users-bounces at lists.bestpractical.com] On Behalf Of Paul Tomblin
Sent: Tuesday, 18 September 2012 11:37 AM
To: rt-users at lists.bestpractical.com
Subject: [rt-users] Cross site request forgery

I have three custom pages, call them "d.html", "a.html" and "c.html".  "d.html" is the dashboard for the plugin, and from that one to either of the others and back to "d.html".  I transition between them using 'window.location = "d.html";' which works fine for all of the transitions, except one.  When I'm on d.html and I want to go to a.html with an argument, I do 'window.location = "a.html?upid=123";'.  That one works just fine on Chrome and Firefox (on Linux and Mac) and IE9 (On Windows 7), but on IE8 I get the dreaded "Cross site request forgery".  Clicking the "click here to resume your request" of course gets me to the page as requested.

In the log, the message is
Possible CSRF: your browser did not supply a Referrer header (/opt/rt4/sbin/../lib/RT/Interface/Web.pm:1369

Looking at the source code, it appears that the problem is that IsCompCSRFWhitelisted is complaining about the fact that there is an argument.  But why isn't IE8 sending a referrer header when the other browsers do?

This is RT 4.0.6, running in standalone development mode.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20120918/1980ada8/attachment.htm>


More information about the rt-users mailing list