Request Support  | Contact Sales

Diventa Autore per CoreTech | Scopri di più





Cross-Origin Resource Sharing (CORS) e intestazione Access-Control-Allow-Origin

05/10/20 CoreTech Blog

I browser moderni utilizzano la stessa politica di origine (SOP) per impostazione predefinita. Questo significa che il recupero di risorse da altre origini non è consentito. Tuttavia, in alcuni casi, tali operazioni sono necessarie. Cross-Origin Resource Sharing (CORS) è stato progettato per affrontare simili circostanze utilizzando le intestazioni di risposta HTTP, che includono Access-Control-Allow-Origin.

CORS: Cross-Origin Resource Sharing

L’acronimo “CORS” sta per “Cross-Origin Resource Sharing”. L’espressione inglese fa riferimento alla condivisione di risorse provenienti da origini diverse, che è il compito specifico del CORS. Normalmente, i browser funzionano sulla base della Same-Origin Policy (SOP). Il CORS interviene quando è necessario che un server richiami risorse di origine differente rispetto alla propria. Si tratta di un meccanismo basato sulle intestazioni HTTP. Permette al server di segnalare da quale origine diversa dalla propria il browser può caricare le risorse.

Same-Origin Policy: che cos'è la politica della stessa origine

Same-Origin Policy (SOP) è una politica di sicurezza del browser web generale per le richieste cross-origin. Controlla l'accesso ai dati tra siti web e applicazioni web. Se non ci fosse SOP, qualsiasi pagina web e qualsiasi codice JavaScript sarebbe in grado di accedere al DOM di altre pagine HTML: questo aspetto rappresenterebbe una falla nella sicurezza.

L'origine è un insieme di caratteristiche comuni di una risorsa web. Di solito, include tre elementi:

  • lo schema (protocollo);
  • il nome host (dominio / sottodominio);
  • la porta. 

Tutte le risorse identificate dallo stesso schema: hostname / any: port hanno la stessa origine. Tuttavia, se anche uno dei tre elementi è diverso, non solo se le risorse hanno un dominio diverso, i browser moderni come Google Chrome considerano le risorse come aventi un'origine diversa. SOP viene applicato dal browser ogni volta che interagiscono elementi di origini diverse. Per esempio, una pagina non può recuperare il contenuto del suo iframe a meno che contenuto e iframe non siano della stessa origine.

Quanto sopra è solo una brevissima introduzione a questo argomento. Per ulteriori informazioni sulla politica della stessa origine (SOP), leggi il nostro articolo su questo argomento .

Il CORS rilassa il SOP: ecco come

La condivisione delle risorse tra le origini funziona come segue:

  1. Il codice JavaScript front-end servito da https://example.comrisorsa 1 ) tenta di utilizzare XmlHttpRequest (XHR) per effettuare una richiesta Ajax per https://css.example.com/formdata/content.json ( risorsa 2 ) .

GET /formdata/content.json HTTP/1.1

Host: css.example.com

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9

Accept-Encoding: gzip, deflate

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.105 Safari/537.36

Origin: https://example.com

  1. Il browser riceve la risposta dal server web e vede che le origini sono diverse.
  2. Normalmente, a causa di SOP, il browser negherebbe alla risorsa 1 l'accesso alla risorsa 2 , ad esempio, restituirebbe un errore Cross-Origin Request Blocked: The Same Origin Policy non consente la lettura della risorsa remota .
  3. Se CORS è impostato per la risorsa 2, la risposta dalla risorsa 2 include intestazioni HTTP speciali, principalmente Access-Control-Allow-Origin .

HTTP/1.1 200 OK

Age: 277354

Cache-Control: max-age=604800

Content-Encoding: gzip

Content-Length: 1701

Content-Type: text/html; charset=UTF-8

Date: Mon, 03 Aug 2020 11:43:26 GMT

Vary: Accept-Encoding

X-Cache: HIT

Access-Control-Allow-Origin: https://example.com

  1. L' intestazione Access-Control-Allow-Originafferma che alla risorsa 1 è consentito accedere alla risorsa 2.
  2. Il browser elabora la richiesta.

Si noti che l’intestazione Access-Control-Allow-Origin può specificare solo un'origine di origine o può specificare un carattere jolly. Un carattere jolly rende la risorsa 2 accessibile da tutte le origini. Ciò potrebbe, ad esempio, avere senso per i caratteri Web, che dovrebbero essere accessibili tra domini.

Per abilitare CORS sul tuo server web, consulta il sito web enable-cors , che contiene le istruzioni per nginx, Apache, IIS e molti altri server web.

Richieste di verifica preliminare dal browser al CORS

Il metodo sopra viene utilizzato per richieste semplici che il browser web considera sicure, come le tipiche richieste GET. In altri casi, sono possibili rischi per la sicurezza. Questo avviene, per esempio, quando sono presenti intestazioni personalizzate nella richiesta, cioè qualsiasi altra intestazione tranne Accept , Accept-Language , Content-Language , Content-Type , DPR , Downlink , Save-Data , Viewport-Width , Width. Un’altra circostanza in cui viene percepita una minaccia si verifica quando il metodo HTTP è PUT, DELETE, CONNECT, OPTIONS, TRACE o PATCH.

La richiesta CORS di preflight è una richiesta OPTIONS con intestazioni CORS:

OPTIONS / HTTP/1.1

Banner

Host: www.example.com

(...)

Origin: http://example2.com

Access-Control-Request-Method: POST

Access-Control-Request-Headers: X-CUSTOM, Content-Type

La risposta del server alla richiesta del metodo OPTIONS include i metodi consentiti, le intestazioni, le credenziali e il tempo di validità:

HTTP/1.1 204 No Content

(...) Access-Control-Allow-Origin: http://example2.com

Access-Control-Allow-Methods: POST, GET, OPTIONS

Access-Control-Allow-Headers: X-CUSTOM, Content-Type

Access-Control-Allow-Credentials: true

Access-Control-Max-Age: 86400

Al termine della verifica preliminare, possono essere inviate richieste regolari con intestazioni CORS.

Vale la pena implementare CORS?

Ora che sai come funziona CORS, potresti domandarti: vale la pena implementarlo sul mio server? Significherebbe alterare la configurazione del server per aggiungere intestazioni CORS per risorse specifiche o alterare il codice lato server per inviare tali intestazioni nella risposta. Questo renderà la tua applicazione web più sicura?

Sfortunatamente, SOP e CORS non impediscono alcun attacco web. Possono essere trattati come un meccanismo aggiuntivo per prevenire attacchi CSRF (cross-site request forgery), ma non vanno utilizzati al posto dei token anti-CSRF. Inoltre, SOP e CORS sono completamente inutili per prevenire eventuali attacchi di cross-site scripting (XSS) .

Tuttavia, poiché tutti i browser moderni supportano SOP, potrebbe essere necessario implementare comunque le intestazioni CORS, solo per consentire l'utilizzo delle risorse da altre origini. Questo, tuttavia, non è un requisito di sicurezza, ma un requisito funzionale: senza le intestazioni CORS alcune applicazioni web semplicemente non funzioneranno.


Articoli su Acunetix

Trovare le vulnerabilità dei siti web prima degli HackerL'importanza della convalida delle correzioni: lezioni da GoogleSDLC agile e sicuro - Best practiceIn che misura le aziende gestiscono la sicurezza delle applicazioni Web?Cross-Origin Resource Sharing (CORS) e intestazione Access-Control-Allow-OriginCosa sono i reindirizzamenti aperti?DevSecOps: come arrivarci da DevOpsIl bigino su SQL Injection per sviluppatoriSfruttare SSTI in ThymeleafSicurezza nginx: come proteggere la configurazione del serverRafforzamento del sistema Web in 5 semplici passaggiCos'è la sicurezza del sito Web - Come proteggere il tuo sito Web dall'hackingRapporto sulle vulnerabilità delle applicazioni Web Acunetix 2020Perché l'elenco delle directory è pericoloso?Cosa sono gli hack di Google?Cosa è l'attacco BEASTWeb Shells in Action - Rilevazione e prevenzione - parte 5Web Shells in Action - parte 4Mantenere le Web Shells sotto copertura - parte 3Introduzione alle web shell - parte 2: 101 Uso di PHPIntroduzione alle web shell - parte 1Debunking 5 miti sulla postura della sicurezza informaticaIniezioni di NoSQL e come evitarleConfigurazione passo passo di Acunetix con JenkinsCosa sono i riferimenti a oggetti diretti non sicuriAnche il più forte cade: un'iniezione SQL in Sophos XG FirewallAcunetix rilascia Business Logic RecorderCome recuperare un sito Web compromessoCome difendersi dagli hacker Black Hat durante la pandemia COVID-19Che cos'è l'inclusione remota dei file (RFI)?Apache Security - 10 consigli per un'installazione sicuraUn nuovo sguardo sugli attacchi correlati al proxy inversoVulnerabilità delle password comuni e come evitarleTutto quello che devi sapere sugli attacchi Man-in-the-MiddleChe cosa sono le iniezioni HTMLRed Teaming – 5 consigli su come farlo in modo sicuroTesta le tue competenze XSS utilizzando siti vulnerabiliPerché hacker malintenzionati hanno messo gli occhi sugli ospedaliPratiche di codifica sicura – I tre principi chiaveLa maledizione delle vecchie librerie JavaMutation XSS nella ricerca GoogleIgnorare SOP utilizzando la cache del browserCome e perché evitare reindirizzamenti e inoltri non convalidati?Dirottamento di sessione e altri attacchi di sessioneCome abbiamo trovato un altro XSS in Google con AcunetixChe cos'è un buffer overflowChe cos'è l'overflow di IntegerChe cos'è HSTS e perché dovrei usarlo?Che cosa è OS Command InjectionVulnerabilità delle entità esterne XML in Internet ExplorerCoreTech assicura protezione dei siti Web con AcunetixCoreTech distributore Acunetix a fianco dei partner per la CyberSecurityCyberSecurity applicativa, nuova opportunità per voi!