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 />
_______________________________________________
dev-platform mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-platform
