Enable CORS on http://treatment.plazi.org/

[retog]

For the treatments to be accessible in browser-applications we should https://enable-cors.org/.

[gsautter]

Done.

[gsautter]

Proudly announcing we now have https://en.wikipedia.org/wiki/Evil_bit compatibility, as CORS is nothing else.

[retog]

That was really amazingly fast! Thanks, @gsautter.

[gsautter]

Well, Tomcat comes with a CORS filter you can deploy ... and I'd done that already for the matching service, so only needed to change the filter pattern ...

Doesn't change my opinion that CORS is completely moot, though, as noting can force clients to observe it ... just like the TCP evil bit.

[retog]

Doesn't change my opinion that CORS is completely moot, though, as noting can force clients to observe it ... just like the TCP evil bit.

Except it's the other way round. With the header you're setting you're allowing, not denying access. Of course, people could have used browsers that allow cross-origin even if the header is not set. Now it works with the well-behaving browsers actually out there.

[gsautter]

Except it's the other way round. With the header you're setting you're allowing, not denying access. Of course, people could have used browsers that allow cross-origin even if the header is not set. Now it works with the well-behaving browsers actually out there.

I am well aware of that ... the point was that it's not actually denying access to anyone who simple ignores the headers, so the whole model is flawed, as it only creates extra effort for well-meaning code, while being completely ineffective against non-well-meaning code, and hence nothing but moot, useless overhead.

[retog]

I am well aware of that ... the point was that it's not actually denying access to anyone who simple ignores the headers, so the whole model is flawed, as it only creates extra effort for well-meaning code, while being completely ineffective against non-well-meaning code, and hence nothing but moot, useless overhead.

No, it is effective against the attack scenarios it addresses. Here's a scenario: Imagine Plazi charges 1$ per treatment and has contracts with universities so that when accessing treatment bank from their networks the costs are automatically charged to the university. Now further assume plazi uses IP Ranges to determine if a request should be billed to a university (without this additional assumption, a Access-Control-Allow-Credentials: false-default would provide enough protection). In this scenario, the malicious website student-goodies.com could, when accessed from within the university, send code to the browser that accesses a bunch of treatments and send them back to student-goodies.com server. The users accessing the site wouldn't notice that they are being used by the operators of student-goodies.com to steal valuable treatments at the expenses of their university.

[myrmoteras]

Is this a realistic scenario for Plazi/TB where all is open anyways?

From: Reto Gmür @.> Sent: Sunday, August 7, 2022 11:17 AM To: plazi/treatmentBank @.> Cc: Subscribed @.***> Subject: Re: [plazi/treatmentBank] Enable CORS on http://treatment.plazi.org/ (Issue #55)

EXTERNAL SENDER

I am well aware of that ... the point was that it's not actually denying access to anyone who simple ignores the headers, so the whole model is flawed, as it only creates extra effort for well-meaning code, while being completely ineffective against non-well-meaning code, and hence nothing but moot, useless overhead.

No, it is effective against the attack scenarios it addresses. Here's a scenario: Imagine Plazi charges 1$ per treatment and has contracts with universities so that when accessing treatment bank from their networks the costs are automatically charged to the university. Now further assume plazi uses IP Ranges to determine if a request should be billed to a university (without this additional assumption, a Access-Control-Allow-Credentials: false-default would provide enough protection). In this scenario, the malicious website student-goodies.com could, when accessed from within the university, send code to the browser that accesses a bunch of treatments and send them back to student-goodies.com server. The users accessing the site wouldn't notice that they are being used by the operators of student-goodies.com to steal valuable treatments at the expenses of their university.

- Reply to this email directly, view it on GitHubhttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fplazi%2FtreatmentBank%2Fissues%2F55%23issuecomment-1207365314&data=05%7C01%7C%7C67fdd6bf8ba249e0fb7d08da7855a07c%7Cbe0003e8c6b9496883aeb34586974b76%7C0%7C0%7C637954606430501290%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1DoPQCtTxcT%2FFbui1HQrygP86EdTiUv0oX8CpGYibKc%3D&reserved=0, or unsubscribehttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FABDFPJGNKJGOFFNAUUPEPMLVX55J5ANCNFSM55VSYAGQ&data=05%7C01%7C%7C67fdd6bf8ba249e0fb7d08da7855a07c%7Cbe0003e8c6b9496883aeb34586974b76%7C0%7C0%7C637954606430501290%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=dJHlnf5bohV6NuSBHwQKOq7RV6%2B%2BN1gNNNNTqGjfgio%3D&reserved=0. You are receiving this because you are subscribed to this thread.Message ID: @.**@.>>

[retog]

Hi @myrmoteras , this is not a possible attack scenario in our case and the reason why we can safely enable cross-origin access to our data. I was just pointing out, that the CORS mechanism does indeed offers real protection against some attacks: it prevents malicious websites from impersonating their visitors to gain access to a third party site.

[gsautter]

Imagine Plazi charges 1$ per treatment and has contracts with universities so that when accessing treatment bank from their networks the costs are automatically charged to the university. Now further assume plazi uses IP Ranges to determine if a request should be billed to a university (without this additional assumption, a Access-Control-Allow-Credentials: false-default would provide enough protection). In this scenario, the malicious website student-goodies.com could, when accessed from within the university, send code to the browser that accesses a bunch of treatments and send them back to student-goodies.com server. The users accessing the site wouldn't notice that they are being used by the operators of student-goodies.com to steal valuable treatments at the expenses of their university.

I do get this ... but it only ever works if at least the browser used inside the university IP range plays along, i.e., CORS relies on client side collaboration of some sort, and there is no way of enforcing that.