Errori di logica ed errori nel controllo dell'accesso

Questo tipo di vulnerabilità è diverso rispetto ad altre (come IDORs o XSS) in quanto non è richiesto un payload che contiene caratteri particolari, ma può essere scatenato richieste HTTP perfettamente valide il cui obiettivo è andare ad interferire, in qualche modo, con la logica seguita dall'applicazione o per aggirare il controllo dell'accesso.

Gli errori di controllo dell'accesso si hanno quando particolari risorse o funzionalità non vengono protette in modo corretto.

Errori logici

Gli errori logici dell'applicazione sono difetti nella logica di questa, e possono essere sfruttati per danneggiare l'organizzazione, l'applicazione stessa o i suoi utenti.
Un errore logico comune si può trovare nell'autenticazione multifattoriale (MFA), che consiste nel richiedere all'utente di verificare la sua identità con qualcosa che conosce (password) e qualcosa che possiede (un codice inviato sul telefono, per esempio).
Prendiamo per esempio un normale flusso di autentificazione diviso in tre passaggi:

1. L'utente visita il sito https://hayden.com/login. L'applicazione chiede all'utente di inserire la password.

2. Se la password è giusta, l'applicazione manda un codice MFA all'indirizzo email di quell'utente e lo reindirizza su https://hayden.com/mfa, dove l'utente inserisce il codice MFA.

3. L'applicazione controlla il codice e, se è corretto, reindirizza l'utente su https://hayden.com/domande_sicurezza. Qui l'applicazione chiede all'utente diverse domande di sicurezza e gli permette di fare il login se le risposte fornite sono corrette.

Tuttavia, può capitare che gli utenti possano arrivare direttamente al passaggio 3 senza essere passati per quelli precedenti. Questo perchè, mentre l'applicazione reindirizza l'utente allo step successivo, potrebbe non controllare l'effettivo completamento del passaggio precedente, e quindi un utente potrebbe manipolare l'URL del sito e richiedere direttamente la pagina https://hayden.com/domande_sicurezza. Se questa viene mostrata senza dover completare i due passaggi precedenti, un utente malintenzionato potrebbe bypassare completamente l'autentificazione e loggare nel sito con la password di qualcun altro e rispondere alle domande di sicurezza, senza aver bisogno del dispositivo MFA.
Un altro modo in cui gli errori di logica possono manifestarsi è durante il processo di pagamento a più step.
Prendiamo per esempio un negozio online che permette agli utenti di salvare il loro metodo di pagamento.
Quando gli utenti salvano un nuovo metodo, il sito verifica se la carta di credito sia valida, in questo modo se un utente crea un ordine con un metodo di pagamento salvato, l'applicazione non ha bisogno di verificarlo nuovamente. Fingiamo che la richiesta HTTP per confermare un ordine con un metodo di pagamento salvato sia la seguente, dove il parametro id_pagamento si riferisce all'ID della carta di credito salvata:

POST /ordine_nuovo
Host: negozio.hayden.com
[...]
id_oggetto=7575
&quantità=1
&carta_salvata=1
&id_pagamento=1

Mentre la seguente richiesta HTTP si ottiene quando un utente paga con una nuova carta di credito.
In questo caso la carta di credito viene verificata al momento del checkout:

POST /ordine_nuovo
Host: negozio.hayden.com
[...]
item_id=7575
&quantità=1
&numero_carta=1234-4321-5678-8765

Tenendo in mente che l'applicazione verifica il numero della carta di credito solo se il cliente sta usando un nuovo metodo di pagamento, ma l'applicazione "capisce" se il metodo di pagamento è nuovo perché nella richiesta non compare il parametro carta_salvata.
Quindi un utente malintenzionato può fare una richiesta con il parametro carta_salvata e un numero finto della carta di credito e, sfruttando questo errore di logica, ordinare oggetti senza doverli pagare.

Errori nel controllo dell'accesso

L'esempio della carta di credito potrebbe essere classificato anche come errore nel controllo dell'accesso.
Questo tipo di vulnerabilità si ottiene quando il controllo dell'accesso viene implementato in modo scorretto e può venir bypassato da un utente malintenzionato.
Le vulnerabilità IDORs discusse qui sono delle conseguenze di errori nel controllo dell'accesso, ma ce ne sono altre molto comuni che bisogna imparare se si vuol diventare un Bug Hunter, guardiamone alcune.

Pannelli admin esposti

Ogni tanto le applicazioni trascurano o dimenticano di bloccare funzioni particolari come i pannelli admin.
Gli sviluppatori presumono che gli utenti non possano accedere a queste funzionalità perché non c'è un link dall'applicazione, o perché sono nascoste dietro URL o porte particolari. Tuttavia, spesso gli utenti malintenzionati possono accedere a questi pannelli senza autenticazione, se riescono a trovarli.
Per esempio, se un applicazione ad hayden.com nasconde il pannello admin dietro ad un URL come hayden.com/KLSIK3/admin.php, un utente malintenzionato potrebbe essere comunque in grado di trovarlo tramite Google dorking o un brute-force dell'URL.
A volte le applicazioni non implementano lo stesso meccanismo di controllo per ogni modo in cui si può accedere alle loro funzionalità "delicate".
Ad esempio, un pannello admin che è visualizzabile solo da coloro con le credenziali giuste da admin, ma se la richiesta arriva da un indirizzo IP interno che la macchina conosce, il pannello admin non chiederà all'utente di autenticarsi. In questo caso, se un utente malintenzionato riesce a trovare una vulnerabilità SSRF che gli permette di mandare richieste interne, possono accedere al pannello admin senza autenticazione.
Utenti malintenzionati potrebbe, inoltre, essere capaci di bypassare il controllo dell'accesso modificando i cookie o gli header della richiesta HTTP se sono prevedibili.
Prendiamo in considerazione un pannello admin che non chiede le credentiali fintanto che l'user che richiede l'accesso presenta il cookie admin=1 nella richiesta HTTP. In questo caso, tutto ciò che bisogna fare è semplicemente aggiungere il cookie admin=1 alla richiesta.
Un altro problema comune di errore nel controllo dell'accesso si ottiene quando gli utenti possono forzare la navigazione oltre ai punti di controllo dell'accesso.
Per esempio, per arrivare al pannello di controllo del sito hayden.com tramite URL si passa per hayden.com/UFKSlfj/admin.php.
Se si naviga a quell'URL, ci verrà richiesto di inserire le credenziali. Dopodiché veniamo reindirizzati a hayden.com/UFSKlfj/dashboard.php, che è dove si trova il pannello di controllo.
Gli utenti potrebbero raggiungere hayden.com/UFSKlfj/dashboard.php e accedere direttamente al pannello admin, senza inserire le credenziali, se l'applicazione non implementa il controllo dell'accesso alla pagina dashboard.

Vulnerabilità Directory Traversal

Queste vulnerabilità sono un altro tipo di errori di controllo dell'accesso e si ottengono quando gli utenti malintenzionati possono vedere, modificare o eseguire file a cui non dovrebbero avere accesso manipolando il percorso del file nei campi per l'input dell'utente.
Per esempio il sito hayden.com ha la funzionalità che permette agli utenti di accedere ai loro file caricati.
Raggiungendo hayden.com/uploads?file=esempio.jpeg, l'applicazione mostra il file chiamato esempio.jpeg nella cartella di upload dell'utente che si trova in /var/www/html/uploads/USERNAME/.
Se l'applicazione non implementa la sanitizzazione dell'input sul parametro file, un utente malintenzionato potrebbe usare l'attacco ../ (detto "dot dot slash") per uscire dalla cartella degli upload e leggere altri file sul sistema.
Per esempio, con il seguente URL riuscirebbe a leggere il file shadow, che nei sistemi UNIX contiene le password hashate. Se l'utente che dirige il server web ha il permesso di vedere il file, ora può farlo anche un utente malintenzionato. Potrebbe poi craccare le password trovate in questo file per ottenere accesso ad account privilegiati sul sistema, potrebbe inoltre ottenere accesso a dati sensibili come file di configurazione, file di log e codice sorgente.

Prevenzione

Gli errori logici dell'applicazione possono essere evitati facendo test per verificare che la sua logica funzioni come voluto.
E' consigliato che ad occuparsene sia qualcuno che capisca sia i requisiti di business dell'organizzazione sia il processo di sviluppo dell'applicazione.
Bisogna rivedere ogni processo in cerca di un qualsiasi difetto di logica che potrebbe portare ad un problema di sicurezza.
Per prevenire gli errori di controllo dell'accesso si devono implementare varie misure di sicurezza.
Per prima cosa, inserire delle politiche di controllo dettagliate su tutti i file e azioni su un sistema.
Inoltre, bisogna assicurarsi che anche i diversi modi di accedere ad un servizio abbiano meccanismi di controllo.
Ad esempio, non importa se si accede all'applicazione tramite un dispositivo mobile, un desktop o un endpoint API: gli stessi requisiti di autenticazione, come MFA, dovrebbero essere validi per ogni punto d'accesso.