feature request: support for CORS

[onesail]

Currently JavaScript clients can not directly connect to CUPS.
If CUPS produced a valid CORS header JavaScript clients could print to or query CUPS.
So far it's common practice to have some kind of forwarding component involved.

in cupsd.conf add:
EnableCORS *
should make CUPS produce HTTP responses with header
Access-Control-Allow-Origin: *

NB:
I added this line in the Location section of cupd.conf
Header set Access-Control-Allow-Origin "*"
but it looks like mod_header ist not supported by CUPS:
E [04/Jul/2016:19:36:52 +0200] Unknown Location directive Header on line 15.

IPP for node.js / javascript currently does not work in browsers
see also: williamkapke/ipp#3

[michaelrsweet]

There are some serious security issues with enabling Javascript access to local print servers, which is why access is locked down as tightly as it is (to address known attack vectors) and why we no longer listen on localhost by default.

I'll keep this issue open for now, but I am not comfortable with enabling direct access to CUPS from arbitrary web pages.

[onesail]

CORS support should not be enabled by default, only by configuration

I agree with your attack vector considerations.

• For access from/via localhost CORS is not required as long as javascript files are hosted by CUPS itself e.g. in /usr/share/doc/cups (configured as DocumentRoot in cups-files.conf)
  In this case CORS should not by necessary.
• For http/ipp access from remote via browser/javascript CORS support is required.
  Security might be less an issue considering that browsers are usually unable to browse bonjour services on the network. This means the attacker would need to know the exact printer URI for the CUPS server on the same network.

• CORS Flowchart: http://www.html5rocks.com/static/images/cors_server_flowchart.png

[jsmeix]

I like to share my opinion from a Linux distributor's point of view
where the main customers are business users:

I am not comfortable with enabling any access
to the cupsd from any kind of arbitrary clients.

I am not comfortable with not thoroughly verified
statements about whether or not security is an issue.

The borderline between secure and insecure is often
almost invisible. Something may look secure on first,
second, and third glance but actually it is insecure.

I do not know what is meant in #4850 (comment)
with "exact printer URI for the CUPS server"
but in general CUPS device URIs are not a secret.

E.g. CUPS device URIs on a CUPS server that point to
the actual printer devices are usually available to all users
who are allowed to submit a print job to that CUPS server:

lpstat -h cups-server.domain -v

And CUPS device URIs that point to print queues on a
CUPS server can be derived when the queue name is known

ipp://cups-server.domain/printers/queue_name

and in general CUPS queue names are not a secret.

[onesail]

Jsmeix, your concern is covered by the use case "share printer: yes/no".
Without printer sharing no client what so ever can access CUPS.

Even with printer sharing enabled no browser supports executing commands like lpstat from JavaScript. JavaScript engines run in a sandbox and have no access to system commands like that.

HTTP headers are produced by all CUPS installations. CUPS is the reference implementation for IPP which is based on HTTP. Any IPP client can connect to CUPS from anywhere as long as it is configured for remote access.

Because JavaScript engines of browsers run in a sandbox we need this feature. If JavaScript code wants to connect to another server the engine first asks the other server if that's okay. This is what CORS is about. We're talking just about one single extra optional header value that would make cumbersome workarounds like using nginx obsolete.

[michaelrsweet]

Onesail, the issue (and the reason why CUPS has so many remote access protections) is that while the Javascript execution environment is often a pretty tight sandbox, there are a LOT of vulnerabilities there (every security conference exposes new ones) and opening a HTML file or web page can result in arbitrary code being executed with no feedback to the user.

So we won't be enabling this by default, if we support it at all...

[michaelrsweet]

We've decided not to support this.

[bushrod]

Doesn't IPP support authentication and TLS encryption that could mitigate these security concerns?

[gmuth]

A workaround for this issue should be to fulfil the CORS requirements by letting CUPS deliver the 'risky' javascript files. This way the javascript code should be allowed to connect to it's own host. The DocumentRoot is usually /usr/share/doc/cups

<script src="http://cups-host:631/ipp-stuff.js"></script>

see also williamkapke/ipp#3

[thenewguy]

@michaelrsweet Any chance for revisiting this in 2021? It would really simplify things for users of SaaS applications served through the browser that need to print documents if some sort of CORs configuration could be enabled via CUPs.

As it stands, the printer must be exposed (hopefully securely) over the internet instead of just the LAN. This seems worse than exposing CORs to the LAN. Considering most people cannot configure a router, it is unlikely that the average person working from home is sharing their printer over the internet securely...

Being able to point and click that "fancyprintjobs.example.com" should be allowed to print via the browser could only be a good thing here

[michaelrsweet]

@thenewguy If this was ever supported, it will be in OpenPrinting CUPS and definitely not in Apple CUPS (which is firmly in maintenance mode now...)

[thenewguy]

Linking related issue OpenPrinting/cups#266