Re: XMLHttpRequest error events

You misunderstood: not only a failed CORS check but any error occurring
*before* the CORS check would need to be reported as a generic NetworkError
without further diagnostics.

Otherwise you could write a script to probe the local network by firing off
(failing) CORS-enabled XMLHttpRequests to various IP addresses / local DNS
names and get a treasure trove of useful information (for attackers).

This is already possible to some extent via a timing attack, but at least
that's more work for the attacker, and is something that could be mitigated
by user agents in the future through the insertion of artificial delays for
failed cross-origin fetches.

Nick



On 10 February 2014 18:01, tlhackque <tlhackque@yahoo.com> wrote:

>  for security reasons cross-origin fetches would not be able to provide
> these diagnostics
>
> In that case, the error event should report "Forbidden by cross-origin
> policy".   At least that gives a clue - we know it's not a DNS failure or
> an unplugged cable or...  In this case, not directly useful to the
> end-user, but when (s)he reports it to the help desk, the person they
> escalate it to will have a place to start.  And a developer will (should)
> know what to do when his testing(?) encounters the problem.
>
> Hiding the failure cause does nothing to improve security, rather it makes
> diagnosing issues and writing good code harder.  As such, it's more likely
> to cause people to write overly permissive code 'to get it working'.   The
> bad guys know what rule they're trying to break.  So the current behavior
> really only hurts the good gusy.
>
>
> On 10-Feb-14 12:16, Nick Krempel wrote:
>
> This sounds nice, but for security reasons cross-origin fetches would not
> be able to provide these diagnostics unless the fetch got as far as passing
> the CORS check.
>
>
>
> On 10 February 2014 12:30, tlhackque <tlhackque@yahoo.com> wrote:
>
>> I found myself using XMLHttpRequest in an application where, when things
>> go wrong, I wanted to provide information to the user.  I was unable to do
>> so.
>>
>> Specifically, I POSTed a form with a large file, and specified listeners
>> for abort and error events (among others) on both the request and upload
>> targets.  I tried disconnecting the network, shutting down the target
>> webserver, mis-spelling the host name, having the server refuse service and
>> injecting various other real-world misadventures.
>>
>> Although I get the events in several browsers, nothing in the event tells
>> me what went wrong.  And I find nothing in the specification (
>> http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html - 22-Nov-2013) to
>> help.
>>
>> According to the spec, in the synchronous model, the exception would at
>> least specify 'NetworkError'.  Async, the only thing one gets is the event
>> type, bytes transfered, and (possibly) total bytes.  One can assume if
>> loaded is zero, no connection was established; otherwise there was a
>> connection failure, but that's about it.
>>
>> It really would be useful - both for debugging and for providing feedback
>> to users - if the error and abort events provided some detail:
>> Was the problem:
>>    DNS failure: no server, host has no A(AAAA) record?
>>    Proxy not reachable?
>>    Host not reachable?
>>    SSL certificate expired?
>>    Connection broken?
>>    Aborted by user action?
>>    Aborted by object destruction?
>> Some supporting detail (e.g. IP address of peer, proxy, etc) would be
>> helpful too.
>>
>> This is not intended to be an exhaustive list.
>>
>> While I would discourage client scripts from trying to analyze
>> OS-specific error codes, some user-actionable clues would be really
>> helpful.  'An error occurred sending <flilename>' is about the best one can
>> do currently, and that doesn't give the user - or the helpdesk - much to go
>> on!
>>
>> Please consider updating the spec to provide reasonable diagnostics for
>> network error events.
>>
>> --
>> This communication may not represent my employer's views,
>> if any, on the matters discussed.
>>
>>
>>
>>
>
>
> --
> This communication may not represent my employer's views,
> if any, on the matters discussed.
>
>