Guadagna ben 4 posizioni, dalla quinta direttamente al piano più alto del podio rispetto alla scorsa edizione.
Il controllo accessi di un applicativo mette in atto delle policy di controllo tali da impedire agli utenti di compiere azioni al di fuori del loro spettro di autorizzazioni. Un controllo di accessi non funzionante porta solitamente ad una divulgazione non autorizzata di informazioni, la modifica o la distruzione di tutti i dati, o addirittura di svolgere delle attività aziendali per cui l’utente base non dovrebbe essere autorizzato. Si tratta quindi di una falla estremamente pericolosa che si traduce in danni potenzialmente nefasti per qualsiasi azienda, dal danno reputazionale, al danno economico (pensate ad un malintenzionato che sfruttando tale falla possa muovere somme di danaro ingenti ai danni dell’azienda).

Fra le varie sfaccettature della regina delle vulnerabilità troviamo:

• Violazioni del principio del “least privilege”, o assenza di regole “deny by default”, dove l’accesso dovrebbe essere concesso soltanto per alcuni ruoli specifici, ma in verità risulta disponibili agli utenti di qualsiasi livello
• Poter ingannare il sistema di controllo accessi in vari modi, dalla manipolazione dell’URL (sfruttando tecniche di manomissione dei parametri o force browsing), modificando lo stato interno dell’applicativo o della pagina HTML, fino ad arrivare dei tool di attacco per modificare le richieste API
• Consentire l’accesso o la modifica di un account di qualcun altro, fornendone direttamente l’ID (Insecure Direct Object References, dette anche IDOR)
• Poter accedere e sfruttare le API senza i controlli di accesso per i metodi POST, PUT e DELETE
• Elevazione dei privilegi. Essere in grado di agire da utente loggato senza aver effettuato il login, o agire come amministratore pure essendo loggato come utente base
• Manipolazione dei cookies e dei tokens, anche noto come manipolazione dei metadati. Ad esempio, attacchi di replay o la manipolazione degli JWT (JSON Web Tokens), o l’uso di campi nascosti per scalare i privilegi o abusare del processo di invalidazione degli JWT
• Una configurazione errata del CORS (Cross-origin resource sharing), che permette dunque un accesso alle API da fonti non autorizzate e/o sconosciute
• Poter forzare la navigazione su pagine che richiedono autenticazione senza credenziali, o di accedere alle pagine di privilegio elevate con credenziali da utente base.

Come difendersi?

Il controllo accessi è realmente efficace solo se implementato in maniera sicura lato server, o via API server-less, in quanto l’attaccante non potrà modificare le verifiche del sistema di controllo o i metadati delle richieste.

• Deny by default, eccetto per le risorse che devono essere pubbliche
• Implementare meccanismi di controllo accessi una volta e poi riutilizzarli per il resto dell’applicazione, minimizzando l’uso del CORS
• Il modello di controllo accessi dovrebbe imporre il concetto di “proprietà del dato”, piuttosto che permettere agli utenti di creare, leggere, aggiornare o cancellare indiscriminatamente i dati
• I domain models (modelli concettuali di funzionamento dei sistemi), dovrebbero tenere conto e imporre i requisiti in termini di limiti alle applicazioni aziendali in maniera univoca
• Disabilitare la possibilità di enumerare le directory dei webserver, e assicurarsi che i file dei metadati e i file di backup non siano presenti nelle web root
• Loggare eventuali fallimenti del controllo accessi, e, quando opportuno, allertare gli amministratori (ad esempio fallimenti continuativi e ripetuti nel tempo)
• Imporre dei limiti alle chiamate API per minimizzare l’impatto di tool di attacco automatizzati
• Gli identificativi di sessioni stateful dovrebbero venire invalidati dal server al logout utente. Nel caso di token JWT (stateless), dovrebbero avere un timer relativamente breve, per ridurre la finestra temporale di opportunità che un malintenzionato ha a disposizione sfruttando il token rubato. Se invece è necessario mantenere un TTL elevato per il token JWT, allora sarebbe opportuno sfruttare lo standard OAuth per revocare l’accesso.
• Gli sviluppatori e lo staff che si occupa di QA dovrebbero includere la verifica del funzionamento del controllo accessi, nei test di funzionali e di integrazione, come prassi abituale.

Bhè che dire… gli sviluppatori non hanno vita facile per quanto riguarda la sicurezza. Diventa però di fondamentale importanza avere ben presenti questi 10 punti cardine quando sviluppiamo un applicativo di qualsiasi genere esso sia.
Il consiglio è di tenere a mente le linee guide dell’OWASP, già in fase di progettazione, ancora prima di aver scritto una singola riga di codice. Assicurarsi di stare usando i framework più recenti, avere delle policies sane di patch management e software life cycle, testare i propri applicativi e farli testare da esterni (che possono avere un occhio più critico), e ultimo ma non per importanza, avere sempre un occhio attento sul panorama dei threat actors, definire un threat model per ogni ambito/azienda e mettere al sicuro il proprio codice e quindi il proprio business dalle minacce potenziali che si nascondono sulla rete.

Sei uno sviluppatore ma non hai idea di come fare? Contattaci, possiamo aiutarti!

Questo era l’ultimo capitolo, ma segui la nostra pagina LinkedIn per ulteriori notizie e aggiornamenti!