Which, from my perspective, is justification to disable reading the sensor until it can be implemented in a way that prevents the cross-origin stealing attack. Users shouldn't have to worry about this.
Haik On Wed, Apr 26, 2017 at 8:28 AM, Ehsan Akhgari <ehsan.akhg...@gmail.com> 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 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 <e...@rtfm.com <mailto: >> e...@rtfm.com>> wrote: >> >> >> >> On Tue, Apr 25, 2017 at 3:40 PM, Salvador de la Puente >> <sdelapue...@mozilla.com <mailto:sdelapue...@mozilla.com>> 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 >> <j...@mozilla.com <mailto:j...@mozilla.com>> 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 < >> > sdelapue...@mozilla.com <mailto:sdelapue...@mozilla.com>> >> 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> for further >> >> processing? >> >> How it is possible for evil.com <http://evil.com> to get >> access to protected resources? >> >> >> >> On Tue, Apr 25, 2017 at 8:04 PM, Ehsan Akhgari >> <ehsan.akhg...@gmail.com <mailto:ehsan.akhg...@gmail.com>> >> >> wrote: >> >> >> >> > On 04/25/2017 10:25 AM, Andrew Overholt wrote: >> >> > >> >> >> On Tue, Apr 25, 2017 at 9:35 AM, Eric Rescorla >> <e...@rtfm.com <mailto:e...@rtfm.com>> 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> >> >> >> 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>. >> >> >> _______________________________________________ >> >> >> dev-platform mailing list >> >> >> dev-platform@lists.mozilla.org >> <mailto:dev-platform@lists.mozilla.org> >> >> >> https://lists.mozilla.org/listinfo/dev-platform >> <https://lists.mozilla.org/listinfo/dev-platform> >> >> >> >> >> > >> >> > _______________________________________________ >> >> > dev-platform mailing list >> >> > dev-platform@lists.mozilla.org >> <mailto:dev-platform@lists.mozilla.org> >> >> > https://lists.mozilla.org/listinfo/dev-platform >> <https://lists.mozilla.org/listinfo/dev-platform> >> >> > >> >> >> >> >> >> >> >> -- >> >> <salva /> >> >> _______________________________________________ >> >> dev-platform mailing list >> >> dev-platform@lists.mozilla.org >> <mailto:dev-platform@lists.mozilla.org> >> >> https://lists.mozilla.org/listinfo/dev-platform >> <https://lists.mozilla.org/listinfo/dev-platform> >> >> >> > >> > >> >> >> -- >> <salva /> >> _______________________________________________ >> dev-platform mailing list >> dev-platform@lists.mozilla.org >> <mailto:dev-platform@lists.mozilla.org> >> https://lists.mozilla.org/listinfo/dev-platform >> <https://lists.mozilla.org/listinfo/dev-platform> >> >> >> >> >> >> -- >> <salva /> >> > > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
