Right, I did not remember that request to victim.com originated in <img> tags inside evil.com went to the network with 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? Do we have any way to measure the traffic of the web properties using this API? On Wed, Apr 26, 2017 at 5:28 PM, 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 /> >> > > -- <salva /> _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
