Access control vulnerabilities and privilege escalation<\/strong><\/p>\n\n\n\n In questa sezione descriviamo:<\/p>\n\n\n\n Cos\u2019\u00e8 il controllo degli accessi?<\/strong><\/p>\n\n\n\n Il controllo degli accessi \u00e8 l\u2019applicazione di vincoli su chi o cosa \u00e8 autorizzato a eseguire azioni o accedere alle risorse. Nel contesto delle applicazioni web, il controllo degli accessi dipende dall\u2019autenticazione e dalla gestione delle sessioni:<\/p>\n\n\n\n I controlli di accesso non funzionanti sono comuni e spesso presentano una vulnerabilit\u00e0 critica per la sicurezza. La progettazione e la gestione dei controlli di accesso \u00e8 un problema complesso e dinamico che applica vincoli aziendali, organizzativi e legali a un\u2019implementazione tecnica. Le decisioni sulla progettazione del controllo degli accessi devono essere prese dagli esseri umani, quindi il rischio di errori \u00e8 elevato.<\/p>\n\n\n\n Controlli di accesso verticale<\/strong><\/p>\n\n\n\n I controlli di accesso verticale sono meccanismi che limitano l\u2019accesso a funzionalit\u00e0 sensibili a tipi specifici di utenti.<\/p>\n\n\n\n Con i controlli di accesso verticale, diversi tipi di utenti hanno accesso a diverse funzioni dell\u2019applicazione. Ad esempio, un amministratore potrebbe essere in grado di modificare o eliminare l\u2019account di qualsiasi utente, mentre un utente normale non ha accesso a queste azioni. I controlli degli accessi verticali possono essere implementazioni pi\u00f9 precise di modelli di sicurezza progettati per applicare politiche aziendali come la separazione dei compiti e il minimo privilegio.<\/p>\n\n\n\n Controlli di accesso orizzontali<\/strong><\/p>\n\n\n\n I controlli di accesso orizzontali sono meccanismi che limitano l\u2019accesso alle risorse a utenti specifici.<\/p>\n\n\n\n Con i controlli di accesso orizzontali, utenti diversi hanno accesso a un sottoinsieme di risorse dello stesso tipo. Ad esempio, un\u2019applicazione bancaria consentir\u00e0 a un utente di visualizzare le transazioni ed effettuare pagamenti dai propri conti, ma non dai conti di qualsiasi altro utente.<\/p>\n\n\n\n Controlli di accesso dipendenti dal contesto<\/strong><\/p>\n\n\n\n I controlli di accesso dipendenti dal contesto limitano l\u2019accesso a funzionalit\u00e0 e risorse in base allo stato dell\u2019applicazione o all\u2019interazione dell\u2019utente con essa.<\/p>\n\n\n\n I controlli di accesso dipendenti dal contesto impediscono a un utente di eseguire azioni nell\u2019ordine 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.<\/p>\n\n\n\n Esempi di controlli di accesso non funzionanti<\/strong><\/p>\n\n\n\n Esistono vulnerabilit\u00e0 nel controllo degli accessi interrotti quando un utente pu\u00f2 accedere a risorse o eseguire azioni che non dovrebbe essere in grado di eseguire.<\/p>\n\n\n\n Escalation verticale dei privilegi<\/strong><\/p>\n\n\n\n Se un utente pu\u00f2 accedere a funzionalit\u00e0 a cui non \u00e8 autorizzato ad accedere, si tratta di un\u2019escalation dei privilegi verticale. Ad esempio, se un utente non amministrativo pu\u00f2 accedere a una pagina di amministrazione in cui pu\u00f2 eliminare gli account utente, si tratta di un\u2019escalation dei privilegi verticale.<\/p>\n\n\n\n Funzionalit\u00e0 non protetta<\/strong><\/p>\n\n\n\n Nella sua forma pi\u00f9 elementare, l\u2019escalation verticale dei privilegi si verifica quando un\u2019applicazione non applica alcuna protezione per funzionalit\u00e0 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\u2019URL di amministrazione pertinente.<\/p>\n\n\n\n Ad esempio, un sito Web potrebbe ospitare funzionalit\u00e0 sensibili al seguente URL:<\/p>\n\n\n\n Potrebbe essere accessibile a qualsiasi utente, non solo agli utenti amministrativi che dispongono di un collegamento alla funzionalit\u00e0 nella propria interfaccia utente. In alcuni casi, l\u2019URL amministrativo potrebbe essere divulgato in altre posizioni, come nel file Anche se l\u2019URL 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\u00e0 sensibile.<\/p>\n\n\n\n Lab-https:\/\/portswigger.net\/web-security\/access-control\/lab-unprotected-admin-functionality<\/a><\/p>\n\n\n\n In alcuni casi, la funzionalit\u00e0 sensibile viene nascosta assegnandogli un URL meno prevedibile. Questo \u00e8 un esempio della cosiddetta \u201csicurezza tramite oscurit\u00e0<\/em>\u201d. Tuttavia, nascondere funzionalit\u00e0 sensibili non fornisce un controllo efficace dell\u2019accesso perch\u00e9 gli utenti potrebbero scoprire l\u2019URL offuscato in diversi modi.<\/p>\n\n\n\n Immagina un\u2019applicazione che ospita funzioni amministrative al seguente URL:<\/p>\n\n\n\n Questo potrebbe non essere direttamente indovinabile da un utente malintenzionato. Tuttavia, l\u2019applicazione potrebbe comunque divulgare l\u2019URL agli utenti. L\u2019URL potrebbe essere divulgato in JavaScript che costruisce l\u2019interfaccia utente in base al ruolo dell\u2019utente:<\/p>\n\n\n\n Questo script aggiunge un collegamento all\u2019interfaccia utente stesso se \u00e8 un utente amministratore. Tuttavia, lo script contenente l\u2019URL \u00e8 visibile a tutti gli utenti indipendentemente dal loro ruolo.<\/p>\n\n\n\n Lab-https:\/\/portswigger.net\/web-security\/access-control\/lab-unprotected-admin-functionality-with-unpredictable-url<\/a><\/p>\n\n\n\n Metodi di controllo degli accessi basati su parametri<\/strong><\/p>\n\n\n\n Alcune applicazioni determinano i diritti di accesso dell\u2019utente o il ruolo al login, quindi archiviano queste informazioni in una posizione controllabile dall\u2019utente. Questo potrebbe essere:<\/p>\n\n\n\n L\u2019applicazione prende decisioni di controllo degli accessi in base al valore inviato. Per esempio:<\/p>\n\n\n\n Questo approccio \u00e8 insicuro perch\u00e9 un utente pu\u00f2 modificare la funzionalit\u00e0 di valore e accesso a cui non sono autorizzati, come le funzioni amministrative.<\/p>\n\n\n\n Lab-https:\/\/portswigger.net\/web-security\/access-control\/lab-user-role-controlled-by-request-parameter<\/a><\/p>\n\n\n\n Lab-https:\/\/portswigger.net\/web-security\/access-control\/lab-user-role-can-be-modified-in-user-profile<\/a><\/p>\n\n\n\n Controllo del <\/strong>broken access<\/em><\/strong> derivante dall\u2019errore di configurazione della piattaforma<\/strong><\/p>\n\n\n\n Alcune applicazioni applicano i controlli di accesso a livello della piattaforma. Lo fanno limitando l\u2019accesso a URL specifici e metodi HTTP in base al ruolo dell\u2019utente. Ad esempio, un\u2019applicazione potrebbe configurare una regola come segue:<\/p>\n\n\n\n Questa regola nega l\u2019accesso al metodo Alcuni framework di applicazione supportano varie intestazioni HTTP non standard che possono essere utilizzate per sovrascrivere l\u2019URL nella richiesta originale, come Lab-https:\/\/portswigger.net\/web-security\/access-control\/lab-url-based-access-control-can-be-circumvented<\/a><\/p>\n\n\n\n Un attacco alternativo si riferisce al metodo HTTP utilizzato nella richiesta. I controlli front-end descritti nelle sezioni precedenti limitano l\u2019accesso in base al metodo URL e HTTP. Alcuni siti Web tollerano diversi metodi di richiesta HTTP durante l\u2019esecuzione di un\u2019azione. Se un utente malintenzionato pu\u00f2 utilizzare il metodo Lab-https:\/\/portswigger.net\/web-security\/access-control\/lab-method-based-access-control-can-be-circumvented<\/a><\/p>\n\n\n\n Controllo di broken access derivante dalle discrepanze di corrispondenza dell\u2019URL<\/strong><\/p>\n\n\n\n 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 Discrepanze simili possono sorgere se gli sviluppatori che utilizzano il framework Spring hanno abilitato l\u2019opzione Su altri sistemi, \u00e8 possibile che si verifichino discrepanze se Escalation del privilegio orizzontale<\/strong><\/p>\n\n\n\n L\u2019escalation del privilegio orizzontale si verifica se un utente \u00e8 in grado di accedere alle risorse appartenenti a un altro utente, anzich\u00e9 alle proprie risorse di quel tipo. Ad esempio, se un dipendente pu\u00f2 accedere ai registri di altri dipendenti e propri, allora si tratta di un\u2019escalation del privilegio orizzontale.<\/p>\n\n\n\n Gli attacchi di escalation dei privilegi orizzontali possono utilizzare tipi simili di metodi di exploit per l\u2019escalation del privilegio verticale. Ad esempio, un utente potrebbe accedere alla propria pagina dell\u2019account utilizzando il seguente URL:<\/p>\n\n\n\n Se un utente malintenzionato modifica il valore del parametro Nota<\/strong><\/p>\n\n\n\n Questo \u00e8 un esempio di vulnerabilit\u00e0 di riferimento a oggetti diretti (IDOR) insicuri. Questo tipo di vulnerabilit\u00e0 sorge laddove i valori dei parametri di controllo utente vengono utilizzati per accedere direttamente alle risorse o alle funzioni.<\/p>\n\n\n\n Lab-https:\/\/portswigger.net\/web-security\/access-control\/lab-user-id-controlled-by-request-parameter<\/a><\/p>\n\n\n\n In alcune applicazioni, il parametro sfruttabile non ha un valore prevedibile. Ad esempio, invece di un numero incremento, un\u2019applicazione potrebbe utilizzare identificatori univoci a livello globale (GUID) per identificare gli utenti. Ci\u00f2 pu\u00f2 impedire a un aggressore di indovinare o prevedere l\u2019identificatore di un altro utente. Tuttavia, le GUID appartenenti ad altri utenti potrebbero essere divulgati altrove nell\u2019applicazione in cui gli utenti vengono referenziati, come i messaggi dell\u2019utente o le revisioni.<\/p>\n\n\n\n Lab-https:\/\/portswigger.net\/web-security\/access-control\/lab-user-id-controlled-by-request-parameter-with-unpredictable-user-ids<\/a><\/p>\n\n\n\n In alcuni casi, un\u2019applicazione rileva quando all\u2019utente non \u00e8 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\u2019utente mirato, quindi l\u2019attacco ha ancora successo.<\/p>\n\n\n\n Escalation del privilegio orizzontale a verticale<\/strong><\/p>\n\n\n\n Spesso, un attacco di escalation del privilegio orizzontale pu\u00f2 essere trasformato in un\u2019escalation del privilegio verticale, compromettendo un utente pi\u00f9 privilegiato. Ad esempio, un\u2019escalation orizzontale potrebbe consentire a un utente malintenzionato di ripristinare o catturare la password appartenente a un altro utente. Se l\u2019attaccante si rivolge a un utente amministrativo e compromette il proprio account, pu\u00f2 ottenere un accesso amministrativo e quindi eseguire un\u2019escalation del privilegio verticale.<\/p>\n\n\n\n Un utente malintenzionato potrebbe essere in grado di accedere alla pagina dell\u2019account di un altro utente utilizzando la tecnica di manomissione dei parametri gi\u00e0 descritta per l\u2019escalation del privilegio orizzontale:<\/p>\n\n\n\n Se l\u2019utente target \u00e8 un amministratore dell\u2019applicazione, l\u2019attaccante otterr\u00e0 l\u2019accesso a una pagina dell\u2019account amministrativo. Questa pagina potrebbe divulgare la password dell\u2019amministratore o fornire un mezzo per modificarla o fornire accesso diretto alla funzionalit\u00e0 privilegiata.<\/p>\n\n\n\n Lab-https:\/\/portswigger.net\/web-security\/access-control\/lab-user-id-controlled-by-request-parameter-with-password-disclosure<\/a><\/p>\n\n\n\n Riferimenti di oggetti diretti insicuri<\/strong><\/p>\n\n\n\n I riferimenti a oggetti diretti insicuri (Insecure direct object references – IDORS) sono una sottocategoria di vulnerabilit\u00e0 di controllo degli accessi. Gli IDOR si verificano se un\u2019applicazione utilizza l\u2019input fornito dall\u2019utente per accedere direttamente agli oggetti e un utente malintenzionato pu\u00f2 modificare l\u2019input per ottenere un accesso non autorizzato. \u00c8 stato reso popolare dalla sua apparizione nella Top Ten Owasp 2007. \u00c8 solo un esempio di molti errori di implementazione che possono fornire un mezzo per aggirare i controlli di accesso.<\/p>\n\n\n\n Lab-https:\/\/portswigger.net\/web-security\/access-control\/lab-insecure-direct-object-references<\/a><\/p>\n\n\n\n Vulnerabilit\u00e0 di controllo degli accessi nei processi in pi\u00f9 fasi<\/strong><\/p>\n\n\n\n Molti siti Web implementano funzioni importanti su una serie di passaggi. Questo \u00e8 comune quando:<\/p>\n\n\n\n Ad esempio, la funzione amministrativa per aggiornare i dettagli dell\u2019utente potrebbe coinvolgere i seguenti passaggi:<\/p>\n\n\n\n A volte, un sito Web implementer\u00e0 rigorosi controlli di accesso su alcuni di questi passaggi, ma ignorer\u00e0 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\u00e0 completato i primi passi, che sono correttamente controllati. Un utente malintenzionato pu\u00f2 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.<\/p>\n\n\n\n Lab-https:\/\/portswigger.net\/web-security\/access-control\/lab-multi-step-process-with-no-access-control-on-one-step<\/a><\/p>\n\n\n\n Controllo degli accessi basato sui Referer<\/strong><\/p>\n\n\n\n Alcuni siti Web basano controlli di accesso sull\u2019intestazione del Ad esempio, un\u2019applicazione applica abilmente il controllo dell\u2019accesso sulla pagina amministrativa principale In questo caso, l\u2019intestazione del Lab-https:\/\/portswigger.net\/web-security\/access-control\/lab-referer-based-access-control<\/a><\/p>\n\n\n\n Controllo dell\u2019accesso basato sulla posizione<\/strong><\/p>\n\n\n\n Alcuni siti Web applicano i controlli di accesso in base alla posizione geografica dell\u2019utente. Ci\u00f2 pu\u00f2 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\u2019uso di proxy Web, VPN o manipolazione dei meccanismi di geolocalizzazione sul lato client.<\/p>\n\n\n\n Come prevenire le vulnerabilit\u00e0 del controllo degli accessi<\/strong><\/p>\n\n\n\n Le vulnerabilit\u00e0 di controllo degli accessi possono essere prevenute adottando un approccio di difesa in profondit\u00e0 e applicando i seguenti principi:<\/p>\n\n\n\n PortSwigger Academy \u2013 Access control vulnerabilities and privilege escalation Continua il percorso di apprendimento suggerito da \u201cPortSwigger Academy\u201d. Access control vulnerabilities and privilege escalation In questa sezione descriviamo: Cos\u2019\u00e8 il controllo degli accessi? Il controllo degli accessi \u00e8 l\u2019applicazione di vincoli su chi o cosa \u00e8 autorizzato a eseguire azioni o accedere alle risorse. Nel … Leggi tutto “Access control vulnerabilities and privilege escalation”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":0,"footnotes":""},"categories":[5,15],"tags":[],"class_list":["post-2070","post","type-post","status-publish","format-standard","hentry","category-burp-suite","category-ethical-hacking"],"_links":{"self":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts\/2070","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/comments?post=2070"}],"version-history":[{"count":17,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts\/2070\/revisions"}],"predecessor-version":[{"id":2088,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts\/2070\/revisions\/2088"}],"wp:attachment":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/media?parent=2070"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/categories?post=2070"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/tags?post=2070"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\n
\n
![\"\"\/](\"https:\/\/lh7-rt.googleusercontent.com\/docsz\/AD_4nXcjXpdI52EERajoObjDtPVUcvMiQFxwVrUVmp0nORILEl8WVPd_rAJkT3sst8DvyLftAKRYy6WOTVGVgJWx2co8qlnuyrtl0HU2wGc8OCEq3XE4Pvx8-HXozYzVroWVZJIBuO2QTQ?key=IblbPG_0FX_5pVHjz1yNo7ph\")
https://insecure-website.com\/admin<\/code><\/pre>\n\n\n\nrobots.txt<\/code>:<\/p>\n\n\n\nhttps://insecure-website.com\/robots.txt<\/code><\/pre>\n\n\n\nhttps://insecure-website.com\/administrator-panel-yb556<\/code><\/pre>\n\n\n\n<script>\n\tvar isAdmin = false;\n\tif (isAdmin) {\n\t\t...\n\t\tvar adminPanelTag = document.createElement('a');\n\t\tadminPanelTag.setAttribute('href', 'https:\/\/insecure-website.com\/administrator-panel-yb556');\n\t\tadminPanelTag.innerText = 'Admin panel';\n\t\t...\n\t}\n<\/script><\/code><\/pre>\n\n\n\n\n
https://insecure-website.com\/login\/home.jsp?admin=true\nhttps:\/\/insecure-website.com\/login\/home.jsp?role=1<\/code><\/pre>\n\n\n\nDENY: POST, \/admin\/deleteUser, managers<\/code><\/p>\n\n\n\nPOST<\/code> sull\u2019URL \/admin\/deleteUser<\/code>, per gli utenti nel gruppo managers. Varie cose possono andare storte in questa situazione, portando al bypass del controllo dell\u2019accesso.<\/p>\n\n\n\nX-Original-URL<\/code> e X-Rewrite-URL<\/code>. Se un sito Web utilizza rigorosi controlli front-end per limitare l\u2019accesso in base all\u2019URL, ma l\u2019applicazione consente di essere sovrascritto dall\u2019URL tramite un\u2019intestazione di richiesta, potrebbe essere possibile bypassare i controlli di accesso utilizzando una richiesta come la seguente:<\/p>\n\n\n\nPOST \/ HTTP\/1.1\nX-Original-URL: \/admin\/deleteUser\n...<\/code><\/pre>\n\n\n\nGET<\/code> (o un altro) per eseguire azioni su un URL limitato, pu\u00f2 bypassare il controllo di accesso implementato sul livello della piattaforma.<\/p>\n\n\n\n\/ADMIN \/DELETEUSER<\/code> pu\u00f2 ancora essere mappata all\u2019endpoint \/admin\/deleteUser<\/code>. Se il meccanismo di controllo dell\u2019accesso \u00e8 meno tollerante, pu\u00f2 trattarli come due diversi endpoint e non far rispettare le restrizioni corrette di conseguenza.<\/p>\n\n\n\nuseSuffixPatternMatch<\/code>. Ci\u00f2 consente ai percorsi con un\u2019estensione di file arbitraria di essere mappata su un endpoint equivalente senza estensione del file. In altre parole, una richiesta a \/admin\/deleteUser.anything<\/code> corrisponderebbe comunque al modello \/admin\/deleteUser<\/code>. Prima di Spring 5.3, questa opzione \u00e8 abilitata per impostazione predefinita.<\/p>\n\n\n\n\/admin\/deleteUser <\/code>e \/admin\/deleteUser\/<\/code> sono trattati come endpoint distinti. In questo caso, potresti essere in grado di bypassare i controlli di accesso aggiungendo una barra finale sul percorso.<\/p>\n\n\n\nhttps://insecure-website.com\/myaccount?id=123<\/code><\/pre>\n\n\n\nid<\/code> a quello di un altro utente, potrebbe accedere alla pagina dell\u2019account di un altro utente e ai dati e alle funzioni associati.<\/p>\n\n\n\nhttps://insecure-website.com\/myaccount?id=456<\/code><\/pre>\n\n\n\n\n
\n
Referer<\/code> inviati nella richiesta HTTP. L\u2019intestazione del Referer<\/code> pu\u00f2 essere aggiunta alle richieste dei browser per indicare quale pagina ha avviato una richiesta.<\/p>\n\n\n\n\/admin<\/code>, ma per le sottopagine come \/admin \/deleteUser<\/code> ispeziona solo l\u2019intestazione del Referer<\/code>. Se l\u2019intestazione del Referer<\/code> contiene l\u2019URL principale \/admin<\/code>, \u00e8 consentita la richiesta.<\/p>\n\n\n\nReferer<\/code> pu\u00f2 essere completamente controllata da un aggressore. Ci\u00f2 significa che possono forgiare richieste dirette alle secondarie sottopagine sensibili fornendo l\u2019intestazione del Referer <\/code>richiesto e ottenere un accesso non autorizzato.<\/p>\n\n\n\n\n