6 Rischi per la sicurezza del backend Web da considerare nello sviluppo

Adottare misure in fase di sviluppo per rafforzare e proteggere il back-end Web.


Le piccole imprese, le banche e molti settori dipendono dalle applicazioni web. Dal momento in cui si crea un’applicazione web, è fondamentale essere sicuri di avere protocolli per controllare le vulnerabilità mentre lo sviluppo si evolve per evitare violazioni della sicurezza, perdite di dati e problemi finanziari.

Gli attacchi Web più pericolosi sono quelli che si verificano sul lato server in cui i dati vengono archiviati e analizzati.

Cos’è il backend?

Un’applicazione Web è divisa in due parti: Frontend e Backend.

  • Il frontend è lato client, è la parte con cui l’utente interagisce. In genere, è costruito con HTML, CSS e Javascript.
  • Il backend è lato server. È fondamentalmente come funziona l’applicazione, applica la logica aziendale, le modifiche e gli aggiornamenti. Alcuni dei più noti stack tecnologici lato server coinvolgono PHP, NodeJS, Java, Ruby, C, Python, database, sicurezza (autenticazione, controllo accessi, ecc.), Struttura e gestione dei contenuti.

Un piccolo promemoria prima di iniziare: autenticazione, controllo degli accessi & gestione della sessione

È comune per noi confondere i termini. Quindi chiariamolo rapidamente:

  • L’autenticazione riguarda la prova dell’identità dell’utente (ad es. Password, nome utente, sicurezza delle domande, impronte digitali)
  • Il controllo dell’accesso riguarda ciò che l’utente può accedere all’applicazione. Applica la politica secondo cui gli utenti non possono agire al di fuori delle autorizzazioni previste.
  • La gestione della sessione riguarda risposte e richieste di transazioni associate allo stesso utente. È un meccanismo di scambio che viene utilizzato tra l’utente e l’applicazione dopo che è stato autenticato correttamente.

Esploriamo quanto segue per una migliore sicurezza web back-end.

Difetti di iniezione

Dal 2010, OSWAP ha classificato l’iniezione come il rischio di applicazione Web n. 1 più pericoloso.

I difetti di iniezione consentono a un utente di fornire dati contenenti parole chiave che modificheranno il comportamento delle query create sul database. Ad esempio, supponiamo di avere uno script SQL che controlla se esiste una voce corrispondente nel database.

uname = request.POST [‘username’]
passwd = request.POST [‘password’]
sql = "SELEZIONA ID DAGLI utenti DOVE username = ‘" + il tuo nome + "’AND password =’" + passwd + "’"
database.execute (SQL)

Un utente malintenzionato può ora manipolare il campo della password utilizzando SQL injection, ad esempio immettendo la password “OR 1 =” 1, che porta alla seguente query SQL:

sql = "SELEZIONA ID DAGLI utenti DOVE username = ” AND password = ‘password’ OR 1 = ‘1’

In questo modo, l’utente malintenzionato può accedere a tutte le tabelle utente del database, essendo la password sempre valida (1 = “1”). Se accedono come amministratore, possono apportare le modifiche che desidera.

Come prevenirlo?

È molto FACILE per evitare difetti di iniezione.

Il modo migliore e semplice per verificare se non vi sono difetti di iniezione è un’accurata revisione manuale del codice sorgente per verificare se le query nel database vengono eseguite tramite istruzioni preparate. È inoltre possibile utilizzare gli strumenti per verificare la presenza di vulnerabilità.

E dovresti anche fare quanto segue.

  • Usa gli ORM (Object Relational Mapping Tools).
  • Esci da tutti gli input. Un campo data non dovrebbe mai contenere nient’altro al di fuori delle date.
  • Isolare i tuoi dati in modo che solo le cose a cui si dovrebbe accedere da una determinata posizione siano trattenute in quella posizione.
  • Scrivi codici di errore di buona gestione. Non rendere il tuo database o il tuo backend troppo prolisso.

Troy Hunt ha fatto un corso brillante sull’iniezione di SQL. Se interessati, è possibile esplorarlo.

Autenticazione non funzionante

Come accennato in precedenza, l’autenticazione si occupa delle credenziali fornite. È la prima linea di difesa contro l’accesso senza restrizioni. Tuttavia, una cattiva implementazione e il mancato rispetto della politica di sicurezza possono portare a un’autenticazione errata.

L’autenticazione interrotta avviene principalmente con tre modelli:

  • Riempimenti di credenziali: dove l’attaccante ha un elenco di nomi utente e password validi e può automatizzare l’attacco per capire se le credenziali sono valide.
  • Attacco bruteforce: dove l’applicazione consente password deboli per utenti o amministratori.
  • Dirottamento della sessione: dove l’applicazione espone ID sessione, URL o non ruota dopo l’accesso.

In tutti i casi, l’utente malintenzionato può ottenere l’accesso a un account importante e dipendere dall’azienda che può causare riciclaggio di denaro, furto di identità o divulgare informazioni legalmente protette e altamente sensibili.

Come prevenirlo?

Prima di implementare il sistema di autenticazione, chiediti: cosa potrebbe ottenere un utente malintenzionato se il sistema di autenticazione fosse compromesso?

E secondo la risposta, puoi fare quanto segue.

  • Implementare l’autenticazione a più fattori per prevenire attacchi automatici.
  • Incoraggiare (o forzare) l’utente ad adottare una buona politica di password.
  • Limita accessi non riusciti.
  • Usa l’hash dell’algoritmo efficiente. Quando si sceglie un algoritmo, considerare la lunghezza massima della password.
  • Testare il sistema di timeout della sessione e assicurarsi che il token della sessione sia invalidato dopo il logout.

Controllo accessi non funzionante

Il controllo degli accessi esiste per garantire ciò che l’utente autenticato è autorizzato a fare. Autenticazione e gestione della sessione sono le regole di base o di controllo dell’accesso. Ma quando queste regole non sono ben definite, ciò può portare a problemi significativi.

I difetti di controllo dell’accesso comuni includono:

  • Configurazione errata di CORS che consente l’accesso API non autorizzato.
  • Manipolazione dei metadati per indirizzare l’accesso ai metodi.
  • Navigazione forzata: l’attaccante proverà un URL, modificherà i percorsi (ad es. Http: //website.domain/user/ to http: //website.domain/admin) e potrà persino scoprire file importanti.

Come prevenirlo?

Per lo più, i difetti di accesso rotti si verificano per ignoranza sui requisiti essenziali di un’efficace gestione dell’accesso.

  • Nega per impostazione predefinita ad eccezione delle risorse pubbliche.
  • Disabilitare l’elenco delle directory del server e assicurarsi che i file di backup non siano presenti.
  • Limite di accesso all’API per ridurre l’impatto degli attacchi automatici.
  • Token JWT non validi dopo la disconnessione sul lato back-end.

Esposizione dei dati

Chiamata anche violazione dei dati, l’esposizione dei dati è una minaccia informatica che minaccia le aziende e i loro clienti.

Si verifica quando l’applicazione non protegge adeguatamente informazioni come credenziali o dati sensibili come carte di credito o cartelle cliniche. Sono oltre 4000 i record violato ogni minuto.

L’impatto sul business è grande dal punto di vista finanziario: una violazione media può costare 3,92 milioni di dollari, secondo IBM.

Come prevenirlo?

Come sviluppatore back-end, dovresti chiedere quali sono le informazioni che richiedono protezione.

E quindi per prevenire tali difetti:

  • Crittografa dati sensibili: per i dati su REST, crittografa tutto. Per i dati in transito, assicurarsi di utilizzare gateway sicuri (SSL)
  • Identificare i dati che richiedono una protezione aggiuntiva e limitare l’accessibilità solo a un gruppo di utenti legittimi solo applicando la crittografia basata su chiave.
  • Evita l’algoritmo di crittografia debole: usa e algoritmi forti.
  • Avere un piano di backup sicuro.

Deserializzazione insicura

La serializzazione e la deserializzazione sono concetti utilizzati quando i dati vengono convertiti in formato oggetto per essere archiviati o inviati a un’altra applicazione. La serializzazione consiste nella conversione di dati in formato oggetto come XML o JSON per renderli utilizzabili. La deserializzazione è solo il processo inverso.

Gli attacchi contro i deserializzatori possono portare a attacchi di negazione del servizio, controllo degli accessi ed esecuzione di codice remoto (RCE) se ci sono classi che possono essere modificate per cambiare comportamento.

Il secondo esempio del documento top 10 di OWASP fornisce una buona illustrazione del serializzatore di oggetti PHP:

a: 4: {i: 0; i: 132; i: 1; s: 7:"Mallory"; I: 2; s: 4:"utente";
i: 3; s: 32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

Questo è un supercookie che contiene informazioni come l’ID utente, il livello dell’utente e la password con hash.

Un utente malintenzionato può modificare l’oggetto serializzato per ottenere l’accesso ai privilegi di amministratore:

a: 4: {i: 0; i: 1; i: 1; s: 5:"Alice"; I: 2; s: 5:"Admin";
i: 3; s: 32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

Come prevenirlo?

È fondamentale non accettare oggetti serializzati da fonti non attendibili.

Dovresti anche:

  • Non fidarti mai dell’input dell’utente.
  • Convalida dati: se l’applicazione ad eccezione di una stringa, assicurati che sia una stringa prima di utilizzarla
  • Usa un segno di spunta per assicurarti che i dati non siano stati modificati. È utile che stai inviando dati tra due fonti attendibili (ad es., Memorizzazione dei dati lato client).

Server XSS

Server XSS (Cross-site scripting) è un tipo di iniezione quando un utente malintenzionato utilizza un’applicazione Web per inviare codice dannoso a utenti diversi. Si verifica quando l’attaccante pubblica alcuni dati predisposti contenenti codice dannoso che l’applicazione memorizza. Questa vulnerabilità è lato server; il browser esegue semplicemente il rendering della risposta.

Ad esempio, in un forum, i post degli utenti vengono salvati in un database, spesso senza verifica. Gli aggressori ne approfittano per aggiungere post con script dannosi. Successivamente, altri utenti ricevono questo link via e-mail o vedono il post in questione e fanno clic su di esso.

Come prevenirlo?

Dopo l’identificazione primaria di tutte le operazioni potenzialmente a rischio di XSS e che devono essere protette, è necessario considerare quanto segue.

  • Convalida input: verifica la lunghezza dell’input, utilizza la corrispondenza regex e consente solo un determinato set di caratteri.
  • Convalida dell’output: se l’applicazione copia nelle risposte a qualsiasi elemento di dati originato da un utente o da una terza parte, questi dati devono essere codificati in HTML per disinfettare caratteri potenzialmente dannosi.
  • Consenti HTML limite: ad esempio, se disponi di un sistema di blog di commenti, consenti solo l’uso di determinati tag. Se possibile, utilizzare un framework adatto per il markup HTML fornito dall’utente per provare ad assicurarsi che non contenga alcun mezzo per eseguire JavaScript.

Conclusione

La fase di sviluppo è cruciale per la sicurezza delle applicazioni web. Inoltre, dovresti considerare di includere uno scanner delle vulnerabilità della sicurezza nel ciclo di vita dello sviluppo, quindi i problemi identificati vengono risolti prima della produzione.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map