I 10 migliori tipi di vulnerabilità di sicurezza

I 10 migliori tipi di vulnerabilità di sicurezza
Un difetto non intenzionale o accidentale nel codice software o in qualsiasi sistema che lo rende potenzialmente sfruttabile in termini di accesso agli utenti illegittimi, comportamenti dannosi come virus, trojan, worm o qualsiasi altro malware è chiamata vulnerabilità della sicurezza. L'uso di software che è già stato sfruttato o l'uso di password deboli e predefinite si traduce anche nel rendere il sistema vulnerabile al mondo esterno. Questi tipi di vulnerabilità di sicurezza richiedono patch per impedire agli hacker di utilizzare nuovamente exploit precedentemente usati per ottenere un accesso non autorizzato al sistema. Una vulnerabilità di sicurezza chiamata anche buco di sicurezza o debolezza è un difetto, un bug o un errore nell'implementazione di codice, progetta Intera rete vulnerabile all'attacco. Le persone che saranno infettate includono il proprietario dell'applicazione, gli utenti dell'applicazione e qualsiasi altra persona che si basa su tale applicazione. Diamo un'occhiata ai rischi di sicurezza più pericolosi e comuni per le applicazioni Web.

Sommario

  1. Iniezione del database
  2. Autenticazione rotta
  3. Esposizione ai dati sensibili
  4. Entità esterne XML (XEE)
  5. Controllo di accesso rotto
  6. Econfigurazione della sicurezza
  7. Scripting tramite (XSS)
  8. Deserializzazione insicura
  9. Utilizzo di componenti con vulnerabilità note
  10. Registrazione e monitoraggio insufficienti

Iniezione del database:

In caso di invio di dati non attendibili all'interprete come parte del comando attraverso qualsiasi area che accetta l'ingresso dell'utente i.e input del modulo o qualsiasi altra area di invio dei dati, si verificano difetti di iniezione. Le query dannose dell'attaccante possono indurre l'interprete all'esecuzione di comandi che possono mostrare dati riservati che l'utente non ha alcuna autorizzazione per dare un'occhiata. Ad esempio in un attacco di iniezione SQL, quando l'input del modulo non è correttamente disinfettato, l'attaccante può inserire nel database SQL e accedervi senza autorizzazione, semplicemente inserendo il codice del database SQL dannoso in una forma che si aspetta un testo in chiaro. Qualsiasi tipo di campo che prende l'input dell'utente è iniettabile i.E parametri, variabili di ambiente, tutti i servizi Web, ecc.

L'applicazione è vulnerabile all'attacco di iniezione quando i dati forniti dall'utente non sono sanificati e validati, mediante l'uso di query dinamiche senza fuga con il contesto e l'uso diretto di dati ostili. I difetti di iniezione possono essere facilmente scoperti attraverso l'esame del codice e l'uso di strumenti automatizzati come scanner e fuzzer. Per prevenire gli attacchi di iniezione, esiste una misura che può essere presa come separare i dati da comandi e query, uso di un'API sicura che fornisce un'interfaccia parametrizzata, l'uso della convalida di input sul lato server "White-list" attraverso strumenti come Snort, Escape di caratteri speciali usando la sintassi di fuga specifica, ecc.

Un attacco di iniezione può portare a una massiccia perdita di dati, divulgazione di informazioni riservate, negazione dell'accesso e può persino portare a un'acquisizione completa dell'applicazione. Alcuni controlli SQL come limite possono essere utilizzati per controllare enormi quantità di perdita di dati in caso di attacco. Alcuni tipi di attacchi di iniezione sono attacchi SQL, OS, NOSQL, LDAP Iniezione.

Autenticazione rotta:

Gli aggressori possono accedere agli account utente e possono persino compromettere l'intero sistema host attraverso gli account di amministrazione, utilizzando le vulnerabilità nei sistemi di autenticazione. I difetti di autenticazione consentono all'attaccante di compromettere password, token di sessione, chiavi di autenticazione e possono essere incatenati con altri attacchi che possono portare ad un accesso non autorizzato di qualsiasi altro account utente o sessione temporaneamente e in alcuni casi, permanentemente. Supponiamo che un utente abbia una lista di parole o un dizionario di milioni di nomi utente e password validi ottenuti durante una violazione. Può usarli uno per uno in un tempo estremamente meno utilizzando strumenti e script automatizzati sul sistema di accesso per vedere se qualcuno funziona. Una scarsa implementazione della gestione delle identità e dei controlli di accesso porta a vulnerabilità come l'autenticazione rotta.

L'applicazione è vulnerabile all'attacco di autenticazione quando consente di provare diversi nomi utente e password, consente attacchi di dizionario o attacchi di forza bruta senza alcuna strategia di difesa, utilizzare password o password predefinite facili che sono trapelate in qualsiasi violazione, espone ID sessione nell'URL, usi Schema di recupero della password scadente, utilizza uno schema di cookie. L'autenticazione rotta può essere sfruttata facilmente utilizzando strumenti semplici per attacchi di forconi bruti e dizionario con un buon dizionario. Questi tipi di attacchi possono essere prevenuti utilizzando sistemi di autenticazione multi-fattore, implementando i controlli di password deboli eseguendo una password tramite un database di una password errata, non utilizzando le credenziali predefinite, allineando la politica di complessità della password, mediante l'uso di un buon lato server. Gestione sessione che genera un nuovo ID a sessione casuale dopo l'accesso, ecc.

La vulnerabilità di autenticazione rotta può comportare la compromesso di alcuni account utente e un account amministratore, che è tutto un utente malintenzionato per compromettere un sistema. Questi tipi di attacchi portano a furto di identità, frode di sicurezza sociale, riciclaggio di denaro e divulgazione di informazioni altamente classificate. Gli attacchi includono attacchi di dizionario, forconi bruti, dirottamento della sessione e attacchi di gestione delle sessioni.

Esposizione ai dati sensibili:

A volte le applicazioni Web non proteggono dati e informazioni sensibili come password, credenziali del database, ecc. Un utente malintenzionato può facilmente rubare o modificare queste credenziali debolmente protette e utilizzarle per scopi illegittimi. I dati sensibili devono essere crittografati durante il riposo o in transito e avere un ulteriore livello di sicurezza altrimenti gli aggressori possono rubarli. Gli aggressori possono mettere le mani su dati esposti sensibili e rubare hash o chiarire gli utenti di testo e le credenziali del database dal server o un browser Web. Ad esempio, se un database di password utilizza hash non salati o semplici per archiviare le password, un difetto di caricamento del file può consentire a un utente malintenzionato di recuperare il database delle password che porterà all'esposizione di tutte le password con una tabella Rainbow di hash pre-calcolati.

Il difetto principale non è solo che i dati non siano crittografati, anche se sono crittografati, ma una generazione chiave debole, algoritmi di hashing debole, un uso debole della cifra può anche comportare questo tipo di attacchi più comuni. Per prevenire questi tipi di attacchi, in primo luogo, classifica quale tipo di dati può essere considerato sensibile in base alle leggi sulla privacy e applicare i controlli secondo la classificazione. Cerca di non archiviare dati classificati che non hai bisogno, lavalo non appena li usi. Per i dati in transito, crittografarli con protocolli sicuri i.E TLS con cifre PFS, ecc.

Questi tipi di vulnerabilità possono comportare l'esposizione di informazioni altamente sensibili come credenziali della carta di credito, cartelle cliniche, password e altri dati personali che possono portare a furto di identità e frodi bancarie, ecc.

Entità esterne XML (XEE):

Processori XML scarsamente configurati elabora riferimenti di entità esterna all'interno di documenti XML. Queste entità esterne possono essere utilizzate per recuperare i dati di file interni come /etc/passwd file o per eseguire altre attività dannose. I processori XML vulnerabili possono essere facilmente sfruttati se un utente malintenzionato può caricare un documento XML o includere XML ecc. Queste entità XML vulnerabili possono essere scoperte utilizzando strumenti SAST e DAST o ispezionando dipendenze e configurazioni.

Un'applicazione Web è vulnerabile all'attacco XEE a causa di molte ragioni come se l'applicazione accetta l'input XML diretto da fonti non attendibili, le definizioni del tipo di documento (DTD) sull'applicazione sono abilitate, l'applicazione utilizza SAML per l'elaborazione dell'identità poiché SAML utilizza XML per l'identità inserzioni, ecc. Gli attacchi XEE possono essere mitigati evitando la serializzazione di dati sensibili, utilizzando formati di dati meno complicati i.E JSON, Processori XML patching L'applicazione sta utilizzando e persino le librerie, disabilitando i DTD in tutti i parser XML, convalida della funzionalità di caricamento dei file XML mediante verifica XSD, ecc.

L'applicazione vulnerabile a questi tipi di attacchi può portare ad attacchi DOS, attacco di miliardi di risate, scansione di sistemi interni, scansione delle porte interne, esecuzione di un comando remoto che si traduce nell'influenza di tutti i dati dell'applicazione.

Controllo degli accessi rotti:

L'accesso controlla gli utenti i privilegi per svolgere attività specifiche. La vulnerabilità del controllo degli accessi interrotti avviene quando gli utenti non sono adeguatamente limitati alle attività che possono eseguire. Gli aggressori possono sfruttare questa vulnerabilità che può finire ad accedere a funzionalità o informazioni non autorizzate. Diciamo che un'applicazione Web consente all'utente di modificare l'account da cui viene effettuato l'accesso solo modificando l'URL su Account di un altro utente senza ulteriori verifiche. Sfruttare la vulnerabilità del controllo degli accessi è un attacco di riferimento di qualsiasi utente malintenzionato, questa vulnerabilità può essere trovata manualmente e utilizzando gli strumenti SAFT e DAFT. Queste vulnerabilità esistono a causa della mancanza di test e del rilevamento automatizzato di applicazioni Web, sebbene il modo migliore per trovarle sia farlo manualmente.

Le vulnerabilità contengono i privilegi escalation i.E agendo come utente che non stai o funzioni come amministratore mentre sei un utente, aggirando i controlli di controllo degli accessi semplicemente modificando l'URL o modificando lo stato dell'applicazione, la manipolazione dei metadati, consentendo di modificare la chiave primaria come chiave principale di un altro utente, eccetera. Per prevenire questo tipo di attacchi, i meccanismi di controllo degli accessi devono essere implementati nel codice lato server in cui gli aggressori non possono modificare i controlli di accesso. Applicazione di limiti di attività di applicazione univoci da parte dei modelli di dominio, disabilitazione di directory di server di elenchi, avviso amministratore su ripetuti tentativi di accesso non riusciti, invalidazione di token JWT dopo il logout deve essere assicurato per mitigare questo tipo di attacchi.

Gli aggressori possono agire come un altro utente o amministratore utilizzando questa vulnerabilità per eseguire attività dannose come la creazione, l'eliminazione e la modifica dei record, ecc. Una massiccia perdita di dati può verificarsi se i dati non sono fissati anche dopo una violazione.

Econfigurazione della sicurezza:

La vulnerabilità più comune è la configurazione della sicurezza. Il motivo principale della vulnerabilità è l'uso di configurazione predefinita, configurazione incompleta, configurazioni ADHOC, intestazioni HTTP scarsamente configurate e messaggi di errore verbosio contenenti più informazioni di quanto l'utente avrebbe dovuto effettivamente sapere. A qualsiasi livello di un'applicazione Web, possono verificarsi errate configurazioni di sicurezza.E database, server Web, server delle applicazioni, servizi di rete, ecc. Gli aggressori possono sfruttare sistemi non patch o accedere a file e directory non protetti per avere una sospensione non autorizzata sul sistema. Ad esempio, un'applicazione messaggi di errore eccessivamente verbosio. Strumenti e scanner automatizzati possono essere utilizzati per rilevare questi tipi di difetti di sicurezza.

Un'applicazione Web contiene questo tipo di vulnerabilità se manca le misure di indurimento della sicurezza in qualsiasi parte dell'applicazione, sono aperte porte non necessarie o consente funzionalità non necessarie, vengono utilizzate password predefinite, la gestione degli errori rivela errori informativi per l'attaccante, sta utilizzando software di sicurezza non impacciato o obsoleto, ecc. Può essere impedito rimuovendo le funzionalità non necessarie del codice, i.E una piattaforma minima senza caratteristiche, documentazione, ecc., Consentendo a un'attività di aggiornare e patch dei fori di sicurezza come parte dei processi di gestione delle patch, l'uso di un processo per verificare l'efficacia delle misure di sicurezza adottate, l'uso di un processo di indurito ripetibile per effettuare È facile distribuire un altro ambiente che è adeguatamente bloccato.

Questi tipi di vulnerabilità o difetti consentono all'attaccante di ottenere un accesso non autorizzato ai dati del sistema che porta alla completa compromesso del sistema.

Scripting incrociato (XSS):

Le vulnerabilità XSS si verificano nel punto in cui un'applicazione Web incorpora dati non attendibili in una nuova pagina del sito Web senza un'approvazione o fuga legittima o aggiorna una pagina del sito corrente con dati forniti dal cliente, utilizzando un'API del browser che può rendere HTML o JavaScript. I difetti XSS si verificano nel caso in cui il sito Web consenta a un utente di aggiungere codice personalizzato in un percorso URL che può essere visto da altri utenti. Questi difetti vengono utilizzati per eseguire codice JavaScript dannoso sul browser del bersaglio. Diciamo che un aggressore può inviare un collegamento alla vittima contenente un link al sito Web di qualsiasi azienda. Questa connessione potrebbe avere un codice JavaScript dannoso incorporato in essa, nel caso in cui la pagina web della banca non sia adeguatamente protetta contro gli attacchi XSS, facendo clic sul collegamento, il codice dannoso verrà eseguito sul browser della vittima.

Lo scripting incrociato è una vulnerabilità di sicurezza che è presente in quasi ⅔ delle applicazioni Web. Un'applicazione è vulnerabile a XSS se l'applicazione memorizza un input dell'utente non sinitato che può essere visto da un altro utente, mediante l'uso di strutture JavaScript, applicazioni a pagina singola e API che incorporano con forza le informazioni controllabili degli attaccanti in una pagina sono indifesi contro DOMSS. Gli attacchi di XSS possono essere mitigati dall'uso di framework che sfugge e sanitari input XSS per natura come react js ecc.E negli attributi HTML, URI, JavaScript, ecc., Uso della codifica sensibile al contesto in caso di modifica del documento sul lato client, ecc.

Gli attacchi basati su XSS sono di tre tipi i.e riflesso XSS, DOM XSS e XSS archiviati. Tutti i tipi di questi attacchi hanno un impatto significativo ma nel caso di XSS immagazzinato, l'impatto è ancora più grande i.e rubare le credenziali, inviare malware alla vittima, ecc.

Deserializzazione insicura:

La serializzazione dei dati significa prendere oggetti e convertirli in qualsiasi formato in modo che questi dati possano essere utilizzati per altri scopi in seguito, mentre la deserializzazione dei dati significa l'opposto. La deserializzazione sta disimballando questi dati serializzati per l'uso di applicazioni. Deserializzazione insicua significa temperamento dei dati che sono stati serializzati poco prima che sta per essere disimballato o deserializzato. La deserializzazione insicura porta all'esecuzione del codice remoto e viene utilizzata per svolgere altri compiti per scopi dannosi come l'escalation dei privilegi, gli attacchi di iniezione, gli attacchi di replay, ecc. Ci sono alcuni strumenti disponibili per scoprire questo tipo di difetti, ma è necessaria l'assistenza umana frequentemente per convalidare il problema. Sfruttare la deserializzazione è un po 'difficile poiché gli exploit non funzionano senza alcuni cambiamenti manuali.

Quando l'applicazione deserializza oggetti dannosi forniti dall'entità attaccante. Questo può portare a due tipi di attacchi i.E attacchi relativi alla struttura dei dati e agli oggetti in cui l'attaccante modifica la logica dell'applicazione o eseguire codice remoto e attacchi tipici di manomissione dei dati in cui vengono utilizzate strutture di dati esistenti con contenuto modificato, ad esempio attacchi correlati al controllo di accesso. La serializzazione può essere utilizzata nella comunicazione di processo remoto (RPC) o in una comunicazione inter-Process (IPC), memorizzazione nella cache di dati, servizi Web, server cache di database, file system, token di autenticazione API, cookie HTML, parametri del modulo HTML, ecc. Gli attacchi di deserializzazione possono essere mitigati non utilizzando oggetti serializzati da fonti non attendibili, implementando controlli di integrità, isolando il codice in esecuzione in un ambiente privilegiato a basso.

Utilizzo di componenti con vulnerabilità note:

Componenti diversi come librerie, framework e moduli software sono utilizzati dalla maggior parte degli sviluppatori nell'applicazione Web. Queste biblioteche aiutano lo sviluppatore a evitare lavori inutili e a fornire la funzionalità necessaria. Gli aggressori cercano difetti e vulnerabilità in questi componenti per coordinare un attacco. In caso di trovare una scappatoia di sicurezza in un componente può rendere tutti i siti usando lo stesso componente, vulnerabile. Gli exploit di queste vulnerabilità sono già disponibili mentre si scrive un exploit personalizzato da zero richiede molto sforzo. Questo è un problema molto comune e diffuso, l'uso di grandi quantità di componenti nello sviluppo di un'applicazione Web non può nemmeno conoscere e comprendere tutti i componenti utilizzati, patching e aggiornamento di tutti i componenti è un lungo go.

Un'applicazione è vulnerabile se lo sviluppatore non conosce la versione di un componente utilizzato, il software è obsoleto i.E il sistema operativo, il dbms, il software in esecuzione, gli ambienti di runtime e le librerie, la scansione della vulnerabilità non viene eseguita regolarmente, la compatibilità del software patchated non è testata dagli sviluppatori. Può essere prevenuto rimuovendo regolarmente dipendenze, file, documentazione e librerie inutilizzate, controllando regolarmente la versione dei componenti sul lato client e sul lato server, ottenendo componenti e librerie da fonti sicure ufficiali e affidabili, monitorando le librerie e i componenti non versati Per aggiornare e patching regolarmente i componenti vulnerabili.

Queste vulnerabilità portano a piccoli impatti ma possono anche portare a compromettere il server e il sistema. Molte grandi violazioni si basavano su vulnerabilità note dei componenti. L'uso di componenti vulnerabili minano le difese dell'applicazione e può essere un punto di partenza per un grande attacco.

Registrazione e monitoraggio insufficienti:

La maggior parte dei sistemi non adotta abbastanza misure e passaggi per rilevare le violazioni dei dati. Il tempo medio di risposta di un incidente è 200 giorni dopo che è successo, questo è molto tempo per fare tutte le cose cattive per un'entità attaccante. La registrazione e il monitoraggio insufficienti consentono all'attaccante di attaccare ulteriormente il sistema, mantenere la presa sul sistema, manomettere, tenere ed estrarre dati secondo la necessità. Gli aggressori usano la mancanza di monitoraggio e risposta a loro favore per attaccare l'applicazione web.
Registrazione e monitoraggio insufficienti si verificano in qualsiasi momento.I registri di applicazioni non monitorati per attività insolite, eventi controllabili come tentativi di accesso non riusciti e alti valori di transazione non sono registrati correttamente, gli avvertimenti e gli errori generano messaggi di errore poco chiari, nessun avviso di trigger in caso di pentesting utilizzando strumenti DAST automatizzati, non essendo in grado di rilevare o avvisare rapidamente gli attacchi attivi, ecc. Questi possono essere mitigati garantendo che tutti i guasti di accesso, il controllo degli accessi e la convalida di input lato server possono essere registrati per identificare l'account utente dannoso e mantenuta per una quantità di tempo sufficiente per le indagini forensi ritardate, garantendo che i registri generati siano in un formato Compatibile con soluzioni centralizzate di gestione dei registri, garantendo controlli di integrità a transazioni di alto valore, stabilendo un sistema per avvisi tempestivi di attività sospette, ecc.

La maggior parte degli attacchi di successo inizia con il controllo e la sondaggio per le vulnerabilità in un sistema, consentendo questi sondaggi di vulnerabilità può comportare la compromesso dell'intero sistema.

Conclusione:

Le vulnerabilità di sicurezza in un'applicazione Web influiscono su tutte le entità relative a tale applicazione. Queste vulnerabilità devono essere curate per fornire un ambiente sicuro per gli utenti. Gli aggressori possono utilizzare queste vulnerabilità per compromettere un sistema, prenderlo e intensificare i privilegi. L'impatto di un'applicazione Web compromessa può essere visualizzato da credenziali rubate della carta di credito e furto di identità alla perdita di informazioni altamente riservate, ecc. A seconda delle esigenze e dei vettori di attacco di entità dannose.