Listino Supporto Partner Contatti 800 13.40.41

Articoli

Icona delle News


Il flag HttpOnly: protezione dei cookie da XSS

15/10/20 CoreTech Blog

×Non sei ancora nostro cliente Acunetix? Diventa Partner CoreTech e visita il nostro configuratore prezzi

Gli attacchi Cross-site scripting (XSS) sono spesso volti a rubare i cookie di sessione. In un simile attacco, il valore del cookie è accessibile da uno script lato client utilizzando JavaScript ( document.cookie). Tuttavia, nell'uso quotidiano, le applicazioni web hanno raramente bisogno di accedere ai cookie tramite JavaScript. Pertanto, è stato ideato un metodo per proteggere i cookie da tali furti: un flag che comunica al browser Web che è possibile accedere al cookie solo tramite HTTP, il flag HttpOnly .

Il flag HttpOnly non è nuovo. È stato implementato per la prima volta in Microsoft Internet Explorer 6 SP1 nel 2002 per proteggere dal furto di informazioni riservate. Attualmente, tutti i principali browser supportano i cookie HttpOnly . Solo alcuni browser mobili di nicchia possono potenzialmente ignorare questa bandiera.

Come funziona HttpOnly?

L' attributo HttpOnly è un attributo facoltativo dell'intestazione della risposta HTTP Set-Cookie che viene inviata dal server Web insieme alla pagina Web al browser Web in una risposta HTTP. Di seguito è riportato un esempio di impostazione di un cookie di sessione utilizzando l' intestazione Set-Cookie :

HTTP/2.0 200 OK

Banner

Content-Type: text/html

Set-Cookie: sessionid=QmFieWxvbiA1

Il cookie di sessione precedente non è protetto e può essere rubato in un attacco XSS. Tuttavia, se il cookie di sessione è impostato come segue, è protetto dall'accesso tramite JavaScript:

Set-Cookie: sessionid=QmFieWxvbiA1; HttpOnly

Come impostare HttpOnly lato server?

Tutti i linguaggi e gli ambienti back-end moderni supportano l'impostazione del flag HttpOnly . Ecco un esempio di come puoi farlo in PHP usando la funzione setcookie :

setcookie("sessionid", "QmFieWxvbiA1", ['httponly' => true]);

L'ultimo valore ( true ) rappresenta l'impostazione dell'attributo HttpOnly .

Altri flag per i cookie protetti

Il flag HttpOnly non è l'unico flag che puoi utilizzare per proteggere i tuoi cookie. Eccone altri due che possono essere utili.

La bandiera sicura

Il flag Secure viene utilizzato per dichiarare che il cookie può essere trasmesso solo utilizzando una connessione sicura (SSL / HTTPS). Se questo cookie è impostato, il browser non invierà mai il cookie se la connessione è HTTP. Questo flag impedisce il furto di cookie tramite attacchi man-in-the-middle.

Tieni presente che questo flag può essere impostato solo durante una connessione HTTPS. Se è impostato durante una connessione HTTP, il browser lo ignora.

Esempio:

Set-Cookie: sessionid=QmFieWxvbiA1; HttpOnly; Secure

Esempio di impostazione del cookie sopra in PHP:

setcookie("sessionid", "QmFieWxvbiA1", ['httponly' => true, 'secure' => true]);

La bandiera SameSite

Il flag SameSite viene utilizzato per dichiarare quando i browser web devono inviare il cookie, a seconda di come un visitatore interagisce con il sito che ha impostato il cookie. Questo flag viene utilizzato per proteggere dagli attacchi CSRF (Cross-Site Request Forgery).

L' attributo SameSite può avere uno dei seguenti valori:

  • SameSite=Strict: Il cookie viene inviato solo se sei attualmente sul sito per cui il cookie è impostato. Se ci si trova su un sito diverso e si fa clic su un collegamento a un sito per il quale è impostato il cookie, il cookie nonviene inviato con la prima richiesta.
  • SameSite=Lax: Il cookie nonviene inviato per il contenuto incorporato ma viene inviato se si fa clic su un collegamento a un sito per il quale è impostato il cookie. Viene inviato solo con tipi di richiesta sicura che non cambiano stato, ad esempio, GET.
  • SameSite=None: Il cookie viene inviato anche per i contenuti incorporati.

Browser diversi si comportano in modo diverso per impostazione predefinita quando l' attributo SameSite non è impostato. Ad esempio, nel 2019 il browser Google Chrome ha cambiato il suo comportamento predefinito per i cookie SameSite.

Esempio:

Set-Cookie: sessionid=QmFieWxvbiA1; HttpOnly; Secure; SameSite=Strict

Esempio di impostazione del cookie sopra in PHP:

setcookie("sessionid", "QmFieWxvbiA1", ['httponly' => true, 'secure' => true, 'samesite'=>'Strict']);

I flag dei cookie sono sufficienti contro XSS?

Anche se i flag dei cookie sono efficaci per molti attacchi, non possono essere utilizzati come rimedio per lo scripting tra siti. Gli aggressori possono escogitare modi per aggirare le limitazioni. Ad esempio, esegui attacchi CST (cross-site tracing) e ruba anche i cookie protetti da flag come HttpOnly .

L'unico modo efficace per proteggersi dallo scripting cross-site è trovare tali vulnerabilità nell'applicazione ed eliminarle alla fonte. E l'unico modo efficace per trovare tali vulnerabilità è eseguire test di penetrazione manuali e / o utilizzare uno scanner di vulnerabilità automatizzato .

 


Articoli su Acunetix

In che misura le aziende gestiscono la sicurezza delle applicazioni Web?Il flag HttpOnly: protezione dei cookie da XSSIl Bug Heartbleed – I vecchi Bug sono duri a morireErrori di configurazione della sicurezza e conseguenze per la sicurezza webCross-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!

Knowledge Base su Acunetix

Il Pen Testing applicativo con Acunetix
Ripe Ncc Member
vmware
CloudLinux
Plesk
HP
Microsoft