PortSwigger Academy – Access control vulnerabilities and privilege escalation
Continua il percorso di apprendimento suggerito da “PortSwigger Academy”.
Access control vulnerabilities and privilege escalation
In questa sezione descriviamo:
- Escalation dei privilegi.
- I tipi di vulnerabilità che possono verificarsi con il controllo degli accessi.
- Come prevenire le vulnerabilità del controllo degli accessi.
Cos’è il controllo degli accessi?
Il controllo degli accessi è l’applicazione di vincoli su chi o cosa è autorizzato a eseguire azioni o accedere alle risorse. Nel contesto delle applicazioni web, il controllo degli accessi dipende dall’autenticazione e dalla gestione delle sessioni:
- L’autenticazione conferma che l’utente è chi dice di essere.
- La gestione delle sessioni identifica quali successive richieste HTTP vengono effettuate dallo stesso utente.
- Il controllo dell’accesso determina se all’utente è consentito eseguire l’azione che sta tentando di eseguire.
I controlli di accesso non funzionanti sono comuni e spesso presentano una vulnerabilità critica per la sicurezza. La progettazione e la gestione dei controlli di accesso è un problema complesso e dinamico che applica vincoli aziendali, organizzativi e legali a un’implementazione tecnica. Le decisioni sulla progettazione del controllo degli accessi devono essere prese dagli esseri umani, quindi il rischio di errori è elevato.
Controlli di accesso verticale
I controlli di accesso verticale sono meccanismi che limitano l’accesso a funzionalità sensibili a tipi specifici di utenti.
Con i controlli di accesso verticale, diversi tipi di utenti hanno accesso a diverse funzioni dell’applicazione. Ad esempio, un amministratore potrebbe essere in grado di modificare o eliminare l’account di qualsiasi utente, mentre un utente normale non ha accesso a queste azioni. I controlli degli accessi verticali possono essere implementazioni più precise di modelli di sicurezza progettati per applicare politiche aziendali come la separazione dei compiti e il minimo privilegio.
Controlli di accesso orizzontali
I controlli di accesso orizzontali sono meccanismi che limitano l’accesso alle risorse a utenti specifici.
Con i controlli di accesso orizzontali, utenti diversi hanno accesso a un sottoinsieme di risorse dello stesso tipo. Ad esempio, un’applicazione bancaria consentirà a un utente di visualizzare le transazioni ed effettuare pagamenti dai propri conti, ma non dai conti di qualsiasi altro utente.
Controlli di accesso dipendenti dal contesto
I controlli di accesso dipendenti dal contesto limitano l’accesso a funzionalità e risorse in base allo stato dell’applicazione o all’interazione dell’utente con essa.
I controlli di accesso dipendenti dal contesto impediscono a un utente di eseguire azioni nell’ordine sbagliato. Ad esempio, un sito Web di vendita al dettaglio potrebbe impedire agli utenti di modificare il contenuto del carrello dopo aver effettuato il pagamento.
Esempi di controlli di accesso non funzionanti
Esistono vulnerabilità nel controllo degli accessi interrotti quando un utente può accedere a risorse o eseguire azioni che non dovrebbe essere in grado di eseguire.
Escalation verticale dei privilegi
Se un utente può accedere a funzionalità a cui non è autorizzato ad accedere, si tratta di un’escalation dei privilegi verticale. Ad esempio, se un utente non amministrativo può accedere a una pagina di amministrazione in cui può eliminare gli account utente, si tratta di un’escalation dei privilegi verticale.
Funzionalità non protetta
Nella sua forma più elementare, l’escalation verticale dei privilegi si verifica quando un’applicazione non applica alcuna protezione per funzionalità sensibili. Ad esempio, le funzioni amministrative potrebbero essere collegate dalla pagina di benvenuto di un amministratore ma non dalla pagina di benvenuto di un utente. Tuttavia, un utente potrebbe essere in grado di accedere alle funzioni amministrative accedendo all’URL di amministrazione pertinente.
Ad esempio, un sito Web potrebbe ospitare funzionalità sensibili al seguente URL:
https://insecure-website.com/adminPotrebbe essere accessibile a qualsiasi utente, non solo agli utenti amministrativi che dispongono di un collegamento alla funzionalità nella propria interfaccia utente. In alcuni casi, l’URL amministrativo potrebbe essere divulgato in altre posizioni, come nel file robots.txt:
https://insecure-website.com/robots.txtAnche se l’URL non viene divulgato da nessuna parte, un utente malintenzionato potrebbe essere in grado di utilizzare un elenco di parole per forzare la posizione della funzionalità sensibile.
Lab-https://portswigger.net/web-security/access-control/lab-unprotected-admin-functionality
In alcuni casi, la funzionalità sensibile viene nascosta assegnandogli un URL meno prevedibile. Questo è un esempio della cosiddetta “sicurezza tramite oscurità”. Tuttavia, nascondere funzionalità sensibili non fornisce un controllo efficace dell’accesso perché gli utenti potrebbero scoprire l’URL offuscato in diversi modi.
Immagina un’applicazione che ospita funzioni amministrative al seguente URL:
https://insecure-website.com/administrator-panel-yb556Questo potrebbe non essere direttamente indovinabile da un utente malintenzionato. Tuttavia, l’applicazione potrebbe comunque divulgare l’URL agli utenti. L’URL potrebbe essere divulgato in JavaScript che costruisce l’interfaccia utente in base al ruolo dell’utente:
<script>
var isAdmin = false;
if (isAdmin) {
...
var adminPanelTag = document.createElement('a');
adminPanelTag.setAttribute('href', 'https://insecure-website.com/administrator-panel-yb556');
adminPanelTag.innerText = 'Admin panel';
...
}
</script>Questo script aggiunge un collegamento all’interfaccia utente stesso se è un utente amministratore. Tuttavia, lo script contenente l’URL è visibile a tutti gli utenti indipendentemente dal loro ruolo.
Metodi di controllo degli accessi basati su parametri
Alcune applicazioni determinano i diritti di accesso dell’utente o il ruolo al login, quindi archiviano queste informazioni in una posizione controllabile dall’utente. Questo potrebbe essere:
- un campo nascosto;
- un cookie;
- un parametro stringa di query preimpostata.
L’applicazione prende decisioni di controllo degli accessi in base al valore inviato. Per esempio:
https://insecure-website.com/login/home.jsp?admin=true
https://insecure-website.com/login/home.jsp?role=1Questo approccio è insicuro perché un utente può modificare la funzionalità di valore e accesso a cui non sono autorizzati, come le funzioni amministrative.
Lab-https://portswigger.net/web-security/access-control/lab-user-role-controlled-by-request-parameter
Lab-https://portswigger.net/web-security/access-control/lab-user-role-can-be-modified-in-user-profile
Controllo del broken access derivante dall’errore di configurazione della piattaforma
Alcune applicazioni applicano i controlli di accesso a livello della piattaforma. Lo fanno limitando l’accesso a URL specifici e metodi HTTP in base al ruolo dell’utente. Ad esempio, un’applicazione potrebbe configurare una regola come segue:
DENY: POST, /admin/deleteUser, managers
Questa regola nega l’accesso al metodo POST sull’URL /admin/deleteUser, per gli utenti nel gruppo managers. Varie cose possono andare storte in questa situazione, portando al bypass del controllo dell’accesso.
Alcuni framework di applicazione supportano varie intestazioni HTTP non standard che possono essere utilizzate per sovrascrivere l’URL nella richiesta originale, come X-Original-URL e X-Rewrite-URL. Se un sito Web utilizza rigorosi controlli front-end per limitare l’accesso in base all’URL, ma l’applicazione consente di essere sovrascritto dall’URL tramite un’intestazione di richiesta, potrebbe essere possibile bypassare i controlli di accesso utilizzando una richiesta come la seguente:
POST / HTTP/1.1
X-Original-URL: /admin/deleteUser
...Lab-https://portswigger.net/web-security/access-control/lab-url-based-access-control-can-be-circumvented
Un attacco alternativo si riferisce al metodo HTTP utilizzato nella richiesta. I controlli front-end descritti nelle sezioni precedenti limitano l’accesso in base al metodo URL e HTTP. Alcuni siti Web tollerano diversi metodi di richiesta HTTP durante l’esecuzione di un’azione. Se un utente malintenzionato può utilizzare il metodo GET (o un altro) per eseguire azioni su un URL limitato, può bypassare il controllo di accesso implementato sul livello della piattaforma.
Controllo di broken access derivante dalle discrepanze di corrispondenza dell’URL
I siti Web possono variare nel modo in cui corrispondono rigorosamente al percorso di una richiesta in arrivo a un endpoint definito. Ad esempio, possono tollerare la capitalizzazione incoerente, quindi una richiesta a /ADMIN /DELETEUSER può ancora essere mappata all’endpoint /admin/deleteUser. Se il meccanismo di controllo dell’accesso è meno tollerante, può trattarli come due diversi endpoint e non far rispettare le restrizioni corrette di conseguenza.
Discrepanze simili possono sorgere se gli sviluppatori che utilizzano il framework Spring hanno abilitato l’opzione useSuffixPatternMatch. Ciò consente ai percorsi con un’estensione di file arbitraria di essere mappata su un endpoint equivalente senza estensione del file. In altre parole, una richiesta a /admin/deleteUser.anything corrisponderebbe comunque al modello /admin/deleteUser. Prima di Spring 5.3, questa opzione è abilitata per impostazione predefinita.
Su altri sistemi, è possibile che si verifichino discrepanze se /admin/deleteUser e /admin/deleteUser/ sono trattati come endpoint distinti. In questo caso, potresti essere in grado di bypassare i controlli di accesso aggiungendo una barra finale sul percorso.
Escalation del privilegio orizzontale
L’escalation del privilegio orizzontale si verifica se un utente è in grado di accedere alle risorse appartenenti a un altro utente, anziché alle proprie risorse di quel tipo. Ad esempio, se un dipendente può accedere ai registri di altri dipendenti e propri, allora si tratta di un’escalation del privilegio orizzontale.
Gli attacchi di escalation dei privilegi orizzontali possono utilizzare tipi simili di metodi di exploit per l’escalation del privilegio verticale. Ad esempio, un utente potrebbe accedere alla propria pagina dell’account utilizzando il seguente URL:
https://insecure-website.com/myaccount?id=123Se un utente malintenzionato modifica il valore del parametro id a quello di un altro utente, potrebbe accedere alla pagina dell’account di un altro utente e ai dati e alle funzioni associati.
Nota
Questo è un esempio di vulnerabilità di riferimento a oggetti diretti (IDOR) insicuri. Questo tipo di vulnerabilità sorge laddove i valori dei parametri di controllo utente vengono utilizzati per accedere direttamente alle risorse o alle funzioni.
Lab-https://portswigger.net/web-security/access-control/lab-user-id-controlled-by-request-parameter
In alcune applicazioni, il parametro sfruttabile non ha un valore prevedibile. Ad esempio, invece di un numero incremento, un’applicazione potrebbe utilizzare identificatori univoci a livello globale (GUID) per identificare gli utenti. Ciò può impedire a un aggressore di indovinare o prevedere l’identificatore di un altro utente. Tuttavia, le GUID appartenenti ad altri utenti potrebbero essere divulgati altrove nell’applicazione in cui gli utenti vengono referenziati, come i messaggi dell’utente o le revisioni.
In alcuni casi, un’applicazione rileva quando all’utente non è autorizzato ad accedere alla risorsa e restituisce un reindirizzamento alla pagina di accesso. Tuttavia, la risposta contenente il reindirizzamento potrebbe includere ancora alcuni dati sensibili appartenenti all’utente mirato, quindi l’attacco ha ancora successo.
Escalation del privilegio orizzontale a verticale
Spesso, un attacco di escalation del privilegio orizzontale può essere trasformato in un’escalation del privilegio verticale, compromettendo un utente più privilegiato. Ad esempio, un’escalation orizzontale potrebbe consentire a un utente malintenzionato di ripristinare o catturare la password appartenente a un altro utente. Se l’attaccante si rivolge a un utente amministrativo e compromette il proprio account, può ottenere un accesso amministrativo e quindi eseguire un’escalation del privilegio verticale.
Un utente malintenzionato potrebbe essere in grado di accedere alla pagina dell’account di un altro utente utilizzando la tecnica di manomissione dei parametri già descritta per l’escalation del privilegio orizzontale:
https://insecure-website.com/myaccount?id=456Se l’utente target è un amministratore dell’applicazione, l’attaccante otterrà l’accesso a una pagina dell’account amministrativo. Questa pagina potrebbe divulgare la password dell’amministratore o fornire un mezzo per modificarla o fornire accesso diretto alla funzionalità privilegiata.
Riferimenti di oggetti diretti insicuri
I riferimenti a oggetti diretti insicuri (Insecure direct object references – IDORS) sono una sottocategoria di vulnerabilità di controllo degli accessi. Gli IDOR si verificano se un’applicazione utilizza l’input fornito dall’utente per accedere direttamente agli oggetti e un utente malintenzionato può modificare l’input per ottenere un accesso non autorizzato. È stato reso popolare dalla sua apparizione nella Top Ten Owasp 2007. È solo un esempio di molti errori di implementazione che possono fornire un mezzo per aggirare i controlli di accesso.
Lab-https://portswigger.net/web-security/access-control/lab-insecure-direct-object-references
Vulnerabilità di controllo degli accessi nei processi in più fasi
Molti siti Web implementano funzioni importanti su una serie di passaggi. Questo è comune quando:
- una varietà di input o opzioni deve essere acquisita;
- l’utente deve rivedere e confermare i dettagli prima dell’esecuzione dell’azione.
Ad esempio, la funzione amministrativa per aggiornare i dettagli dell’utente potrebbe coinvolgere i seguenti passaggi:
- caricare il modulo che contiene i dettagli per un utente specifico;
- inviare le modifiche;
- rivedere le modifiche e confermare.
A volte, un sito Web implementerà rigorosi controlli di accesso su alcuni di questi passaggi, ma ignorerà altri. Immagina un sito Web in cui i controlli di accesso vengono applicati correttamente al primo e al secondo passaggio, ma non al terzo passaggio. Il sito Web presuppone che un utente raggiunga il passaggio 3 solo se ha già completato i primi passi, che sono correttamente controllati. Un utente malintenzionato può ottenere un accesso non autorizzato alla funzione saltando i primi due passaggi e inviando direttamente la richiesta per il terzo passaggio con i parametri richiesti.
Controllo degli accessi basato sui Referer
Alcuni siti Web basano controlli di accesso sull’intestazione del Referer inviati nella richiesta HTTP. L’intestazione del Referer può essere aggiunta alle richieste dei browser per indicare quale pagina ha avviato una richiesta.
Ad esempio, un’applicazione applica abilmente il controllo dell’accesso sulla pagina amministrativa principale /admin, ma per le sottopagine come /admin /deleteUser ispeziona solo l’intestazione del Referer. Se l’intestazione del Referer contiene l’URL principale /admin, è consentita la richiesta.
In questo caso, l’intestazione del Referer può essere completamente controllata da un aggressore. Ciò significa che possono forgiare richieste dirette alle secondarie sottopagine sensibili fornendo l’intestazione del Referer richiesto e ottenere un accesso non autorizzato.
Lab-https://portswigger.net/web-security/access-control/lab-referer-based-access-control
Controllo dell’accesso basato sulla posizione
Alcuni siti Web applicano i controlli di accesso in base alla posizione geografica dell’utente. Ciò può applicarsi, ad esempio, alle applicazioni bancarie o ai servizi dei media in cui si applicano la legislazione statale o le restrizioni aziendali. Questi controlli di accesso possono spesso essere aggirati dall’uso di proxy Web, VPN o manipolazione dei meccanismi di geolocalizzazione sul lato client.
Come prevenire le vulnerabilità del controllo degli accessi
Le vulnerabilità di controllo degli accessi possono essere prevenute adottando un approccio di difesa in profondità e applicando i seguenti principi:
- non fare mai affidamento sull’offuscamento da solo per il controllo dell’accesso;
- a meno che una risorsa non sia destinata a essere accessibile al pubblico, negano l’accesso per impostazione predefinita;
- ove possibile, utilizzare un singolo meccanismo a livello di applicazione per far rispettare i controlli di accesso;
- a livello di codice, rendere obbligatorio per gli sviluppatori dichiarare l’accesso consentito per ciascuna risorsa e negare l’accesso per impostazione predefinita;
- controlli di accesso a controllo e test per garantire che funzionino come progettato.
