- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Fri, 8 May 2015 19:20:54 +0200
- To: Ahmed Elsobky <mreagle0x@gmail.com>
- Cc: WebAppSec WG <public-webappsec@w3.org>, Jake Archibald <jakearchibald@google.com>, Adam Barth <abarth@google.com>
On Fri, May 8, 2015 at 4:00 PM, Ahmed Elsobky <mreagle0x@gmail.com> wrote:
> 2015-05-08 7:13 GMT+02:00 Anne van Kesteren <annevk@annevk.nl>:
>>>Do you have a test case showing that <script> fires an error event
>>>consistently for 4xx or 5xx status codes? I thought it would always
>>>try to parse the result as a script and execute it
>
> Sure, Here is a test-case for 500+ status codes:
> <script src=http://apps.testinsane.com/rte/status/500/0
> onerror="alert('fires onerror')"></script>
>
> And this is a 4xx example:
> <script src=http://apps.testinsane.com/rte/status/403/0
> onerror="alert('fires onerror')"></script>
>
> It's also worth noting that this has other implications rather than user
> deanonymization and login detection..
That is somewhat fascinating. I wonder what the actual check is
browsers do. Follow all redirects atomically and then it has to be in
the 2xx range?
Jake, Adam, it seems we already leak status codes to some extent for
no-cors fetches. So maybe that opens some doors for distinguishing a
2xx from a "network error" in API land.
(Although as Ahmed points it, that we do this is also problematic, and
we should probably have some way for sites to opt-out of leaking all
this stuff across origins.)
--
https://annevankesteren.nl/
Received on Friday, 8 May 2015 17:21:18 UTC