1

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).

Improve this question
3
  • 1
    See if there are any errors in the browser's developer console on the page that launches the CSRF attack.
    – multithr3at3d
    Commented Jul 17, 2019 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
    Commented Jul 18, 2019 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
    Commented Jul 18, 2019 at 2:10

1 Answer 1

Reset to default
3

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.

Improve this answer
3
  • 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
    Commented Jul 18, 2019 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
    Commented Jul 18, 2019 at 2:07
  • 1
    @Cal-linux I added some information to make it more understandable what happened to you.
    – H. Idden
    Commented Jul 18, 2019 at 19:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .