Contatta il reparto vendite 800 13.40.41 | Richiedi il Supporto Partner

Articoli

Icona delle News




Esposizione dei dati sensibili: come si verificano le violazioni

Esposizione-dei-dati-sensibili-come-si-verificano-le-violazioni

13/07/21 CoreTech Blog

Il termine esposizione di dati sensibili significa consentire a parti non autorizzate di accedere a informazioni sensibili memorizzate o trasmesse come numeri di carta di credito o password. La maggior parte delle principali violazioni della sicurezza in tutto il mondo comporta una sorta di esposizione dei dati sensibili.

Sfruttare un vettore di attacco come una vulnerabilità web è solo il primo passo che l'aggressore compie. Ulteriori passaggi di solito comportano uno dei tre obiettivi: furto di informazioni sensibili, installazione di software dannoso (ad esempio, per attaccare altri obiettivi o consentire il controllo/spionaggio permanente) o l'escalation verso altri sistemi (dove questa scelta si ripete). Ovviamente, rubare informazioni sensibili come i dati della carta di credito è l'obiettivo più redditizio per l'attaccante e la maggior parte degli attacchi informatici è guidata dal denaro, quindi l'esposizione dei dati sensibili è l'obiettivo di attacco più comune.

Proprio come è possibile creare software con quasi nessuna vulnerabilità, è anche possibile creare software che impedisca all'attaccante di accedere a informazioni sensibili. L'esposizione di dati sensibili è causata da una cattiva progettazione o implementazione di sistemi informatici e software, nonché da un'errata configurazione di tali sistemi e software.

Banner

Definire i dati sensibili

Quando crei un'applicazione web, devi definire chiaramente quali dati consideri sensibili. Mentre alcuni esempi sono ovvi, come numeri di carta di credito, credenziali di autenticazione o cartelle cliniche, altri potrebbero non sembrare così semplici. Anche se un'informazione deve essere visualizzata sullo schermo dall'applicazione, può comunque essere considerata sensibile durante il trasporto e l'archiviazione.

Qualsiasi tipo di dati che possono essere considerati dati personali o dati privati ​​dovrebbe essere considerato sensibile. Ciò significa anche dati come nome e cognome, data di nascita o persino un indirizzo e-mail. I criminali cercano tali dati perché possono correlare le informazioni personali rubate da altre fonti per creare profili per il furto di identità.

Anche tutti i dati relativi ai dati finanziari dovrebbero essere considerati sensibili e questo non significa solo numeri di carta di credito. Ad esempio, anche i numeri di conto bancario, sia interno che IBAN, dovrebbero essere considerati sensibili così come gli eventuali importi delle transazioni.

A seconda del settore in cui opera la tua azienda, alcuni dati potrebbero non solo essere considerati sensibili, ma anche coperti dalle normative di conformità. Assicurati che tutti i dati siano protetti, sia in transito che in deposito, altrimenti perderai la tua conformità.

Vulnerabilità di esposizione ai dati sensibili in transito

La maggior parte dei siti Web e delle applicazioni Web oggigiorno sono accessibili tramite connessioni SSL/TLS sicure. Molti arrivano al punto di imporre tali connessioni utilizzando HTTP strict transport security (HSTS). Di conseguenza, molti progettisti di applicazioni Web pensano che sia sicuro trasmettere informazioni sensibili tra il client e il server utilizzando testo in chiaro.

Questa mentalità è la causa principale dell'esposizione di dati sensibili in transito. Sfortunatamente, nonostante il fatto che SSL/TLS fornisca un alto grado di protezione, ci sono casi in cui è possibile un attacco man-in-the-middle (MITM) sul traffico di rete. Se l'attaccante riesce in qualche modo ad accedere ai dati trasmessi tra l'applicazione web e l'utente, e questi dati includono, ad esempio, numeri di carta di credito o password in chiaro, l'attacco finisce nell'esposizione di dati sensibili.

Pertanto, il modo migliore per proteggere la tua applicazione web dall'esposizione di dati sensibili è non trasmettere mai dati sensibili utilizzando testo in chiaro e utilizzare sempre algoritmi crittografici per proteggerli. Si noti che questi non dovrebbero essere algoritmi crittografici deboli perché l'attaccante potrebbe archiviare i dati intercettati e successivamente tentare di violare la crittografia utilizzando potenti GPU.

Vulnerabilità di esposizione ai dati sensibili nell'archiviazione

Conservare i dati sensibili in modo sicuro è importante quanto trasmetterli in modo sicuro, se non di più. Se un utente malintenzionato sfrutta una vulnerabilità e ottiene l'accesso al tuo sito Web o applicazione Web, ad esempio utilizzando un'iniezione SQL, potrebbe essere in grado di accedere al contenuto dell'intero database. Se nel database vengono archiviate informazioni sensibili senza crittografia, è una perdita garantita.

Quando si archiviano informazioni sensibili, l'utilizzo di algoritmi di crittografia rinomati, sicuri e potenti è ancora più importante che in caso di transito. Un algoritmo debole consentirà all'attaccante di eseguire rapidamente attacchi di forza bruta sui dati crittografati rubati e di decodificare le informazioni originali.

Oltre alla crittografia avanzata del database, alcuni tipi di dati sensibili richiedono una protezione aggiuntiva. Ad esempio, le password crittografate o con hash utilizzando anche gli algoritmi più potenti possono essere facilmente violate se la password stessa è una password debole. Pertanto, evitare le vulnerabilità comuni delle password è importante quanto la crittografia o l'hashing.

Vulnerabilità di esposizione ai dati sensibili nelle e-mail

È scioccante vedere quante aziende e istituzioni dimenticano che la posta elettronica non è un canale sicuro e che i dati sensibili non dovrebbero mai essere trasmessi utilizzando questo mezzo. Le connessioni e-mail tra il client e il server possono essere crittografate, ma le connessioni tra i server vengono generalmente eseguite utilizzando testo normale. Anche il corpo dell'e-mail non è crittografato. E il destinatario dell'e-mail non ha alcun controllo sulla sicurezza con cui il contenuto della sua e-mail viene archiviato o se viene effettivamente distrutto quando l'e-mail viene eliminata lato client.

Se la tua applicazione web invia e-mail, non dovresti mai inviare dati sensibili nelle e-mail e, invece, utilizzare l'applicazione web stessa per presentare o accettare informazioni sensibili. Ad esempio, non dovresti mai inviare una nuova password tramite e-mail e mostrarla invece per l'utente su una pagina web. Inoltre, un'istituzione non dovrebbe mai inviare dati personali e sensibili in chiaro tramite e-mail, che è, purtroppo, il modo in cui lo fanno molte istituzioni governative in molti paesi.

Protezione dei dati sensibili

I dati sensibili sono considerati sufficientemente importanti da OWASP (Open Web Application Security Project) da includerli nella Top 10 di OWASP come categoria separata. Nell'edizione 2017, questa categoria è stata considerata il terzo difetto comune più importante. Riteniamo inoltre che nella prossima OWASP Top 10 del 2021 questa categoria non farà che aumentare di importanza. Pertanto, dovresti prestare molta attenzione a proteggere le tue informazioni sensibili ed evitare l'esposizione di dati sensibili.

Proteggere i tuoi dati sensibili è davvero semplice se utilizzi algoritmi crittografici in transito e in memoria insieme a eventuali misure collaterali come, ad esempio, una corretta gestione delle chiavi (in modo che le tue chiavi siano sicure quanto i dati stessi). In alcuni casi, non è nemmeno necessario trasmettere o archiviare dati crittografati, è possibile utilizzare algoritmi di hash. L'hashing delle password è il modo più efficiente per assicurarsi che le password non vengano mai rubate, sia in transito che in memoria.


Articoli su Sicurezza

La cattiva comunicazione è al centro delle sfide di AppSecImpostazione e raggiungimento degli obiettivi di sicurezza delle applicazioniMetriche di sicurezza informatica per le applicazioni WebCome evitare attacchi alla supply chainPerché la maggior parte delle misure di sicurezza delle applicazioni fallisceVuoi che la tua sicurezza sia costruita su scuse?Cos'è SCA e perché ne hai bisognoLa scansione ad hoc non è sufficienteEsposizione dei dati sensibili: come si verificano le violazioniHai paura dei test di sicurezza nell'SDLC?Vantaggi di Web Asset DiscoveryStrumenti di scansione delle vulnerabilità: perché non open source?Protezione WAF - Ottieni il massimo dal tuo firewall per applicazioni webL'errore di comunicazione è al centro delle sfide di AppSecDebugger remoti come vettore di attaccoDAST è una parte essenziale di un programma completo per la sicurezza delle applicazioniCome difendersi dagli attacchi recenti su Microsoft Exchange5 principali vantaggi dei primi test di sicurezzaTecniche di attacco Denial-of-Service con avvelenamento della cacheQuali principali attacchi web possiamo aspettarci nella nuova top 10 di OWASP?Hack di SolarWindsPillole di Sicurezza | Episodio 38Pillole di Sicurezza | Episodio 37Perché gli sviluppatori evitano la sicurezza e cosa puoi fare al riguardoPillole di Sicurezza | Episodio 36Cos'è l'attacco RUDYCos'è la navigazione forzataCome gli scanner trovano le vulnerabilitàPillole di Sicurezza | Episodio 34Pillole di Sicurezza | Episodio 35Come eseguire il benchmark di uno scanner di vulnerabilità Web?Pillole di Sicurezza | Episodio 33Pillole di Sicurezza | Episodio 325 proposte di vendita comuni sulla sicurezza delle applicazioni web5 motivi per non fare affidamento sui programmi BountyPillole di Sicurezza | Episodio 315 motivi per cui la sicurezza web è importante quanto la sicurezza degli endpointPillole di Sicurezza | Episodio 305 motivi per cui la sicurezza web è importante per evitare il ransomwarePillole di Sicurezza | Episodio 293 motivi per cui DAST è il migliore per la sicurezza delle applicazioni WebPillole di Sicurezza | Episodio 28Pillole di Sicurezza | Episodio 27Pillole di Sicurezza | Episodio 24Pillole di Sicurezza | Episodio 25Pillole di Sicurezza | Episodio 21Pillole di Sicurezza | Episodio 22Pillole di Sicurezza | Episodio 20Pillole di Sicurezza | Episodio 17Il flag HttpOnly: protezione dei cookie da XSSPillole di Sicurezza | Episodio 16Il Bug Heartbleed – I vecchi Bug sono duri a morirePillole di Sicurezza | Episodio 15Pillole di Sicurezza | Episodio 14Pillole di Sicurezza | Episodio 13Pillole di Sicurezza | Episodio 12Pillole di Sicurezza | Episodio 11Pillole di Sicurezza | Episodio 10Sicurezza delle reti: gli hacker puntano CitrixCyber hacking: la Germania chiede l’intervento dell’UESicurezza informatica: Cisco rilascia aggiornamentiOcchio al cryptojacking: malware infiltrato in Docker HubSIGRed: bug di sistema in Windows Server scovato dopo 17 anniPillole di Sicurezza | Episodio 9Summit Live - Disponibili le registrazioni delle live di MonteleoneCriminalità informatica: Schmersal sventa un cyber-attaccoPillole di Sicurezza | Episodio 8Pillole di Sicurezza | Episodio 7Analisi pratica dei rischi per il SysAdmin, DevOps e Dev | Summit LivePillole di Sicurezza | Episodio 6Pillole di Sicurezza | Episodio 5Pillole di Sicurezza | Episodio 4Pillole di Sicurezza | Episodio 3Pillole di Sicurezza | Episodio 2Pillole di Sicurezza | Episodio 1Pillole di Sicurezza | Episodio 23
Ripe Ncc Member
vmware
CloudLinux
Plesk
HP
Microsoft