Quando la politica della stessa origine impedisce l'invio di una richiesta?

3

Ho avuto a che fare con alcune confusioni sulla politica della stessa origine.

Diciamo che il mio attacco assomiglia a questo. Nella pagina a evil.com l'autore dell'attacco ha inserito (jQuery):

$.post('http://bank.com/transfer', { to: 'ciro', ammount: '100' })

L'aggressore ti convince quindi a visitare evil.com .

Questo carico utile (jQuery) verrà ancora eseguito? Manderebbe una richiesta o genererebbe un errore senza inviare la richiesta?

Sto confrontando questo con XMLHttpRequest dove la richiesta va almeno, ma la risposta non può essere letta a causa di violazioni della politica dell'origine stessa. In caso di violazione SOP, la richiesta viaggia sempre sul server? Ci sono dei casi in cui SOP impedisce l'invio della richiesta e la intercetta prima?

    
posta H4X 11.12.2016 - 04:47
fonte

1 risposta

4

Would it send a request or throw an error without sending the request?

La tua richiesta POST verrebbe inviata. Tuttavia, la politica della stessa origine impedisce che tu sia in grado di leggere la risposta. Proprio come un normale invio di moduli, è un tipo di scrittura di origine incrociata . Ecco una panoramica di Mozilla :

  • Cross-origin writes are typically allowed. Examples are links, redirects and form submissions. Certain rarely used HTTP requests require preflight.
  • Cross-origin embedding is typically allowed. Examples are listed below.
  • Cross-origin reads are typically not allowed, but read access is often leaked by embedding. For example you can read the width and height of an embedded image, the actions of an embedded script, or the availability of an embedded resource.

Nel tuo scenario, la richiesta scatenerebbe un'azione involontaria (un bonifico bancario). Questo tipo di attacco è chiamato falsificazione di richieste cross-site (CSRF). Per prevenirli, gli sviluppatori devono prendere attivamente contromisure come l'implementazione dei token CSRF .

Are there any cases where SOP prevents the request from being sent and catches it before?

Sì. Ad esempio, non puoi specificare metodi diversi da GET , POST e HEAD per impostazione predefinita. Altri metodi devono essere esplicitamente consentiti utilizzando una tecnica chiamata condivisione delle risorse tra origini (CORS ). Ecco perché i metodi personalizzati vengono talvolta utilizzati come alternativa (discutibile) ai token CSRF.

Per consentire un metodo personalizzato FOO da qualsiasi origine, il server potrebbe rispondere con queste intestazioni:

Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: FOO

Ecco come Google Chrome rifiuta una richiesta con il metodo FOO a https://www.google.com :

Puoivederecheilbrowserinviaprimaunarichiesta preflight OPTIONS per verificare quali metodi sono consentiti tramite CORS. Il server risponde quindi con uno stato di 405 che indica che FOO non è consentito e l'intera richiesta non riesce.

    
risposta data 11.12.2016 - 05:51
fonte

Leggi altre domande sui tag