In quali modi un javascript che effettua una richiesta HEAD su più domini può essere una minaccia?

4

Stavo leggendo questa risposta alla domanda Perché la stessa politica di origine è così importante?

Basically, when you try to make an XMLHttpRequest to a different domain, the browser will do one of two things:

  1. If it's a GET or POST request which meets certain limits (which the makers of the standard have determined to add no extra risk for CSRF attacks) then the browser just passes the request through.

  2. Otherwise, it does what's called a "preflighted request", where it first sends an OPTIONS request instead and only does what you requested if the checks pass for the OPTIONS request.

Ma una richiesta HEAD non riceverà nulla di diverso dalle intestazioni e uno stato, che ritengo sia almeno altrettanto sicuro di una richiesta OPTIONS, ma sarebbe effettivamente bloccato.

Leggendo questa sezione della bozza sui Principi dello Stesso- Politica di origine indica che l'interfaccia di posizione è disponibile

There are some exceptions to this general policy. For example, some parts of HTML's Location interface are available across origins (e.g., to allow for navigating other browsing contexts).

C'è un motivo di sicurezza per cui HEAD è effettivamente bloccato dalla politica della stessa origine?

    
posta Iain 26.07.2013 - 12:19
fonte

1 risposta

4

Ci sono due problemi con le richieste tra domini: se una richiesta raggiunge il server e se una risposta è visibile allo script client che ha emesso la richiesta. Le cosiddette richieste "semplici" (che usano un metodo "semplice" e includono solo intestazioni "semplici") sono garantite per farlo sul server, ma la loro visibilità sullo script client dipende ancora dalle intestazioni CORS appropriate. Le richieste non semplici non vengono immediatamente inviate al server; per prima cosa, il browser invia una richiesta di "preflight" (usando OPTIONS) e utilizza le intestazioni nella risposta di preflight per decidere se inviare la richiesta effettiva. Questo perché le richieste non semplici potrebbero alterare lo stato del server, e quindi potrebbero causare danni anche se al cliente è stato vietato di vedere la risposta.

Sia chiaro che il risultato di una richiesta OPZIONI di preflight è mai reso disponibile per lo script del client. Viene utilizzato solo privatamente dal browser per decidere se eseguire la richiesta effettiva avviata dallo script:

Sehaiscrittounoscriptchehaprovatoafareunarichiestadieffettivo(cioè,visibiledalclient),sarebbesoggettaallenormaliregoleCORS:

varxhr=newXMLHttpRequest();xhr.open("OPTIONS", "http://cors-enabled-server.example.com/");
xhr.onload = function(e) { console.log(e); }
xhr.send();

Questa richiesta genererà un preflight (poiché OPTIONS è un metodo non semplice) e la richiesta non riuscirà , a meno che il server non invii una risposta di Access-Control-Allow-Methods: OPTIONS . Si noti che questo genera una richiesta OPZIONI di preflight, ma quella richiesta OPZIONI di preflight è mai resa visibile allo script . Lo script può vedere solo la "reale" richiesta / risposta di OPTIONS, che viene dopo un preflight riuscito.

In secondo luogo, chiedi:

But a HEAD request won't receive anything other than headers and a status... yet it would effectively be blocked.

Questo non è vero: la visibilità del risultato potrebbe essere bloccata, ma la richiesta non lo è. Questo perché il metodo HEAD è un metodo semplice secondo CORS e quindi non richiede una verifica preliminare, proprio come GET e POST:

A method is said to be a simple method if it is a case-sensitive match for one of the following:

  • GET
  • HEAD
  • POST

Una semplice richiesta HEAD per più domini richiede ancora una risposta Access-Control-Allow-Origin accettabile, ma non richiede una verifica preliminare. Pertanto, una semplice richiesta HEAD (ad esempio, una che non ha intestazioni speciali che richiedono una verifica preliminare) verrà sempre inviata direttamente al server.

OPTIONS, d'altra parte, è un metodo non semplice e deve essere approvato da Access-Control-Allow-Methods in una risposta di preflight. Non confondere una richiesta OPZIONI di preflight (che non è mai soggetta a CORS, ma è visibile solo al browser, non allo script) con una richiesta OPZIONI JavaScript (che è visibile al cliente, ma solo se supera i requisiti CORS).

Per rispondere alla domanda del titolo nel titolo, " In che modo un JavaScript può rendere una richiesta HEAD tra domini una minaccia? ": è una minaccia all'incirca sull'ordine di consentire un dominio incrociato Richiesta GET, poiché HEAD dovrebbe essere - secondo le specifiche HTTP - lo stesso di fare una richiesta GET, ma senza il corpo della risposta. C'è ancora il potenziale per la perdita di molti dati sensibili attraverso intestazioni e codici di stato.

    
risposta data 26.07.2013 - 15:38
fonte

Leggi altre domande sui tag