Well, I'm not saying "don't fix it" but if we switch the API off then other-than-evil ways of using the API will never happen and, as Belen said before, it undermines the confidence on the Web platform.
I can not foresee the canonical use of the API that would support the decision of not switching it off, but neither I thought of reading an image pixel by pixel with the ambient light sensor, to be honest. On Wed, Apr 26, 2017 at 8:27 PM, Ehsan Akhgari <[email protected]> wrote: > On 04/26/2017 11:36 AM, Salvador de la Puente wrote: > >> Right, I did not remember that request to victim.com <http://victim.com> >> originated in <img> tags inside evil.com <http://evil.com> went to the >> network with victim.com <http://victim.com> credentials so clients can >> reach more than servers. That's fine. >> >> Anyway, with only that use of the APIs, is it not a little bit early to >> say that every possible usage will be harmful? >> > Nobody is saying that every usage of the API is harmful. But the browser > engine doesn't have a way to read the mind of the author of the page to > figure out why a certain API is being used. When APIs expose risks like > this we need some kind of mitigation. Rate limits are one approach, but > it's hard to get right and it's hard to demonstrate its effectiveness given > the existence of wakelock APIs as described in the article. > > Also please note that typically Web APIs aren't designed based on the > assumption that most of the consumers use them in a non-malicious way, > quite the contrary -- we usually assume an untrusted caller because we > can't know much about the intentions of the caller, and our users can't be > expected to make security decisions before visiting a website. > > Do we have any way to measure the traffic of the web properties using this >> API? >> > > That has no bearing on the security aspect of this. And no, we don't. At > best we can add some telemetry for the number of sessions that have an > event handler for this or some such which bug 1359124 was filed for. > > >> On Wed, Apr 26, 2017 at 5:28 PM, Ehsan Akhgari <[email protected] >> <mailto:[email protected]>> wrote: >> >> On 04/25/2017 08:26 PM, Salvador de la Puente wrote: >> >> So the risk is not that high since if the image is not >> protected I can get it and do evil things without requiring >> the Light Sensor API. Isn't it? >> >> >> No, the risk is extremely high. >> >> Here is a concrete example. Some banks give their users scanned >> copies of their cheques (including secret financial information) >> as cookie protected images. Browsers already have protections in >> place that prevent cross-origin pages from reading the pixel >> values of these images by tainting such images and remembering >> that an image is coming from such a source and preventing the >> contents of such a tainted image to be read out through an API >> that gives you access to raw pixel values. Merely uploading the >> URL of such an image to the evil.com <http://evil.com> server >> doesn't help the attacker since they won't have access to the >> user's credentials on the server side. The attack vector being >> discussed here introduces a new vulnerability vector for websites >> to try to steal sensitive information like this in ways that >> currently isn't possible. >> >> >> On Wed, Apr 26, 2017 at 1:30 AM, Eric Rescorla <[email protected] >> <mailto:[email protected]> <mailto:[email protected] >> <mailto:[email protected]>>> wrote: >> >> >> >> On Tue, Apr 25, 2017 at 3:40 PM, Salvador de la Puente >> <[email protected] <mailto:[email protected]> >> <mailto:[email protected] >> <mailto:[email protected]>>> wrote: >> >> The article says: >> >> Embed an image from the attacked domain; generally >> this will >> be a resource >> > which varies for different authenticated users such >> as the >> logged-in user’s >> > avatar or a security code. >> > >> >> And then refers all the steps to this image (binarizing, >> expand and measure >> per pixel) but, If I can embed that image, it is because I >> know the URL for >> it and the proper auth tokens if it is protected. In that >> case, why to not >> simply steal the image? >> >> >> The simple version of this is that the image is cookie >> protected. >> >> -Ekr >> >> >> On Wed, Apr 26, 2017 at 12:23 AM, Jonathan Kingston >> <[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>> wrote: >> >> > Auth related images are the attack vector, that and >> history >> attacks on >> > same domain. >> > >> > On Tue, Apr 25, 2017 at 11:17 PM, Salvador de la >> Puente < >> > [email protected] >> <mailto:[email protected]> >> <mailto:[email protected] >> <mailto:[email protected]>>> wrote: >> > >> >> Sorry for my ignorance but, in the case of Stealing >> cross-origin >> >> resources, >> >> I don't get the point of the attack. If have the >> ability to >> embed the >> >> image >> >> in step 1, why to not simply send this to evil.com >> <http://evil.com> >> <http://evil.com> for further >> >> processing? >> >> How it is possible for evil.com <http://evil.com> >> <http://evil.com> to get >> access to protected resources? >> >> >> >> On Tue, Apr 25, 2017 at 8:04 PM, Ehsan Akhgari >> <[email protected] >> <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected] >> >>> >> >> wrote: >> >> >> >> > On 04/25/2017 10:25 AM, Andrew Overholt wrote: >> >> > >> >> >> On Tue, Apr 25, 2017 at 9:35 AM, Eric Rescorla >> <[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>> wrote: >> >> >> >> >> >> Going back to Jonathan's (I think) question. >> Does anyone >> use this at >> >> all >> >> >>> in >> >> >>> the field? >> >> >>> >> >> >>> Chrome's usage metrics say <= 0.0001% of page >> loads: >> >> >> >> https://www.chromestatus.com/metrics/feature/popularity#Ambi >> <https://www.chromestatus.com/metrics/feature/popularity#Ambi> >> <https://www.chromestatus.com/metrics/feature/ >> popularity#Ambi >> <https://www.chromestatus.com/metrics/feature/popularity#Ambi>> >> >> >> entLightSensorConstructor. >> >> >> >> >> > >> >> > This is the new version of the spec which we >> don't ship. >> >> > >> >> > >> >> > We are going to collect telemetry in >> >> >> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1359124 >> <https://bugzilla.mozilla.org/show_bug.cgi?id=1359124> >> <https://bugzilla.mozilla.org/show_bug.cgi?id=1359124 >> <https://bugzilla.mozilla.org/show_bug.cgi?id=1359124>>. >> >> >> _______________________________________________ >> >> >> dev-platform mailing list >> >> >> [email protected] >> <mailto:[email protected]> >> <mailto:[email protected] >> <mailto:[email protected]>> >> >> >> https://lists.mozilla.org/listinfo/dev-platform >> <https://lists.mozilla.org/listinfo/dev-platform> >> <https://lists.mozilla.org/listinfo/dev-platform >> <https://lists.mozilla.org/listinfo/dev-platform>> >> >> >> >> >> > >> >> > _______________________________________________ >> >> > dev-platform mailing list >> >> > [email protected] >> <mailto:[email protected]> >> <mailto:[email protected] >> <mailto:[email protected]>> >> >> > https://lists.mozilla.org/listinfo/dev-platform >> <https://lists.mozilla.org/listinfo/dev-platform> >> <https://lists.mozilla.org/listinfo/dev-platform >> <https://lists.mozilla.org/listinfo/dev-platform>> >> >> > >> >> >> >> >> >> >> >> -- >> >> <salva /> >> >> _______________________________________________ >> >> dev-platform mailing list >> >> [email protected] >> <mailto:[email protected]> >> <mailto:[email protected] >> <mailto:[email protected]>> >> >> https://lists.mozilla.org/listinfo/dev-platform >> <https://lists.mozilla.org/listinfo/dev-platform> >> <https://lists.mozilla.org/listinfo/dev-platform >> <https://lists.mozilla.org/listinfo/dev-platform>> >> >> >> > >> > >> >> >> -- >> <salva /> >> _______________________________________________ >> dev-platform mailing list >> [email protected] >> <mailto:[email protected]> >> <mailto:[email protected] >> <mailto:[email protected]>> >> https://lists.mozilla.org/listinfo/dev-platform >> <https://lists.mozilla.org/listinfo/dev-platform> >> <https://lists.mozilla.org/listinfo/dev-platform >> <https://lists.mozilla.org/listinfo/dev-platform>> >> >> >> >> >> >> -- <salva /> >> >> >> >> >> >> -- >> <salva /> >> > > -- <salva /> _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
