2

My Ubuntu 18 system did an upgrade to Firefox 68 (presumably from 67.x).

I have a simple XSRF demo that I use for class --- the demo is extremely simple: I have a login program that sets a sessionid cookie once there is a successful login. To simplify the demo, the cookie is set with a hardcoded value.

Then, I have an "add user" server app (a plain'old CGI program) that is intended to add the user only of there is a log in --- that is, if the sessionid cookie contains the expected (hardcoded) value. The program simply checks:

if (cookie["sessionid"] == "the-hardcoded-value")
{
    // execute SQL: insert into users values ........
}

Then, I have a third page (on a separate domain) that just has an embedded img tag that looks like this:

<img src="https://mydomain.com/cgi-bin/add_user.cgi?username=AddedViaXSRF" />

(the img shows as a little empty square on the displayed HTML page)

The thing worked like a charm..... until this morning. It just won't work with Firefox 68. I check the server logs (the "add user" program logs the requests that it receives, including the cookies) --- it is not receiving the sessionid cookie even though I see, via the menu Web developer → Storage Inspector, that the cookie has been set in the browser. I also checked: the sameSite attribute is not set (httpOnly is, because the login program sets it).

The demo still works with Firefox 61 (I tried from a virtual machine --- two, actually: a Windows 7 with FF 61, and also an unpatched Ubuntu 18.04.1 that happens to also have FF 61). But I'm fairly certain that it was also working on FF 67.x (I had tried the demo a couple days ago, in preparation for today's class where I showed the demo).

Is it really some change in FF 68 that's preventing this simple "classic" img-based CSRF attack from succeeding? (if so, what is the change? I can't see anything remotely close to related in the list of security fixes for FF 68)

[[EDIT]]: I just tried with FF 65 (a "live booted" Ubuntu 18.04.2 system), and the demo works without a glitch (i.e., the XSRF attack succeeds in adding a user to the table).

  • 1
    See if there are any errors in the browser's developer console on the page that launches the CSRF attack. – multithr3at3d Jul 17 at 22:28
  • No, no errors (there's only a warning that the charset was not declared --- because it is a demo, I didn't bother; the page just goes: <html> <body> <h2>.....) – Cal-linux Jul 18 at 1:51
  • I'm now puzzled --- Following H.Idden's answer, I tried the Custom settings; if I select "Block all third-party cookies", then I do get an error in te developer console (clearly stating that this access was blocked because it involves third-party storage access) + the popup "New in FF: Content Blocking". Not sure why with the previous settings it seemed to block it (because the demo was not working) but didn't produce the error message. – Cal-linux Jul 18 at 2:10
4

Firefox 67 and 68 added multiple possible settings for privacy and Third-Party-Cookie-Blocking. As far as I understand, your demo seems to include usage of Third-Party-Cookies. You can find the information at the information page about content-blocking from Mozilla. The main reason for the change were protecting against being tracked by Third-Party-Advertisers and similar.

Further information:

When you open a page at evil.com, all content loaded from evil.com is considered First-Party-Content. Content loaded from other domains, is called Third-Party-Content. Depending on your privacy settings, Third-Party-Content might be loaded without cookies or not at all (for example if the domain got on a black-list). Since your (fake-)image from demo.com is considered Third-Party-Content, depending on your settings, the request might not contain the cookies of demo.com.

  • No, no third-party cookies. I login to site demo.com; a successful login sets a cookie sessionid associated to the demo.com domain. A page from evil.com simply contains, as part of its HTML code, an img tag with: <img src="https://demo.com/cgi-bin/add_user.cgi?username=AddedViaXSRF.... />. However, maybe some of the rules targeting third-party cookies are overlapping with some aspect of the functionality of my demo? – Cal-linux Jul 18 at 1:44
  • Huh --- I overlooked the detail that the request from evil.com of a page at demo.com that has a cookie, that looks like third-party storage to FF. If I go to Content Blocking settings and select Custom, as long as I either uncheck Cookies or set the level to less restrictive than Block all third-party cookies, the demo works. – Cal-linux Jul 18 at 2:07
  • 1
    @Cal-linux I added some information to make it more understandable what happened to you. – H. Idden Jul 18 at 19:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.