Without further context or more specific question I can provide only general response here.

Since CORS is a way to bypass SOP in a controlled manner, I assume infosec will want to vet all origins before they are allowed on bugzilla side. It seems that this request is mostly motivated by Bodhi, so it may be worth checking with infosec whether Bodhi meets their expectations (w.r.t. technical measures, governance, operational security etc.) and whether they would be OK with it in general. Checking first before committing to development might save some effort.

I do not know what it a bandwidth of bugzilla dev team, and what are plans for bz5 upgrade, so this might be prioritized after the upgrade. It would make sense AFAIK, since there are changes to authentication in BZ5 that might be relevant to this request. Waiting until after upgrade to let the dust settle might save some effort as well.

Last, just before deployment I'd like a quick audit by a pentester on a staging instance.

I should add that I'm only a contributor to Bodhi not involved in governance, etc.

The call I would like to do is viewable at https://github.com/mattiaverga/bodhi/blob/625c6d33256418f4135c533aea278359c282420b/bodhi/server/static/js/update_form.js#L315

for example:
https://bugzilla.redhat.com/jsonrpc.cgi?method=Bug.get&params=[{%22ids%22:1551307}]

Hi Mattia, have you tested on https://bugzilla5.redhat.com? IIRC we did some CORS changes for the jsonrpc interface on Bugzilla 5, they might be enough for you use case.

Hi Jeff, yes I was aware of Bugzilla 5 and I also tried with it, but it still doesn't send back the required `Access-Control-Allow-Headers: *` header in the json response.

(In reply to Mattia Verga from comment #4)
> Hi Jeff, yes I was aware of Bugzilla 5 and I also tried with it, but it
> still doesn't send back the required `Access-Control-Allow-Headers: *`
> header in the json response.

It's unlikely we'd ever use a wild card, can you specify which headers you'd like?

(In reply to Jeff Fearn from comment #5)

> It's unlikely we'd ever use a wild card, can you specify which headers you'd
> like?

I'm not expert in CORS headers, but for bodhi purposes I think I would need something like `Access-Control-Allow-Origin: *.fedoraproject.org` (to allow both bodhi and bodhi.stg)

My previous comment is wrong, it seems there's no way to specify more than one domain in the `Access-Control-Allow-Origin` header.

The recommended way to do that is to compare the `Origin` header of the request to a list of allowed domains and if the domain is allowed set the `Access-Control-Allow-Origin` in the reply.

So, for Bodhi purposes, the server (or maybe just the jsonrpc.cgi script) should add a
Access-Control-Allow-Origin: https://bodhi.fedoraproject.org
or
Access-Control-Allow-Origin: https://bodhi.stg.fedoraproject.org

header if the request comes from one of those domains.

(In reply to Mattia Verga from comment #4)
> Hi Jeff, yes I was aware of Bugzilla 5 and I also tried with it, but it
> still doesn't send back the required `Access-Control-Allow-Headers: *`
> header in the json response.

It should be doing this, but the header gets returned in the response to the OPTIONS request, not the data request ... maybe the browser doesn't send the OPTIONS request if you aren't trying to do authenticated access?

That change was introduced for Bug 1519998

Also there is a JSONP interface that shouldn't require cors ... if I'm reading the jsopnp docs correctly.

https://bugzilla.redhat.com/docs/en/html/api/Bugzilla/WebService/Server/JSONRPC.html#JSONP

Oh, that link to the API guide it's very useful! I can't find it in the main docs page.

In fact, using JSONP in place of normal JSON-RPC I can successfully retrieve the information I need with an ajax call without the need of cors headers. So I think you can ignore my previous request.

Thank you!

As JSONP works for unauthenticated access I'll nak CORS changes until someone has a specific authentication required use case ... which would probably entail using JWTs in case anyone is wondering :)

*** Bug 1666031 has been marked as a duplicate of this bug. ***

(In reply to Jeff Fearn from comment #5)
> (In reply to Mattia Verga from comment #4)
> > Hi Jeff, yes I was aware of Bugzilla 5 and I also tried with it, but it
> > still doesn't send back the required `Access-Control-Allow-Headers: *`
> > header in the json response.
> 
> It's unlikely we'd ever use a wild card, can you specify which headers you'd
> like?

Could I ask why not? These headers only affect use from browsers and tools like cURL completely ignore them. It's not a security mechanism of any form, as comment 1 would lead us to believe, it's a misconfiguration. As noted in bug 1666031, the REST API as-is is pretty much unusable for anyone that wants to consume data for a dashboard or something similar, which is something that should totally be expected given that we track multiple community projects here and the general open source nature of the projects we at Red Hat are involved in. JSONP is not the answer either - it's a hack at best that limits what one can do with the API(s), though at least it shows how unnecessary not simply setting headers is. Can we please explore simply adding this header for the REST API at a minimum, or at least provide a detailed reason why that can't/won't happen?

For good measure, I've included a list of popular APIs, all of which set this header by default (again, the APIs are useless otherwise).

---

$ curl -Is https://api.github.com/ | grep Access-Control-Allow-Origin
Access-Control-Allow-Origin: *

$ curl -Is https://bugzilla.mozilla.org/rest/bug/ | grep Access-Control-Allow-Origin
Access-Control-Allow-Origin: *

(In reply to Stephen Finucane from comment #12)
> (In reply to Jeff Fearn from comment #5)
> > (In reply to Mattia Verga from comment #4)
> > > Hi Jeff, yes I was aware of Bugzilla 5 and I also tried with it, but it
> > > still doesn't send back the required `Access-Control-Allow-Headers: *`
> > > header in the json response.
> > 
> > It's unlikely we'd ever use a wild card, can you specify which headers you'd
> > like?
> 
> Could I ask why not?

This is what InfoSec have told me, Rob is still needinfo on this bug so maybe he will give the long answer.

Stephen, wildcard disables Same Origin Policy for the page, allowing any other domain to perform cross origin requests:

https://en.wikipedia.org/wiki/Cross-origin_resource_sharing

"A wildcard same-origin policy is appropriate when a page or API response is considered completely public content and it is intended to be accessible to everyone, including any code on any site. For example, a freely-available web font on a public hosting service like Google Fonts."

Please note that we have confidential bugs in bugzilla, so giving other domains to perform cross-domain request also gives them ability to extract confidential information. This is why those servers need to be vetted by infosec and under Red Hat's control.

Just to muddy the waters here:

curl - output from BMO:

< HTTP/1.1 200 OK
< Access-control-allow-headers: accept, content-type, origin, user-agent, x-requested-with, x-bugzilla-token, x-bugzilla-password, x-bugzilla-login, x-bugzilla-api-key
< Access-Control-Allow-Origin: *
< Content-Type: application/json; charset=UTF-8
< Date: Tue, 05 Feb 2019 04:33:22 GMT
< ETag: /7Sh31/39q6ashVoe4EGHQ
< Referrer-policy: same-origin
< Set-Cookie: Bugzilla_login_request_cookie=dteRs4wulC; path=/; secure; HttpOnly; SameSite=Lax
< Set-Cookie: github_secret=pHGTnfS3MZTK2SxRcjmIbbEr9KniO47RvAiY2NF5yt1AAaD2sNgOAReFEiLfKvO35X9IBkNPmqxkja1j9yQXqAlDcpmvx5GfvS2jWcwkvERUtgGzNLtyiAM9aE7bYI1ccld8XtLDMcMZf1FpAy1Eny5ecR8tcUtGXTQtP0TCmQmfXjKmYWFtE3HsATYKeTKzH9MEqLzuI7rKEhYxUEP8Rq7XmGGqwwzzXLHAEWrCnIjkJj0us8LnA1Ln2Py3P1tR; path=/; secure; HttpOnly; SameSite=Lax
< Status: 200
< Strict-Transport-Security: max-age=31536000; includeSubDomains
< Vary: Accept-Encoding
< X-content-type-options: nosniff
< X-frame-options: SAMEORIGIN
< X-xss-protection: 1; mode=block
< Content-Length: 2204
< Connection: keep-alive


curl -v output from RHBZ:

< HTTP/1.1 200 OK
< Date: Tue, 05 Feb 2019 04:34:10 GMT
< Server: Apache
< X-xss-protection: 1; mode=block
< Access-control-allow-headers: origin, content-type, accept, x-requested-with
< Access-control-allow-origin: *
< X-frame-options: SAMEORIGIN
< X-content-type-options: nosniff
< Etag: x28SWM9swolS5CwSIYLSxw
< Vary: Accept-Encoding,User-Agent
< Content-Type: application/json; charset=UTF-8
< Set-Cookie: Bugzilla_login_request_cookie=gzF3womwma; domain=bugzilla.redhat.com; path=/; HttpOnly
< Connection: close
< Transfer-Encoding: chunked

RHBZ headers:

HTTP/1.1 200 OK
Connection: close
Content-Encoding: gzip
Content-Length: 39803
Content-Type: text/html; charset=UTF-8
Date: Fri, 22 Mar 2019 01:06:56 GMT
Server: Apache
Vary: Accept-Encoding,User-Agent
X-content-type-options: nosniff
X-frame-options: SAMEORIGIN
X-xss-protection: 1; mode=block


BMO Headers:

HTTP/1.1 200 OK
Connection: keep-alive
Content-Encoding: gzip
Content-Security-Policy: default-src 'self'; worker-src 'none'; connect-src 'self' https://product-details.mozilla.org https://www.google-analytics.com https://treeherder.mozilla.org/api/failurecount/; img-src 'self' https://secure.gravatar.com https://bug1525807.bmoattachments.org/; object-src 'none'; script-src 'self' 'nonce-JlgmP8QDn9s2BMOBaAHpcUfHrMeRSthxaMPVNS3J9p0XNp1x' 'unsafe-inline' 'unsafe-eval' https://www.google-analytics.com; style-src 'self' 'unsafe-inline'; frame-src 'self' https://crash-stop-addon.herokuapp.com; frame-ancestors 'none'; form-action 'self' https://www.google.com/search
Content-Type: text/html; charset=UTF-8
Date: Fri, 22 Mar 2019 01:09:05 GMT
Link: </static/v20190312.1/skins/standard/fonts/FiraMono-Regular.woff2?v=3.202>; rel="preload"; as="font", </static/v20190312.1/skins/standard/fonts/FiraSans-Bold.woff2?v=4.203>; rel="preload"; as="font", </static/v20190312.1/skins/standard/fonts/FiraSans-Italic.woff2?v=4.203>; rel="preload"; as="font", </static/v20190312.1/skins/standard/fonts/FiraSans-Regular.woff2?v=4.203>; rel="preload"; as="font", </static/v20190312.1/skins/standard/fonts/FiraSans-SemiBold.woff2?v=4.203>; rel="preload"; as="font", </static/v20190312.1/skins/standard/fonts/MaterialIcons-Regular.woff2>; rel="preload"; as="font", <https://www.google-analytics.com>; rel="preconnect"; crossorigin
Referrer-policy: same-origin
Strict-Transport-Security: max-age=31536000; includeSubDomains
transfer-encoding: chunked
Vary: Accept-Encoding
X-content-type-options: nosniff
X-frame-options: SAMEORIGIN
X-xss-protection: 1; mode=block

(In reply to Ján Rusnačko from comment #14)
> Stephen, wildcard disables Same Origin Policy for the page, allowing any
> other domain to perform cross origin requests:
> 
> https://en.wikipedia.org/wiki/Cross-origin_resource_sharing
> 
> "A wildcard same-origin policy is appropriate when a page or API response is
> considered completely public content and it is intended to be accessible to
> everyone, including any code on any site. For example, a freely-available
> web font on a public hosting service like Google Fonts."
> 
> Please note that we have confidential bugs in bugzilla, so giving other
> domains to perform cross-domain request also gives them ability to extract
> confidential information. This is why those servers need to be vetted by
> infosec and under Red Hat's control.

Hmm, that's a fair point. I'd figured that it would be possible to enable CORS just for the REST API and not the web UI and that this was reasonable, given that other sites that also have non-public info (e.g. GitHub) do it. I don't have an InfoSec background and my few hours spent reading up on CORS clearly do not qualify me to speak on the matter. For what it's worth though, the reasons I want this feature is so that we can augment information provided in Bugzilla with information living in another application (because BZ doesn't provided what we need) and to provide our own UI that hides a lot of the information that isn't relevant to us (something BZ doesn't describe). I've posted about these issues in particular on tech-list [1] so that might be worth a look. Ultimately, perhaps we can do all this behind the firewall and not have to worry about CORS or anything, but it really does seem like a shame to work on something and keep it effectively closed sourced because no one else can use it.

[1] http://post-office.corp.redhat.com/archives/tech-list/2019-May/msg00118.html

Is the use of a proxy method, as discussed in https://medium.com/@dtkatz/3-ways-to-fix-the-cors-error-and-how-access-control-allow-origin-works-d97d55946d9, another pathway for you to change your tool code in Bohdi etc?

Leaving Bugzilla as it is presently configured is the most secure option and preferred.

Jeff, have you examined https://metacpan.org/pod/Plack::Middleware::CrossOrigin for its potential use giving variable responses?

(In reply to Mark Keir from comment #19)
> Jeff, have you examined
> https://metacpan.org/pod/Plack::Middleware::CrossOrigin for its potential
> use giving variable responses?

Nope. Moving to Plack would require significant changes to the web stack and porting a bunch of Bugzilla 6 stuff.

Which would leave duplicating the functionality and I'm not a fan of doing that.

(In reply to Mark Keir from comment #18)
> Is the use of a proxy method, as discussed in
> https://medium.com/@dtkatz/3-ways-to-fix-the-cors-error-and-how-access-
> control-allow-origin-works-d97d55946d9, another pathway for you to change
> your tool code in Bohdi etc?
> 
> Leaving Bugzilla as it is presently configured is the most secure option and
> preferred.

As I stated in comment#9 the original problem with Bodhi was fixed by using JSONP as data type in the ajax request. The bug was reopened in comment#12 by another user.