Audit di sicurezza per applicazioni web e negozi online

Testiamo applicazioni web, API e negozi WordPress o WooCommerce come farebbe un attaccante, esaminiamo il codice e la configurazione del server e vi consegniamo un report che dice cosa correggere per primo. Dopo le correzioni testiamo di nuovo. Lavoriamo solo con l’autorizzazione scritta del proprietario del sistema.

Quando un audit vale la pena

I problemi di sicurezza raramente si annunciano. Di solito un audit nasce da un cambiamento: un lancio, un’uscita dal team, una domanda di un partner.

Uno sviluppatore se n'è andato, e non siete sicuri di quali chiavi e accessi abbia portato con sé
Il prodotto sta per essere lanciato, e nessuno l'ha guardato con gli occhi di un attaccante
Un partner, un investitore o un cliente corporate chiede la prova che la piattaforma è stata testata
Il negozio gira su decine di plugin, e per uno di questi è appena stata pubblicata una vulnerabilità
Il prodotto è costruito su un vecchio framework che nessuno nel team vuole toccare
Avete corretto i problemi di un audit precedente e vi serve qualcuno che confermi che sono chiusi

Cosa controlliamo

Test delle applicazioni web

Test manuali dell’applicazione e della sua logica di business: controllo degli accessi, gestione degli input, caricamento di file, sessioni e i flussi in cui passano denaro o dati personali.

API e autenticazione

Login, reset della password, token e gestione dei JWT, ruoli e permessi. Verifichiamo se un utente può raggiungere i dati di un altro cambiando un ID in una richiesta.

WordPress e WooCommerce

Plugin e temi con vulnerabilità note, accesso all’amministrazione, file e configurazioni esposti, e logica del checkout come prezzi, coupon e cambi di stato degli ordini.

Revisione del codice per la sicurezza

Leggiamo il codice e la sua cronologia alla ricerca di segreti nel repository, query non sicure, controlli mancanti e librerie obsolete, anche su stack legacy che nessuno esamina da anni.

Hardening dei server

Regole SSH e firewall, porte aperte, TLS, header di sicurezza, permessi di database e file, backup conservati lontano dal server e una protezione dal brute force che non blocca il vostro stesso ufficio.

Nuovo test

Dopo che il vostro team o il nostro ha corretto i problemi, testiamo di nuovo ciascuno di essi e aggiorniamo il report con il relativo stato.

Cosa non facciamo

Queste regole fanno parte di ogni accordo e non sono negoziabili.

Non testiamo alcun sistema senza l'autorizzazione scritta del suo proprietario
Non eseguiamo test di carico o di denial of service in produzione senza un accordo separato
Non condividiamo i risultati con nessuno al di fuori dei referenti indicati nell'accordo
Non conserviamo i vostri dati né gli account di test al termine del lavoro

Un report che dice cosa correggere per primo

Un elenco di duecento avvisi di uno scanner non aiuta un team a decidere cosa fare lunedì. Il nostro report valuta la gravità di ogni vulnerabilità con CVSS, mostra le prove, come la richiesta e la risposta che dimostrano il problema, spiega come riprodurlo e indica come correggerlo. Il titolare riceve un executive summary in linguaggio semplice, e gli sviluppatori un piano di correzione ordinato per rischio e impegno.

Dove si nascondono di solito i problemi gravi

Gli scanner automatici trovano le versioni obsolete. I problemi che permettono a qualcuno di impadronirsi degli account di solito sono altrove: un’API che restituisce l’ordine di un altro cliente quando cambia il numero nella richiesta, una chiave di firma finita nel repository anni fa, una route di amministrazione che controlla il login ma non il ruolo, un checkout che si fida del prezzo inviato dal browser, un file di backup lasciato in una cartella pubblica. Per trovarli serve una persona che legga il codice e provi i flussi a mano, ed è così che testiamo.

Nuovo test e hardening, perché il report non sia la fine

Un audit ripaga solo quando le vulnerabilità vengono chiuse. Dopo le correzioni testiamo di nuovo ogni vulnerabilità e la segniamo come chiusa, parzialmente corretta o ancora aperta. Se volete, le correzioni le fanno direttamente i nostri sviluppatori, e il nostro team server rafforza l’infrastruttura: accesso solo con chiavi, un firewall che espone solo ciò che deve essere pubblico, TLS aggiornato, utenti del database separati con permessi minimi e backup conservati lontano dal server che proteggono.

Come si svolge un audit

Perimetro e autorizzazione

Concordiamo cosa si testa, da dove e quando, e il proprietario del sistema firma un’autorizzazione scritta. Voi fornite gli account di test e, per la revisione del codice, l’accesso al repository.

Test

Mappiamo l’applicazione, la testiamo a mano ed esaminiamo codice e configurazione del server entro il perimetro concordato. Ogni problema critico vi viene segnalato subito, senza aspettare il report.

Report

Ricevete le vulnerabilità valutate con CVSS, le prove, le correzioni, un executive summary e un piano di correzione, e li illustriamo al vostro team.

Correzioni

I vostri sviluppatori o i nostri seguono il piano in ordine di rischio.

Nuovo test

Testiamo di nuovo ogni vulnerabilità ed emettiamo un report aggiornato con lo stato di ciascuna.

Cosa testiamo e secondo quali standard

Standard

Applicazioni

Piattaforme e stack

Infrastruttura

Come lavorare con noi

Audit con nuovo test

Un perimetro fisso: test, report e un nuovo test dopo che il vostro team ha corretto le vulnerabilità.

Audit e correzioni

Testiamo, correggiamo le vulnerabilità nel codice e sul server e confermiamo con un nuovo test.

Revisioni periodiche

Una revisione prima dei rilasci importanti o a cadenza fissa, spesso abbinata alla manutenzione del sito o all’assistenza server.

Recensioni

Trattiamo ogni cliente e il suo progetto con attenzione.

Il team di Revol continua a potenziare le capacità di sviluppo del cliente con un lavoro di alta qualità e un supporto affidabile. Comunica in modo efficace e dimostra una solida comprensione delle esigenze e del business del cliente.

Tomas

CEO (Yukon, Canada)

Il lavoro di Revol ha pienamente soddisfatto le aspettative del cliente. Il loro approccio fresco e la costante disponibilità al supporto si sono rivelati preziosi. Chi cerca un team comunicativo e orientato al cliente per raggiungere i propri obiettivi può affidarsi a loro.

Andrey

CEO, Stellium (USA)

Domande frequenti

Vi serve la nostra autorizzazione scritta?

Sì, sempre. Il proprietario del sistema firma un'autorizzazione che indica perimetro, indirizzi e date. Se il sistema gira presso un provider di hosting o cloud, seguiamo anche le regole di quel provider sui test di sicurezza.

I test manderanno in tilt il nostro sito live?

Concordiamo i limiti in anticipo. Dove possibile testiamo su una copia di staging con lo stesso codice. In produzione usiamo account di test, evitiamo azioni distruttive e non eseguiamo test di carico senza un accordo separato.

In cosa si differenzia da una scansione automatica delle vulnerabilità?

Uno scanner trova versioni note e configurazioni errate comuni, e anche noi usiamo gli scanner. Le vulnerabilità più importanti, come un utente che legge i dati di un altro o un prezzo modificato nel browser, richiedono una persona che capisca l'applicazione e la testi a mano.

Cosa riceviamo esattamente?

Un report con ogni vulnerabilità valutata con CVSS, le prove, i passaggi di riproduzione e la correzione, un executive summary per la direzione e un piano di correzione. Dopo il nuovo test ricevete una versione aggiornata con lo stato di ogni vulnerabilità.

Potete correggere ciò che trovate?

Sì. I nostri sviluppatori possono correggere il codice e il nostro team server può rafforzare l'infrastruttura. Alcuni clienti preferiscono che corregga il proprio team e che noi verifichiamo, e funziona altrettanto bene.

Il nuovo test fa parte dell'audit?

Lo inseriamo nel perimetro fin dall'inizio, perché un audit senza nuovo test vi lascia a indovinare se le correzioni hanno funzionato. Quando avviene dipende da quanto rapidamente vengono fatte le correzioni.

Come trattate i nostri dati e i risultati?

Lavoriamo con un NDA, condividiamo i risultati solo con i referenti indicati nell'accordo ed eliminiamo dati e accessi di test al termine del lavoro. Non pubblichiamo mai dettagli su ciò che troviamo.

È una certificazione?

No. Non siamo un ente di certificazione, e il report non è un certificato di conformità. Può supportare il vostro lavoro sulla conformità e mostra ai partner che chiedono una prova dei test esattamente cosa è stato controllato e come.