NOT AN ISSUE: Simple questions / help

[EstherMoellman]

Hi @tartpvule !

Firstly, thank you for your CCC' add-on. I found it after reading your conversations with @claustromaniac.

I'm a newbie trying to understand a little about CORS. So please, be patience with my ignorance.
It is not my intention to become a CORS' expert. So honestly, I have no interest on reading a lot about it.
However, I would like to prevent my browser from leaking information to third parties.
And now, I'm trying to compare your add-on with @claustromaniac' add-on.

Please:

1. At CCC, if I want to test other "request type" (beacon, csp_report, image, main_frame etc), is it enough if I copy/paste the CCC' default rule, and I change "font" to the request type I want to test? Or do I need to add something else for different request types?

2. What about the "{" and "}"? If I want to test more than one request type at the same time, how do I write a rule containing more than one request type? Where to put the "{" and "}"?

3. Besides "font" (default), what else do you consider safe to be included as a rule?

4. I tested the "aggressive mode" at @claustromaniac' add-on, and haven't found any apocalypse (in simple words, not a lot of web-page breakages for me). However I read your explanation about how this might be dangerous (exploited). In the other hand, a year already has passed since the launch of your and @claustromaniac' add-ons, sadly both add-ons didn't become famous... and I ask you: Today, have you changed your opinion about the "aggressive mode"? Are you still against the aggressive mode? Or today, in real world, "aggressive mode" is useful?

Thank you in advance!

[tartpvule]

@EstherMoellman Sorry for the late reply
Thank you for trying out my WebExtension

1. At CCC, if I want to test other "request type" (beacon, csp_report, image, main_frame etc), is it enough if I copy/paste the CCC' default rule, and I change "font" to the request type I want to test? Or do I need to add something else for different request types?
2. What about the "{" and "}"? If I want to test more than one request type at the same time, how do I write a rule containing more than one request type? Where to put the "{" and "}"?

The config is a JSON object

{
  "font": { // Type
    "*": { // Origin
      "*": { // Target
        "*": { // Path
          "ACAO": "star",
          "ACAC": false,
          "ACAM": ["GET"]
      	}
      }
    }
  }
}

For example, to add a rule matching xmlhttprequest requests from origin www.somewhere.com to www.elsewhere.com with path /super-secret-page, and another rule matching font requests for the same origin and path, it would go like this:

{
  "font": {
    "*": {
      "*": {
        "*": {
          "ACAO": "star",
          "ACAC": false,
          "ACAM": ["GET"]
      	}
      }
    },
    "www.somewhere.com": {
      "www.elsewhere.com": {
        "/super-secret-page": {
          ... RULE A GOES HERE ...
        }
      }
    }
  },
  "xmlhttprequest": {
    "www.somewhere.com": {
      "www.elsewhere.com": {
        "/super-secret-page": {
          ... RULE B GOES HERE ...
        }
      }
    }
  }
}

Hope that explains it

3. Besides "font" (default), what else do you consider safe to be included as a rule?

At least, not "xmlhttprequest", but I have not tested all risky request types (e.g. "websocket") or the seemingly benign ones (e.g. "image" in conjunction with canvas shenanigans).
So as a general suggestion, nothing other than "fonts". I strongly suggest testing any rule you write in a closed LAN environment first.
More explanations below.

4. I tested the "aggressive mode" at @claustromaniac' add-on, and haven't found any apocalypse (in simple words, not a lot of web-page breakages for me). However I read your explanation about how this might be dangerous (exploited). In the other hand, a year already has passed since the launch of your and @claustromaniac' add-ons, sadly both add-ons didn't become famous... and I ask you: Today, have you changed your opinion about the "aggressive mode"? Are you still against the aggressive mode?

As I understand it, claustromaniac's addon was created to remove the Origin header, to prevent leakage of origin referrer information. This means that the target server cannot decide what accesses to allow/deny as per the CORS specification, so the addon add "Access-Control-Allow-Origin: *" to response headers to prevent breakage. For this purpose, it is doing a reasonably good job.

(Details might be sketchy, I have not looked at claustromaniac's addon in a while)
In "aggressive mode", the addon would go through all CORS requests without credentials and do the aforementioned procedure on them, to prevent Origin leakage. Safeguards were in place to prevent exposing sensitive data, like cookies, POSTs, etc.

That bug I reported was that the safeguards were not sufficient, as plain xmlhttprequest GET requests without credentials are still dangerous. As illustrated in my POC, an attacker can use a visiting user's browser as a proxy to access the user's internal network. This can be used to roughly survey services in the network's topology (Transmission bittorrent client's web interface comes to mind), find out the make and model of the home router (e.g. GET 192.168.1.1 and compare the login page with a database), and more.

From a cursury reading of the extension's source code today and the fact that the issue is still open, I would say that "aggressive mode" is still hazardous.

You will not find page breakages from using "aggressive mode", but a page specifically coded to take advantage of the security hole will be able to use your browser as a limited proxy. As the extension is not popular I would not expect to find such specially crafted malicious websites outside of targeted attacks today.

Or today, in real world, "aggressive mode" is useful?

Useful in the same way spoofing Referer header is useful: privacy.

The crux of it is that, unlike privacy extensions like adblockers that only deny websites something, meddling with CORS headers can result in giving websites (potential attackers) more information than they would otherwise be able to access.

Be very careful writing a rule for my extension (CCC), the warning Misconfiguring the rules WILL break the protections offered by the Same-Origin Policy is no joke.

P.S. Spotted several documentation errors while writing this, fixed them.