Hi,
I'm working on a Pull Request for Bodhi web interface to allow retrieving bugs information when we try to attach them to an update. This way we can do some checks on the bug we're trying to attach (is it private? is it a Fedora or Fedora EPEL bug?...) and provide some useful information in the update submission form.
The problem is that the ajax request to Bugzilla fails, because BZ doesn't provide CORS headers. I've asked BZ guys [2] to add those headers, but I'm a bit confused about how CORS works and I would need some help from someone who may have a deeper knowledge on this. Does the BZ server need to provide the `Access-Control-Allow-Headers` header or the `Access-Control-Allow-Origin` header? Is it correct what I asked in the opened bug [3]?
What type of security issue may arise with a wildcarded `Access-Control-Allow-Headers: *` header? As I understand CORS, it's not a server protection, rather a client protection. In fact, installing a browser extension like CorsE for Firefox easily bypass that "protection" and allows the script to run. Am I wrong?
Thanks in advance for any help. Mattia
[1] https://github.com/mattiaverga/bodhi/tree/manual_bugs [2] https://bugzilla.redhat.com/show_bug.cgi?id=1641232 [3] https://bugzilla.redhat.com/show_bug.cgi?id=1641232#c6
Il 10/30/18 6:36 PM, Mattia Verga ha scritto:
[1] https://github.com/mattiaverga/bodhi/tree/manual_bugs [2] https://bugzilla.redhat.com/show_bug.cgi?id=1641232 [3] https://bugzilla.redhat.com/show_bug.cgi?id=1641232#c6
A more precise link to the ajax call to Bugzilla:
https://github.com/mattiaverga/bodhi/blob/625c6d33256418f4135c533aea278359c2...
On 30/10/2018 17:36, Mattia Verga wrote:
The problem is that the ajax request to Bugzilla fails, because BZ doesn't provide CORS headers. I've asked BZ guys [2] to add those headers, but I'm a bit confused about how CORS works and I would need some help from someone who may have a deeper knowledge on this. Does the BZ server need to provide the `Access-Control-Allow-Headers` header or the `Access-Control-Allow-Origin` header? Is it correct what I asked in the opened bug [3]?
Principally it needs to send Access-Control-Allow-Origin if it is happy to allow the request - if the request requires unusual headers then it might need to send the other one as well.
What type of security issue may arise with a wildcarded `Access-Control-Allow-Headers: *` header? As I understand CORS, it's not a server protection, rather a client protection. In fact, installing a browser extension like CorsE for Firefox easily bypass that "protection" and allows the script to run.
No it protects against unintended exfiltration of data from the server - without it a random web page could have javascript that did a background XHR to a web site that required authentication and just wait until somebody happens to visit that page who happens to have a valid session cookie for the target site.
So allowing CORS access to resources that don't require authentication is not normally a problem but allowing it to resources that do require some sort of authentication requires that you trust the domain you are allowing the access to.
So for BZ I guess the issue will be figuring out if any of the bugs you are getting information on are restricted in any way? or maybe that's fine if the bodhi user has access to those bugs and the domain can just be validated to restrict it to bodhi?
Tom
On 30/10/2018 18:13, Tom Hughes wrote:
On 30/10/2018 17:36, Mattia Verga wrote:
What type of security issue may arise with a wildcarded `Access-Control-Allow-Headers: *` header? As I understand CORS, it's not a server protection, rather a client protection. In fact, installing a browser extension like CorsE for Firefox easily bypass that "protection" and allows the script to run.
No it protects against unintended exfiltration of data from the server - without it a random web page could have javascript that did a background XHR to a web site that required authentication and just wait until somebody happens to visit that page who happens to have a valid session cookie for the target site.
Of course for non-GET requests this extends beyond exfiltration to state altering operations, so that background script might place an order or submit a new bug or whatever using your session cookie.
Tom
Il 10/30/18 7:13 PM, Tom Hughes ha scritto:
No it protects against unintended exfiltration of data from the server - without it a random web page could have javascript that did a background XHR to a web site that required authentication and just wait until somebody happens to visit that page who happens to have a valid session cookie for the target site.
So allowing CORS access to resources that don't require authentication is not normally a problem but allowing it to resources that do require some sort of authentication requires that you trust the domain you are allowing the access to.
So, for example, it is acceptable that https://apps.fedoraproject.org/packages/ sends a `access-control-allow-origin: *` header because it doesn't require authentication, while BZ must use something more granular, doesn't it?
So for BZ I guess the issue will be figuring out if any of the bugs you are getting information on are restricted in any way? or maybe that's fine if the bodhi user has access to those bugs and the domain can just be validated to restrict it to bodhi?
From what I see, if a bug is somehow restricted (like private bugs) BZ will manage that with an error response in the json reply. For example:
https://bugzilla.redhat.com/jsonrpc.cgi?method=Bug.get%C2%B6ms=%5B%7B%22ids%...]
returns me a "You are not authorized to access" even if in the same browser session I'm logged in in BZ and I can see the bug content in the html view.