Core Web Vitals: cosa sono a cosa servono e come si misurano

Ti sarà sicuramente capitato di navigare su di un sito inusabile a causa degli infiniti tempi di caricamento e della quantità smodata di banner di ogni sorta. Esperienza terribile.

Proprio l’esperienza di navigazione dell’utente sta per diventare uno dei fattori con cui Google deciderà l’ordinamento dei risultati del motore di ricerca.

Nella pagina about di Google si legge che lo scopo fondamentale del motore di ricerca è:

La nostra missione è organizzare le informazioni a livello mondiale e renderle universalmente accessibili e utili.

https://about.google

Organizzare le informazioni a livello mondiale significa trovare e catalogare tutte le pagine web esistenti in modo da fornire i migliori risultati possibili sulla base delle parole chiave digitate dall’utente.

Ma Google non si limita a classificare i risultati solamente in base al contenuto. Immagina di cercare una parola chiave come “miglior software gestionale per hotel” su Google.

Ti sei mai chiesto come faccia il motore di ricerca a decidere l’ordinamento con cui sono mostrati i risultati quando tutte le pagine hanno contenuti più o meno simili tra loro? Al fine di fornire anche in queste situazione i migliori risultati possibili, Google dichiara di tenere in considerazione oltre 100 fattori differenti!

E tra i fattori presi in considerazione, a partire dalla prima metà del 2021, uno che guadagnerà maggiore importanza nella definizione dell’ordinamento dei risultati di Google sarà proprio la così detta Page Experience. Proprio per misurare in maniera oggettiva la qualità di navigazione di un sito web Google aveva introdotto qualche anno fa i segnali Core Web Vitals. Nei prossimi mesi questi indicatori verranno inclusi all’interno del punteggio della Page Experience e da Maggio 2021 diventeranno un fattore di ranking a tutti gli effetti.

Questo vuol dire che a parità di contenuto un sito pulito, veloce a caricarsi e di facile consultazione verrà favorito rispetto ad un sito lento, pesante e complesso da usare.

NOTA: Chi si intende di ottimizzazione per i motori di ricerca conosce benissimo il motto “content is king” che sta a significare che il contenuto informativo il vero motivo per cui gli utenti aprono un sito. Questo motto continuerà ad essere valido anche con l’avvento dei Core Web Vitals tra i fattori di ranking. Un sito con il contenuto confuso e sgrammaticato ma con segnali Vitals al top continuerà ad essere penalizzato rispetto ad un sito con contenuto di qualità ma scarse performance.

Ma prima di trattare nel dettaglio dei Core Web Vitals mi presento: sono Lorenzo Millucci e sono un ingegnere del software che ama lavorare con Symfony e a cui piace condividere in questo blog le cose che impara. Non perderti anche il mio canale Telegram in cui ogni martedì parliamo di news e curiosità legate al mondo della tecnologia!


Indice


Cosa sono i segnali Core Web Vitals

I segnali Core Web Vitals sono degli indicatori che servono a rispondere alla domanda: “Qual’è l’esperienza di navigazione che il mio sito sta offrendo?”.

Secondo Google i concetti su cui si basa una navigazione di qualità sono tre:

  • Velocità: la navigazione deve avvenire senza la necessità di attendere tempi infiniti di caricamento tra una pagina e l’altra;
  • Interattività: una volta che il contenuto è stato mostrato a schermo l’utente non deve attendere un’infinità di tempo prima di poter interagire con la pagina;
  • Stabilità visuale: il contenuto della pagina non deve subire spostamenti mano a mano che i contenuti vengono caricati (es. viene caricato un banner pubblicitario che fa si che il testo venga scrollato più giù nella pagina).

Questi concetti possono essere misurati utilizzando rispettivamente le seguenti metriche:

  • Largest Contentful Paint (LCP): il caricamento dovrebbe avvenire entro 2.5s
  • First Input Delay (FID): dovrebbe essere possibile interagire con la pagina entro 100ms dal caricamento
  • Cumulative Layout Shift (CLS): il punteggio relativo alla stabilità non dovrebbe essere superiore a 0.1

I report di Google mostrano come un sito che soddisfi a pieno i requisiti di qualità appena definiti abbia un tasso di abbandono più basso del 24% rispetto ad uno sito che non li rispetta.

Misurare i Core Web Vitals

Ora che hai capito le motivazioni che hanno spinto Google ad introdurre i Core Web Vitals come indicatore dell’esperienza di navigazione percepita dall’utente vediamo come misurarli praticamente.

Una prima importante differenziazione da fare nella misura dei segnali Vitals è la distinzione tra “dati sul campo” e “dati sintetici”. I primi sono i dati raccolti da Google tramite l’analisi dei visitatori reali del sito web mentre i secondi sono dati ottenuti in laboratorio simulando quello che potrebbe essere il comportamento dell’utente nel sito.

Google (ovviamente) utilizza i dati sul campo per determinare l’ordinamento dei risultati di ricerca e ti farò vedere non sono facilmente accessibili. I dati sintetici invece possono essere generati facilmente e sono utilizzati principalmente dagli sviluppatori per individuare quali possono a cui gli utenti vanno incontro.

Google offre diversi strumenti per la misura dei Core Web Vitals che coprono diversi aspetti dello stesso problema e in particolare gli strumenti più usati sono:

  • Google Search Console
  • PageSpeed Insight
  • Lighthouse
I 3 strumenti più utilizzati per la misurazione dei segnali Core Web Vitals

Search Console

La Search Console è un servizio di Google dedicato ai webmaster con il quale è possibile monitorare e gestire la presenza del tuo sito nei risultati della ricerca Google.

Tra i vari report che è possibile consultare nella Search Console ne puoi trovare proprio uno dedicato interamente ai segnali Core Web Vitals.

Il report sui segnali web essenziali di Google Search Console

Il report della Search Console mostra i “dati sul campo” ed è ottimo per individuare rapidamente i problemi comuni a più pagine del sito visto che tutte le pagine con problematiche simili vengono raggruppate insieme. Ad esempio, se più pagine del sito hanno un layout comune con una grossa immagine in copertina, è molto probabile che il loro punteggio circa il Largest Contentful Paint (LCP) sia simile. In questi casi il report di Google segnalerà un eventuale problema su tutte le pagine.

Per farla breve la Google Search Console è lo strumento giusto da utilizzare per identificare eventuali problemi di performance a livello globale del sito. Lo svantaggio principale però della Console è che ogni punto del grafico è la media dei punteggi alle performance dei 28 giorni precedenti. Questo vuol dire che un miglioramento fatto oggi non sarà visibili nel report prima di un mese.

PageSpeed Insights (PSI)

PageSpeed Insight è un applicativo web di Google che permette di vedere nella stessa pagina sia i dati sul campo (se disponibili) che quelli sintetici. Tutto ciò che devi fare per ottenere il report di PageSpeed Insight è inserire l’URL della pagina da analizzare nell’applicazione e premere invio.

L’analisi del punteggio di questo blog da desktop secondo PageSpeed Insight

L’analisi svolta da questo strumento è relativa al singolo URL specificato e solo nel caso in cui la pagina sia frequentata da un numero sufficientemente alto di visitatori è possibile vedere i dati raccolti sul campo, altrimenti saranno mostrati solo dei dati sintetici raccolti tramite test automatici.

All’interno della pagina dei risultati dell’analisi sono presenti anche dei consigli relativi alle aree su cui concentrare l’attenzione per migliorare il punteggio della pagina. (Attenzione si tratta di suggerimenti ottenuti dal test sintetico eseguito sulla pagina, gli utenti reali potrebbero riscontrare problematiche differenti).

In breve, tramite l’analisi della PageSpeed Insight è possibile analizzare con precisione i dati reali delle performance misurate dai visualizzatori del sito per una determinata pagina.

L’obiettivo di questo strumento dovrebbe essere quello di mettere a confronto i dati reali con quelli sintetici così da vedere se c’è un’effettiva corrispondenza in modo da scongiurare l’ipotesi per cui i dati sintetici siano migliori di quelli effettivamente riscontrati dagli utenti.

Il problema principale di questo report è che se la pagina da analizzare non è sufficientemente trafficata otterrai solo i dati sintetici (misurati tramite Lighthouse).

Lighthouse

Lighthouse è uno strumento automatico di analisi dei siti web incluso all’interno di Chrome (o anche il nuovo Edge basato su Chromium).

Questo strumento è principalmente rivolto agli sviluppatori e ha come finalità la raccolta di dati sintetici sulle performance di un sito.

Lighthouse in particolare permette di ricavare vari report:

  • Performance del sito: è il report che contiene le metriche legate alle prestazioni (tra cui i Core Web Vitals) ed è in grado di fornire agli sviluppatori vari suggerimenti sulle aree in cui intervenire per migliorare l’esperienza dell’utente.
  • Progressive Web App: questo report è rilevante solo nel caso in cui abbinata al sito ci sia una PWA e serve ad identificare se il sito web aderisce a tutti gli standard richiesti ad una PWA.
  • Best Practices: questo report si concentra sugli aspetti legati alla sicurezza e sugli aspetti legati ai moderni standard di sviluppo web.
  • Accessibilità: questo report serve ad individuare eventuali problematiche che possano rendere la pagina web inutilizzabile da persone con disabilità.
  • SEO: in questo report è indicato quanto la pagina web è facile da scansionare per un motore di ricerca (non solo Google). Più il punteggio è alto e più sarà facile che la pagina venga indicizzata e compaia come risultato della ricerca di un utente.
Punteggio relativo alle performance misurato da Lighthouse su dev.to (in rosso ho evidenziato i Core Vitals)

La navigazione web in questi anni si sta spostando sempre più dai PC verso i dispositivi mobili come smartphone e tablet.

Google è ampiamente a conoscenza di questo fenomeno e proprio per questo motivo tiene in particolare considerazione questa categoria di dispositivi permettendo a Lighthouse di simulare l’esperienza utente da uno smartphone.

La navigazione da smartphone però non è sempre ottimale. Dispositivi dalla scarsa potenza di calcolo e connessioni lente e/o ballerine sono molto più comuni di quanto si pensi. Per tenere conto di queste situazionivo Lighthouse simula uno smartphone che non sia un top di gamma (Moto G4) e che sia sotto una connessione lenta (slow 4G = 1.6Mbps download / 750 Kbps upload – latenza 150ms).
Proprio a causa di questa scelta il sito web che si carica in un lampo nel tuo iPhone 12 Pro potrebbe ottenere un punteggio delle performance basso (per verificare questa ipotesi il test da eseguire è quello della PageSpeed Insight).

Il ragionamento che ha spinto Google ad percorrere questa strada è il seguente: se la pagina web ha performance buone su un dispositivo limitato sicuramente sarà un piacere consultarla su di un cellulare di ultima generazione.

Il modo più semplice per misurare i segnali Core Web Vitals tramite Lighthouse è utilizzarlo direttamente da Chrome usando i seguenti comandi:

  • Naviga sulla pagina per cui vuoi misurare le performance
  • Apri gli strumenti per sviluppatori usando F12 (o utilizzando ctrl+shift+I)
  • Seleziona dalle tab in alto il menù Lighthouse
  • Metti la spunta sulla voce “Performance” (e rimuovere le altre se non sei interessato agli altri report)
  • Seleziona mobile o desktop per decidere se quale report vuoi ottenere
  • Avvia il test tramite il bottone “Genera Report”

Al termine dell’analisi del sito verrà mostrato un voto complessivo del sito e sarà possibile analizzare nel dettaglio tutte le voci che concorrono alla determinazione del punteggio. Per sapere come sono combinate tra loro le voci per il calcolo del punteggio complessivo ti lascio la documentazione ufficiale di Google.

Nel momento in cui scrivo Lighthouse 6 utilizza questi pesi per mediare le metriche e determinare il punteggio complessivo

Il report è diviso in due sezioni: metrics e opportunities. I valori delle metriche sono quelli che vanno ad influire direttamente sul punteggio globale assegnato alle performance mentre le opportunità non incidono direttamente. In ogni caso aggiustare una delle problematiche segnalate nella sezione opportunità può avere un impatto sul valore di una delle metriche e quindi contribuire ad aumentare il punteggio globale.

Analizzando i le voci contenute nella sezione metriche è possibile individuare i valori dei Core Web Vitals:

  • Largest Contentful Paint
  • Cumulative Layout Shift
  • Total Blocking Time (che non è esattamente il First Input Delay ma lo approssima con buona precisione).

Conclusione

L’ottimizzazione dei siti web per i motori di ricerca (SEO) non è una scienza esatta. Gli algoritmi usati dai motori di ricerca cambiano continuamente e quello che è valido oggi potrebbe non essere più valido domani. L’unica cosa certa è che ci sono dei principi generici a cui i motori di ricerca si ispirano costantemente. Tra questi principi fondamentali uno che nel 2021 acquisirà maggiore importanza sarà proprio la valutazione delle performance del sito misurata tramite i segnali Core Web Vitals.

Google ha avvisato con largo anticipo che il cambiamento avverrà intorno al mese di Maggio in modo da dare tempo a chiunque gestisca un sito di iniziare a valutarne le performance e ad apportare i cambiamenti necessari. Chi non si adegua in tempo vedrà soffiarsi il primo posto nei risultati di ricerca da i competitor.

Come ho accennato poco fa, Google non fornisce delle regole esatte ma solo dei principi a cui si ispira per questo motivo quello che è scritto in questo post potrebbe essere aggiustato e modificato da Google in ogni momento. Per tale motivo ho cercato di mettere sempre i link alla documentazione ufficiale in modo da poter risalire sempre alla fonte di ogni dato riportato nel post.


Se questo post ti è stato utile puoi farmelo sapere lasciando un commento qui sotto oppure scrivendomi direttamente a t.me/lorenzomillucci.
Inoltre ti invito ad iscriverti al mio canale Telegram e a seguirmi su Twitter per non perderti nemmeno un post del mio blog. A presto!

Software engineer presso Slope.
Appassionato di videogame, nel tempo libero mi diletto a scrivere su questo blog.
Per non perderti nemmeno un post puoi seguirmi su Telegram!

Responsible disclosure: SQL Injection su portale sanitario

Hero image: ho trovato una sql injection in un portale sanitario

I dati sanitari delle persone dovrebbero essere tra i segreti meglio custoditi al mondo visto che la loro divulgazione senza esplicito consenso risulterebbe in una gravissima violazione della privacy dei pazienti. Non a caso ogni singolo dato sanitario ottenuto può valere fino a 250$ nel mercato nero .

Proprio per questo motivo mi aspetto che gli applicativi software che trattano questi dati siano protetti seguendo i più alti standard di sicurezza informatica esistenti.

Immaginate il mio stupore quando mi sono accorto che uno dei portali web utilizzati dai medici per il controllo dei proprio assistiti era vulnerabile a quello che OWASP mette al primo posto come fattore di rischio per le web app: la SQL Injection.

Per chi non sapesse di che cosa parlo, tramite un attacco di tipo SQL Injection un attaccante è in grado di eseguire dei comandi in linguaggio SQL con i quali può leggere, alterare ed eliminare qualsiasi dato presente all’interno di un database.

Non oso nemmeno immaginare le conseguenze disastrose che avrebbe potuto avere l’accesso e la divulgazione non consentita dei dati anagrafici e dei percorsi sanitari di migliaia e migliaia di pazienti.

Ma prima di procedere con i dettagli della SQL Injection mi presento: sono Lorenzo Millucci e sono un ingegnere del software che ama lavorare con Symfony e a cui piace condividere in questo blog le cose che impara. Iscriviti anche al mio canale Telegram in cui ogni martedì parliamo di piccole curiosità legate al mondo della tecnologia!

Cos’è una SQL Injection

Un attacco di tipo SQL Injection è un attacco che sfrutta la mancata validazione degli input digitati dall’utente per fare in modo che questi vengano interpretati come comandi per il database al fine di introdursi in un sistema informatico.

SQL infatti è un linguaggio di programmazione utilizzato per creare, modificare ed interrogare un database relazionale.

Normalmente quando un utente prova ad inserire un’istruzione SQL all’interno di un campo di input (come potrebbe esserlo il campo username di una pagina di login) il sistema si occupa di validare i dati inseriti accertandosi che non ci siano caratteri illeciti e/o facendone la traslitterazione verso una versione non dannosa (ad esempio il carattere < di solito viene convertito in &lt;).

Se questo processo di validazione dei dati immessi dall’utente non avviene potrebbe essere possibile sferrare un attacco di tra quelli appartenenti alla famiglia delle injection (a cui la SQL Injection appartiene).

Il tipico esempio di SQL Injection riportato in tutti i libri di testo è quello di una schermata di login in cui, per verificare che username e password siano corretti, viene usata la seguente query:

SELECT * FROM users WHERE username = "Foo" AND password = "bar" 

Un attaccante potrebbe aggirare questa schermata di login digitando come username Foo e come password " OR "" = ". In questo modo la query con i dati inseriti dall’utente diventerebbe:

SELECT * FROM users WHERE username = "Foo" AND password = "" OR "" = "" 

E poiché l’uguaglianza tra stringhe vuote "" = "" risulta essere sempre verificata l’attaccante si vedrebbe garantito l’accesso al sistema come un regolare utente senza che sia stato necessario conoscerne la password.

La SQL Injection sul portale

Esattamente come nell’esempio descritto poco sopra, nel portale in questione era possibile aggirare la pagina di login confezionando una stringa SQL ad-hoc e usandola come nome utente.

Per verificare l’esistenza del problema mi è bastato inserire il carattere ' nel campo username della pagina di login ottenendo come risposta la query SQL che il server ha provato ad eseguire per verificare la correttezza delle credenziali inserite.

Il messaggio d’errore restituito inserendo il carattere ‘ come username

Una volta accertata l’esistenza del problema mi sono immediatamente preoccupato di contattare chi di dovere affinché approntasse un fix per la vulnerabilità.

Timeline

20/10/2020 Mi accorgo del problema sul portale

20/10/2020 Invio email all’indirizzo di supporto generico (mai risposta)

26/10/2020 Invio email al dirigente del reparto IT che mi mette in contatto con il tecnico incaricato del portale

28/10/2020 Riporto la vulnerabilità al tecnico responsabile

11/11/2020 Mi segnalano che la vulnerabilità è stata sistemata

Conclusioni

Il problema sembra essere stato corretto e ora quando si prova ad inserire il carattere ' all’interno dei campi di login non viene più visualizzata la query SQL eseguita ma viene mostrata una semplice pagina bianca. Tutto bene quel che finisce bene.

O no?

Sinceramente ho l’impressione che il problema sia stato “risolto” semplicemente nascondendo il messaggio d’errore e lasciando la vulnerabilità esattamente dove si trova ma siccome non sono in grado di dimostrare questa mia ipotesi confido nella bontà della correzione. Avrei dormito sogni tranquilli vedendo un messaggio d’errore generico del tipo “nome utente non valido” piuttosto che una pagina bianca.

In ogni caso, vista la natura estremamente sensibile dei dati sanitari, mi auguro che le istituzioni incaricate al controllo e alla gestione di questi dati si impegnino maggiormente a garantire i più alti standard di sicurezza possibili.


Se questo post ti è stato utile puoi farmelo sapere lasciando un commento qui sotto oppure scrivendomi direttamente a t.me/lorenzomillucci.
Inoltre ti invito ad iscriverti al mio canale Telegram e a seguirmi su Twitter per non perderti nemmeno un post del mio blog. A presto!

Software engineer presso Slope.
Appassionato di videogame, nel tempo libero mi diletto a scrivere su questo blog.
Per non perderti nemmeno un post puoi seguirmi su Telegram!

Responsible disclosure: esposizione della cartella .git su di un sito di comparazione prezzi

responsible disclosure

Era un normalissimo Lunedì mattina. Come sempre, prima di iniziare a lavorare, stavo facendo una navigata sul web. Ero appena entrato sul sito di una compagnia di comparazione prezzi quando una notifica del browser cattura la mia attenzione: Found an exposed .git.

L’estensione del browser che utilizzo per verificare automaticamente se un sito web ha la cartella /.git esposta ne aveva appena beccato uno.

Ops, ho appena trovato una cartella .git pubblicamente accessibile

Se non sei uno sviluppatore ti starai chiedendo: “è quindi”? Se invece conosci Git sai già quanto possa essere potenzialmente grave avere la cartella .git pubblicamente accessibile.

Infatti attraverso l’accesso a quella cartella sono riuscito ad estrapolare le chiavi di accesso al database!

A livello puramente teorico, in assenza di ulteriori meccanismi di protezione, ottenere credenziali del genere potrebbe garantire ad un malintenzionato l’accesso in lettura e scrittura ai dati di tutti gli utenti della piattaforma (username, hash di password, ecc…).

Ma prima di vedere nel dettaglio che strumenti ho usato per accorgermi della vulnerabilità e come è andata a finire la storia lasciami presentare. Io sono Lorenzo Millucci e sono un ingegnere del software che ama lavorare con Symfony e a cui piace condividere in questo blog le cose che impara. Iscriviti al mio canale Telegram per non perderti nessuna notizia!

Cos’è Git?

Andiamo con ordine. La prima cosa che ti serve sapere per capire quale sia stato il problema di sicurezza è capire cosa sia Git e perché avere accesso a quella cartella è un problema di sicurezza.

Git è un popolarissimo software utilizzato dagli sviluppatori per tracciare le modifiche del codice sorgente (versionamento) creato da Linus Torvalds (il creatore di Linux) nel 2003.

Per tracciare tutti i cambiamenti all’interno di una codbase, Git mantiene tutti i (meta-)dati necessari all’interno di una cartella nascosta chiamata .git.

Normalmente Git è uno strumento utilizzato esclusivamente internamente ai team di sviluppo e i meta-dati che produce non sono accessibili pubblicamente. Può però capitare che a causa di una dimenticanza o di una cattiva configurazione del server questa cartella non venga opportunamente protetta e che sia quindi leggibile da chiunque.

Avendo accesso alla cartella .git è possibile estrapolare diverse informazioni sensibili sul sito web semplicemente guardando i file in essa contenuti:

  • .git/config: è il file di testo utilizzato da git per tracciare le informazioni generali sul repository (es. l’URL del server con il repository, l’username, le branch attive… )
  • .git/index: è il file contente l’indice di tutti i file presenti nel repository e di tutte le modifiche fatte. Il file è in formato binario ma esistono dei tool appositi in grado di leggerne il contenuto.
  • .git/objects: è la cartella che contiene tutte i file del progetto. Tutti i file sono salvati senza estensione e utilizzando l’hash SHA1 come file name. E’ da questa cartella che è possibile estrapolare dati sensibili del sito web.

Come mi accorgo di una cartella .git esposta pubblicamente?

Ora che hai capito cos’è Git ti chiederai come si fa a verificare se la cartella .git è pubblicamente accessibile su una web-app.

Il metodo più semplice (e più macchinoso) per verificare se una cartella .git è esposta pubblicamente è quello di provare a modificare l’URL della pagina aggiungendo di volta in volta il percorso alla cartella .git nel seguente modo:

  • https://example.com/.git/config
  • https://example.com/.git/HEAD
  • https://example.com/.git/logs/HEAD
  • https://example.com/.git/index

Siccome farlo manualmente è una scocciatura è possibile scaricare un estensione del browser (per Firefox e Chrome) chiamata DotGit che permette di effettuare la verifica automaticamente. Nel caso in cui i file sono pubblicamente accessibili l’estensione lo farà presente immediatamente con una notifica.

Che ci faccio con la cartella .git?

Ora arriva la parte divertente. Una volta che ho trovato una cartella Git esposta tutto quello che devo fare è utilizzare un software chiamato GitTools per scaricare ed estrarre automaticamente tutto il codice lasciato incustodito.

Per scaricare il contenuto della cartella .git basta dare il comando:

./Dumper/gitdumper.sh https://example.com/.git/ /output-directory/

Siccome spesso i repository vengono compressi può succedere che i dati scaricati non siano immediatamente leggibili. Proprio per questa evenienza i GitTools mettono a disposizione un altro strumento che permette di carpire quanta più informazione possibile dal repository scaricato.
Per usare questo strumento il comando da utilizzare è:

 ./Extractor/extractor.sh /output-directory/ /output-directory-extracted/

Una volta che il tool avrà finito di estrarre il contenuto della cartella sarà possibile esplorare il codice sorgente. A seconda dell’applicazione web è possibile cercare all’interno del codice chiavi di accesso, credenziali hardcodate, nuovi endpoint segreti, ecc…

Disclosure

Ma ritorniamo a Lunedì mattina. Avevo appena ricevuto la notifica da parte di DotGit. Ero abbastanza stupito che un sito così famoso avesse potuto commettere un errore tanto banale senza che nessuno se ne accorgesse.

Così ho provato a vedere cosa ci fosse all’interno del repository utilizzando i GitTools e mi sono accorto che tra i file c’era il file di configurazione .env contenete le chiavi di accesso ai vari database del sito.

Uno dei “pericolosi” file che contengono le chiavi di accesso ai database. Naturalmente ho oscurato i dati sensibili

Io non ho provato a connettermi ai vari database del sito visto che il mio interesse era puramente “accademico” e visto che molto probabilmente sono protetti da ulteriori meccanismi di protezione. Tutto quello che ho fatto è stato segnalare la vulnerabilità al supporto tecnico del sito che si è rivelato svelto a rispondermi e a risolvere il problema.

Timeline

  • Lunedì 22/06/2020 navigando prima di attaccare al lavoro mi accorgo della vulnerabilità;
  • Lunedì 22/06/2020 11:24 contatto il supporto del sito per segnalare la vulnerabilità;
  • Lunedì 22/06/2020 13:05 mi risponde il responsabile tecnico del sito;
  • Lunedì 22/06/2020 13:17 segnalo il problema al responsabile;
  • Lunedì 22/06/2020 15:21 il supporto mi segnala che il problema è stato risolto.

Conclusioni

Alla fine tutto bene quel che finisce bene. Sfortunatamente il problema di lasciare cartelle .git esposte è più comune di quanto si pensi. Tanto è vero che anche OWASP (il progetto che ha come scopo la sicurezza delle applicazioni web) lo inserisce tra i requisiti da verificare per garantire la protezione da accessi indesiderati ai siti web.

In ogni caso l’assistenza si è dimostrata rapida ed efficace nel risolvere il problema e mi piace pensare che ora il web sia diventato un po’ più sicuro anche per merito mio.

Nonostante il problema sia stato gestito e risolto in maniera impeccabile l’azienda in questione mi ha chiesto di non divulgare il suo nome e di conseguenza non è riportato da nessuna parte nell’articolo.


Se questo post ti è stato utile puoi farmelo sapere lasciando un commento qui sotto oppure scrivendomi direttamente a t.me/lorenzomillucci.
Inoltre ti invito ad iscriverti al mio canale Telegram e a seguirmi su Twitter per non perderti nemmeno un post del mio blog. A presto!

Software engineer presso Slope.
Appassionato di videogame, nel tempo libero mi diletto a scrivere su questo blog.
Per non perderti nemmeno un post puoi seguirmi su Telegram!