File upload vulnerabilities<\/strong><\/p>\n\n\n\n In questa sezione, imparerai come le funzioni di caricamento dei file semplici possono essere utilizzate come potente vettore per un numero di attacchi ad alta severit\u00e0. Ti mostreremo come bypassare i meccanismi di difesa comuni per caricare una shell Web, consentendo di prendere il pieno controllo di un server Web vulnerabile. Dato quanto sono comuni le funzioni di caricamento dei file, sapere come testarle correttamente \u00e8 una conoscenza essenziale.<\/p>\n\n\n\n Cosa sono le vulnerabilit\u00e0 del caricamento dei file?<\/strong><\/p>\n\n\n\n Le vulnerabilit\u00e0 di caricamento dei file sono quando un server Web consente agli utenti di caricare file sul proprio filesystem senza convalidare sufficientemente cose come il loro nome, tipo, contenuto o dimensione. Non riuscire a far rispettare correttamente le restrizioni su questi potrebbe significare che anche una funzione di caricamento di base di immagini pu\u00f2 essere utilizzata per caricare file arbitrari e potenzialmente pericolosi. Ci\u00f2 potrebbe anche includere file di script lato server che abilitano l\u2019esecuzione del codice remoto.<\/p>\n\n\n\n In alcuni casi, l\u2019atto di caricare il file \u00e8 di per s\u00e9 abbastanza da causare danni. Altri attacchi possono comportare una richiesta HTTP di follow-up per il file, in genere per attivare la sua esecuzione da parte del server.<\/p>\n\n\n\n Qual \u00e8 l\u2019impatto delle vulnerabilit\u00e0 del caricamento dei file?<\/strong><\/p>\n\n\n\n L\u2019impatto delle vulnerabilit\u00e0 del caricamento dei file dipende generalmente da due fattori chiave:<\/p>\n\n\n\n Nel peggiore dei casi, il tipo del file non \u00e8 validato correttamente e la configurazione del server consente di eseguire alcuni tipi di file (come Se il nome file non \u00e8 validato correttamente, ci\u00f2 potrebbe consentire a un utente malintenzionato di sovrascrivere i file critici semplicemente caricando un file con lo stesso nome. Se anche il server \u00e8 vulnerabile al directory traversal<\/em>, ci\u00f2 potrebbe significare che gli aggressori sono persino in grado di caricare file in posizioni impreviste.<\/p>\n\n\n\n Non riuscire a assicurarsi che la dimensione del file rientri all\u2019interno delle soglie previste potrebbe anche consentire una forma di attacco di denial-of-service<\/em> (DOS), per cui l\u2019attaccante riempie lo spazio del disco disponibile.<\/p>\n\n\n\n Come sorgono le vulnerabilit\u00e0 del caricamento dei file?<\/strong><\/p>\n\n\n\n Dati i pericoli abbastanza ovvi, \u00e8 raro che i siti Web in natura non abbiano alcuna restrizione su quali file gli utenti possono caricare. Pi\u00f9 comunemente, gli sviluppatori implementano ci\u00f2 che ritengono essere una convalida robusta che \u00e8 intrinsecamente imperfetta o pu\u00f2 essere facilmente bypassata.<\/p>\n\n\n\n Ad esempio, possono tentare una blacklist per tipi di file pericolosi, ma non riescono a tenere conto delle discrepanze di analisi durante il controllo delle estensioni del file. Come con qualsiasi lista nera, \u00e8 anche facile omettere accidentalmente tipi di file pi\u00f9 oscuri che possono essere ancora pericolosi.<\/p>\n\n\n\n In altri casi, il sito Web pu\u00f2 tentare di verificare il tipo di file verificando le propriet\u00e0 che possono essere facilmente manipolate da un utente malintenzionato utilizzando strumenti come il Proxy o il Repeater di Burp.<\/p>\n\n\n\n In definitiva, anche robuste misure di convalida possono essere applicate in modo incoerente attraverso la rete di host e directory che formano il sito Web, con conseguenti discrepanze che possono essere sfruttate.<\/p>\n\n\n\n In che modo i server Web gestiscono le richieste per i file statici?<\/strong><\/p>\n\n\n\n Prima di esaminare come sfruttare i file caricare le vulnerabilit\u00e0, \u00e8 importante avere una comprensione di base di come i server gestiscono le richieste per i file statici.<\/p>\n\n\n\n Storicamente, i siti Web consistevano quasi interamente da file statici che sarebbero stati serviti agli utenti quando richiesti. Di conseguenza, il percorso di ciascuna richiesta potrebbe essere mappato 1: 1 con la gerarchia di directory e file sul filesystem del server. Al giorno d\u2019oggi, i siti Web sono sempre pi\u00f9 dinamici e il percorso di una richiesta spesso non ha alcuna relazione diretta al filesystem. Tuttavia, i server Web affrontano ancora le richieste per alcuni file statici, inclusi fogli di stile, immagini e cos\u00ec via.<\/p>\n\n\n\n Il processo per la gestione di questi file statici \u00e8 ancora in gran parte lo stesso. Ad un certo punto, il server analizza il percorso nella richiesta di identificare l\u2019estensione del file. Quindi lo utilizza per determinare il tipo di file richiesto, in genere confrontandolo con un elenco di mappature preconfigurate tra estensioni e tipi di mime. Cosa succede dopo dipende dal tipo di file e dalla configurazione del server.<\/p>\n\n\n\n L\u2019intestazione di risposta del Exploiting dell\u2019upload di file senza restrizioni per distribuire Web shell <\/strong><\/p>\n\n\n\n Dal punto di vista della sicurezza, lo scenario peggiore \u00e8 quando un sito Web consente di caricare script sul lato server, come file PHP, Java o Python ed \u00e8 anche configurato per eseguirli come codice. Questo rende banale creare la tua shell web sul server.<\/p>\n\n\n\n Nota<\/strong><\/p>\n\n\n\n Una Web shell \u00e8 uno script dannoso che consente a un utente malintenzionato di eseguire comandi arbitrari su un server Web remoto semplicemente inviando richieste HTTP all\u2019endpoint giusto.<\/p>\n\n\n\n Se sei in grado di caricare correttamente una shell Web, hai effettivamente il pieno controllo sul server. Ci\u00f2 significa che \u00e8 possibile leggere e scrivere file arbitrari, exfiltraere dati sensibili, persino utilizzare il server per aprire gli attacchi contro l\u2019infrastruttura interna e altri server al di fuori della rete. Ad esempio, il seguente PHP One-liner potrebbe essere utilizzato per leggere file arbitrari dal filesystem del server:<\/p>\n\n\n\n Una volta caricato, l\u2019invio di una richiesta per questo file dannoso restituir\u00e0 il contenuto del file di destinazione nella risposta.<\/p>\n\n\n\n Lab-https:\/\/portswigger.net\/web-security\/file-upload\/lab-file-upload-remote-code-execution-via-web-shell-upload<\/a><\/p>\n\n\n\n Una shell web pi\u00f9 versatile pu\u00f2 assomigliare a questa:<\/p>\n\n\n\n Questo script consente di passare un comando di sistema arbitrario tramite un parametro di query come segue:<\/p>\n\n\n\n Exploiting della convalida imperfetta nell\u2019upload di file<\/strong><\/p>\n\n\n\n In natura, \u00e8 improbabile che troverai un sito Web che non ha protezione contro gli attacchi sull\u2019upload dei file come abbiamo visto nel laboratorio precedente. Ma solo perch\u00e9 le difese sono in atto, ci\u00f2 non significa che siano robuste. A volte puoi ancora sfruttare i difetti in questi meccanismi per ottenere una shell Web per l\u2019esecuzione del codice remoto.<\/p>\n\n\n\n Imperfetta convalida del tipo di file <\/strong><\/p>\n\n\n\n Quando si invia i moduli HTML, il browser invia in genere i dati forniti in una richiesta Prendi in considerazione un modulo contenente campi per caricare un\u2019immagine, fornirne una descrizione e inserire il tuo nome utente. L\u2019invio di tale modulo potrebbe comportare una richiesta che assomiglia a questa:<\/p>\n\n\n\n Come puoi vedere, il corpo del messaggio viene diviso in parti separate per ciascuno degli input del modulo. Ogni parte contiene un\u2019intestazione Un modo in cui i siti Web possono tentare di convalidare i caricamenti di file \u00e8 verificare che questa intestazione Lab-https:\/\/portswigger.net\/web-security\/file-upload\/lab-file-upload-web-shell-upload-via-content-type-restriction-bypass<\/a><\/p>\n\n\n\n Prevenire l\u2019esecuzione del file in directory accessibili dall\u2019utente<\/strong><\/p>\n\n\n\n Mentre in primo luogo \u00e8 chiaramente meglio impedire che i tipi di file pericolosi vengano caricati, la seconda linea di difesa \u00e8 impedire al server di eseguire qualsiasi script che \u201cscivolano<\/em>\u201d attraverso la rete.<\/p>\n\n\n\n Per precauzione, i server eseguono generalmente solo script il cui tipo di MIME \u00e8 stato esplicitamente configurato per essere eseguito. Altrimenti, possono restituire una sorta di messaggio di errore o, in alcuni casi, servire invece il contenuto del file come testo semplice:<\/p>\n\n\n\n Questo comportamento \u00e8 potenzialmente interessante a s\u00e9 stante, in quanto pu\u00f2 fornire un modo per carpire il codice sorgente, ma annulla qualsiasi tentativo di creare una shell Web.<\/p>\n\n\n\n Questo tipo di configurazione spesso differisce tra le directory. Una directory a cui vengono caricati i file forniti dall\u2019utente avr\u00e0 probabilmente controlli molto pi\u00f9 severi rispetto ad altre posizioni sul filesystem che si presume siano fuori portata per gli utenti finali. Se riesci a trovare un modo per caricare uno script in una directory diversa che non dovrebbe contenere file forniti dall\u2019utente, il server potrebbe eseguire lo script.<\/p>\n\n\n\n Nota<\/strong><\/p>\n\n\n\n I server Web utilizzano spesso il campo Lab-https:\/\/portswigger.net\/web-security\/file-upload\/lab-file-upload-web-shell-upload-via-path-traversal<\/a><\/p>\n\n\n\n Dovresti inoltre notare che anche se puoi inviare tutte le tue richieste allo stesso nome di dominio, questo spesso indica un server proxy inverso di qualche tipo, come un bilanciamento del carico. Le tue richieste saranno spesso gestite da ulteriori server dietro le quinte, che possono anche essere configurati in modo diverso.<\/p>\n\n\n\n Lista nera di file pericolosi insufficiente <\/strong><\/p>\n\n\n\n Uno dei modi pi\u00f9 ovvi per impedire agli utenti di caricare script dannosi \u00e8 quello di blacklist estensioni di file potenzialmente pericolose come Overriding della configurazione del server<\/strong><\/p>\n\n\n\n Come abbiamo discusso nella sezione precedente, i server in genere non eseguiranno file a meno che non siano stati configurati per farlo. Ad esempio, prima che un server Apache eseguir\u00e0 i file PHP richiesti da un client, gli sviluppatori potrebbero dover aggiungere le seguenti direttive al loro file Molti server consentono inoltre agli sviluppatori di creare file di configurazione speciali all\u2019interno delle singole directory per sovrascrivere o aggiungere a una o pi\u00f9 impostazioni globali. I server Apache, ad esempio, caricheranno una configurazione specifica della directory da un file chiamato Allo stesso modo, gli sviluppatori possono effettuare una configurazione specifica per la directory sui server IIS utilizzando un file I server Web utilizzano questi tipi di file di configurazione quando presenti, ma normalmente non \u00e8 consentito accedervi utilizzando le richieste HTTP. Tuttavia, occasionalmente potresti trovare server che non ti impediscono di caricare il tuo file di configurazione dannoso. In questo caso, anche se l\u2019estensione del file di cui hai bisogno \u00e8 nella lista nera, potresti essere in grado di indurre il server a mappare un\u2019estensione arbitraria e personalizzata su un tipo MIME eseguibile.<\/p>\n\n\n\n Lab-https:\/\/portswigger.net\/web-security\/file-upload\/lab-file-upload-web-shell-upload-via-extension-blacklist-bypass<\/a><\/p>\n\n\n\n Estensioni di file offuscanti<\/strong><\/p>\n\n\n\n Anche le liste nere pi\u00f9 esaustive possono potenzialmente essere bypassate usando le classiche tecniche di offuscamento. Supponiamo che il codice di convalida sia sensibile al caso e non riconosce che Puoi anche ottenere risultati simili utilizzando le seguenti tecniche:<\/p>\n\n\n\n Altre difese prevedono lo stripping o la sostituzione di estensioni pericolose per impedire l\u2019esecuzione del file. Se questa trasformazione non viene applicata in modo ricorsivo, \u00e8 possibile posizionare la stringa proibita in modo tale da rimuoverla lasciando ancora una valida estensione del file. Ad esempio, considera cosa succede se si spoglia Questa \u00e8 solo una piccola selezione dei molti modi in cui \u00e8 possibile offuscare le estensioni dei file.<\/p>\n\n\n\n Lab-https:\/\/portswigger.net\/web-security\/file-upload\/lab-file-upload-web-shell-upload-via-obfuscated-file-extension<\/a><\/p>\n\n\n\n Convalida imperfetta del contenuto del file<\/strong><\/p>\n\n\n\n Invece di fidarsi implicitamente del Nel caso di una funzione di caricamento di una immagine, il server potrebbe provare a verificare alcune propriet\u00e0 intrinseche di un\u2019immagine, come le sue dimensioni. Se provi a caricare uno script PHP, ad esempio, non avr\u00e0 alcuna dimensione. Pertanto, il server pu\u00f2 dedurre che non pu\u00f2 essere un\u2019immagine e rifiutare il caricamento di conseguenza.<\/p>\n\n\n\n Allo stesso modo, alcuni tipi di file possono sempre contenere una sequenza specifica di byte nell\u2019header<\/em> o nel footer<\/em> di pagina. Questi possono essere usati come un\u2019impronta digitale o una firma per determinare se i contenuti corrispondono al tipo previsto. Ad esempio, i file JPEG iniziano sempre con i byte Questo \u00e8 un modo molto pi\u00f9 robusto di convalidare il tipo di file, ma anche questo non \u00e8 infallibile. Utilizzando strumenti speciali, come Exiftool, pu\u00f2 essere banale creare un file JPEG polyglot<\/em> contenente codice dannoso all\u2019interno dei suoi metadati.<\/p>\n\n\n\n Lab-https:\/\/portswigger.net\/web-security\/file-upload\/lab-file-upload-remote-code-execution-via-polyglot-web-shell-upload<\/a><\/p>\n\n\n\n Sfruttamento delle condizioni di caricamento dei file<\/strong><\/p>\n\n\n\n I framework moderni sono pi\u00f9 resistenti contro questo tipo di attacchi. In genere non caricano file direttamente nella destinazione prevista sul filesystem. Invece, prendono precauzioni come il caricamento in una directory temporanea e sandboxing e randomizzando il nome per evitare di sovrascrivere i file esistenti. Quindi eseguono la convalida su questo file temporaneo e lo trasferiscono a destinazione solo una volta considerato sicuro.<\/p>\n\n\n\n Detto questo, gli sviluppatori a volte implementano il proprio processo di caricamento di file indipendentemente da qualsiasi framework. Non solo \u00e8 abbastanza complesso da implementare bene, ma pu\u00f2 anche introdurre condizioni pericolose che consentono a un aggressore di aggirare completamente anche la convalida pi\u00f9 robusta.<\/p>\n\n\n\n Ad esempio, alcuni siti Web caricano il file direttamente sul filesystem principale e quindi lo rimuovono se non supera la convalida. Questo tipo di comportamento \u00e8 tipico nei siti Web che si basano sul software antivirus e di verifica del malware. Ci\u00f2 pu\u00f2 richiedere solo pochi millisecondi, ma per il breve periodo esiste sul server, l\u2019attaccante pu\u00f2 potenzialmente ancora eseguirlo.<\/p>\n\n\n\n Queste vulnerabilit\u00e0 sono spesso estremamente subdole, il che le rende difficili da rilevare durante i test blackbox, a meno che non si riesca a trovare un modo per far trapelare il codice sorgente pertinente.<\/p>\n\n\n\n Lab-https:\/\/portswigger.net\/web-security\/file-upload\/lab-file-upload-web-shell-upload-via-race-condition<\/a><\/p>\n\n\n\n Race condition nei carichi di file basati su URL<\/strong><\/p>\n\n\n\n Condizioni di corsa simili possono verificarsi in funzioni che consentono di caricare un file fornendo un URL. In questo caso, il server deve recuperare il file su Internet e creare una copia locale prima di poter eseguire qualsiasi convalida.<\/p>\n\n\n\n Poich\u00e9 il file viene caricato utilizzando HTTP, gli sviluppatori non sono in grado di utilizzare i meccanismi integrati del loro framework per la convalida in modo sicuro. Invece, possono creare manualmente i propri processi per archiviare e convalidare temporaneamente il file, che potrebbe non essere cos\u00ec sicuro.<\/p>\n\n\n\n Ad esempio, se il file viene caricato in una directory temporanea con un nome randomizzato, in teoria, dovrebbe essere impossibile per un attaccante sfruttare eventuali condizioni di gara. Se non conoscono il nome della directory, non saranno in grado di richiedere il file per attivare la sua esecuzione. D\u2019altra parte, se il nome della directory randomizzato viene generato utilizzando funzioni pseudo-casuali come Per semplificare gli attacchi come questo, puoi provare a prolungare il tempo impiegato per elaborare il file, allungando cos\u00ec la finestra per il brute-forcing del nome della directory. Un modo per farlo \u00e8 caricare un file pi\u00f9 grande. Se viene elaborato in blocchi, puoi potenzialmente trarne vantaggio creando un file dannoso con il carico utile all\u2019inizio, seguito da un gran numero di byte arbitrari di imbottitura.<\/p>\n\n\n\n Sfruttare le vulnerabilit\u00e0 del caricamento dei file senza esecuzione del codice remoto<\/strong><\/p>\n\n\n\n Negli esempi che abbiamo esaminato finora, siamo stati in grado di caricare script sul lato server per l\u2019esecuzione del codice remoto. Questa \u00e8 la conseguenza pi\u00f9 grave di una funzione di upload di file insicuri, ma queste vulnerabilit\u00e0 possono ancora essere sfruttate in altri modi.<\/p>\n\n\n\n Caricamento di script dannoso lato client <\/strong><\/p>\n\n\n\n Sebbene potresti non essere in grado di eseguire script sul server, potresti comunque essere in grado di caricare script per gli attacchi sul lato client. Ad esempio, se \u00e8 possibile caricare file HTML o immagini SVG, \u00e8 possibile utilizzare potenzialmente i tag Se il file caricato viene quindi visualizzato in una pagina visitata da altri utenti, il loro browser eseguir\u00e0 lo script quando tenta di visualizzare la pagina. Si noti che a causa delle restrizioni delle politiche della stessa origine, questi tipi di attacchi funzionano solo se il file caricato viene servito dalla stessa origine a cui lo si carica.<\/p>\n\n\n\n Sfruttando le vulnerabilit\u00e0 nell\u2019analisi di file caricati<\/strong><\/p>\n\n\n\n Se il file caricato sembra essere archiviato e servito in modo sicuro, l\u2019ultima risorsa \u00e8 provare a sfruttare le vulnerabilit\u00e0 specifiche per l\u2019analisi o l\u2019elaborazione di diversi formati di file. Ad esempio, sai che il server analizza i file basati su XML, come i file Microsoft Office Caricamento di file utilizzando PUT<\/strong><\/p>\n\n\n\n Vale la pena notare che alcuni server Web potrebbero essere configurati per supportare le richieste Nota<\/strong><\/p>\n\n\n\n \u00c8 possibile provare a inviare richieste Come prevenire le vulnerabilit\u00e0 del caricamento dei file<\/strong><\/p>\n\n\n\n Consentire agli utenti di caricare file \u00e8 all\u2019ordine del giorno e non deve essere pericoloso fintanto che prendi le precauzioni giuste. In generale, il modo pi\u00f9 efficace per proteggere i propri siti Web da queste vulnerabilit\u00e0 \u00e8 implementare tutte le seguenti pratiche:<\/p>\n\n\n\n PortSwigger Academy – File upload vulnerabilities Continua il percorso di apprendimento suggerito da \u201cPortSwigger Academy\u201d. File upload vulnerabilities In questa sezione, imparerai come le funzioni di caricamento dei file semplici possono essere utilizzate come potente vettore per un numero di attacchi ad alta severit\u00e0. Ti mostreremo come bypassare i meccanismi di difesa comuni per caricare … Leggi tutto “File upload vulnerabilities”<\/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-2091","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\/2091","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=2091"}],"version-history":[{"count":14,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts\/2091\/revisions"}],"predecessor-version":[{"id":2106,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts\/2091\/revisions\/2106"}],"wp:attachment":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/media?parent=2091"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/categories?post=2091"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/tags?post=2091"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}![\"\"\/](\"https:\/\/lh7-rt.googleusercontent.com\/docsz\/AD_4nXdQ_aDDtdrIirU5I1NNxFccdJx7Eg0V5fwnryPxj623TJp3X88Y0Mi7tIx3YEyY5IWkGGszARSqYbb1K8mYOzRQWtnV_m0imF9cRDt4dldr4g_m-TNVBW78ZrZ3TBZEp-FUt0X_Yg?key=5bHMLNELaEZwwjzcqBh2zPC4\")
\n
.php<\/code> e .jsp<\/code>) come codice. In questo caso, un utente malintenzionato potrebbe potenzialmente caricare un file di codice lato server che funziona come una shell Web, concedendo loro efficacemente il pieno controllo sul server.<\/p>\n\n\n\n\n
Content-Type<\/code> pu\u00f2 fornire indizi sul tipo di file che il server pensa di aver servito. Se questa intestazione non \u00e8 stata esplicitamente impostata dal codice dell\u2019applicazione, normalmente contiene il risultato della mappatura del tipo di extension\/MIME.<\/p>\n\n\n\n<?php echo file_get_contents(\u2019\/path\/to\/target\/file\u2019); ?><\/code><\/p>\n\n\n\n<?php echo system($_GET[\u2019command\u2019]); ?><\/code><\/p>\n\n\n\nGET \/example\/exploit.php?command=id HTTP\/1.1<\/code><\/p>\n\n\n\nPOST<\/code> con il content type<\/em> application\/x-www-form-url-encoded<\/code>. Va bene per inviare un testo semplice come il tuo nome o indirizzo. Tuttavia, non \u00e8 adatto per l\u2019invio di grandi quantit\u00e0 di dati binari, come un intero file di immagine o un documento PDF. In questo caso, \u00e8 preferito il content type<\/em> multipart\/form-data<\/code>.<\/p>\n\n\n\nPOST \/images HTTP\/1.1\n Host: normal-website.com\n Content-Length: 12345\n Content-Type: multipart\/form-data; boundary=---------------------------012345678901234567890123456\n\n ---------------------------012345678901234567890123456\n Content-Disposition: form-data; name=\"image\"; filename=\"example.jpg\"\n Content-Type: image\/jpeg\n\n [...binary content of example.jpg...]\n\n ---------------------------012345678901234567890123456\n Content-Disposition: form-data; name=\"description\"\n\n This is an interesting description of my image.\n\n ---------------------------012345678901234567890123456\n Content-Disposition: form-data; name=\"username\"\n\n wiener\n ---------------------------012345678901234567890123456--<\/code><\/pre>\n\n\n\nContent-Disposition<\/code>, che fornisce alcune informazioni di base sul campo di input a cui si riferisce. Queste singole parti possono anche contenere la propria intestazione Content-Type<\/code>, che indica al server il tipo MIME dei dati inviati utilizzando questo input.<\/p>\n\n\n\nContent-Type<\/code> specifica per input corrisponda a un tipo MIME previsto. Se il server si aspetta solo file di immagini, ad esempio, pu\u00f2 consentire solo tipi come image\/jpeg<\/code> e image\/png<\/code>. I problemi possono sorgere quando il valore di questa intestazione \u00e8 implicitamente affidabile dal server. Se non viene eseguita alcuna ulteriore convalida per verificare se il contenuto del file corrisponde effettivamente al presunto tipo di MIME, questa difesa pu\u00f2 essere facilmente bypassata usando strumenti come Burp Repeater.<\/p>\n\n\n\nGET \/static\/exploit.php?command=id HTTP\/1.1\n Host: normal-website.com\n\n\n HTTP\/1.1 200 OK\n Content-Type: text\/plain\n Content-Length: 39\n\n <?php echo system($_GET['command']); ?><\/code><\/pre>\n\n\n\nfilename<\/code> nelle richieste multipart\/form-data<\/code> per determinare il nome e la posizione in cui il file deve essere salvato.<\/p>\n\n\n\n.php<\/code>. La pratica della lista nera \u00e8 intrinsecamente imperfetta in quanto \u00e8 difficile bloccare esplicitamente ogni possibile estensione di file che potrebbe essere utilizzata per eseguire il codice. Tali liste nere a volte possono essere bypassate utilizzando estensioni di file alternative meno note che possono essere ancora eseguibili, come .php5<\/code>, .shtml<\/code> e cos\u00ec via.<\/p>\n\n\n\n\/etc\/apache2\/apache2.conf<\/code>:<\/p>\n\n\n\nLoadModule php_module \/usr\/lib\/apache2\/modules\/libphp.so\n AddType application\/x-httpd-php .php<\/code><\/pre>\n\n\n\n.htaccess<\/code> se uno \u00e8 presente.<\/p>\n\n\n\nweb.config<\/code>. Ci\u00f2 potrebbe includere direttive come le seguenti, che in questo caso consente di servire i file JSON agli utenti:<\/p>\n\n\n\n<staticContent>\n <mimeMap fileExtension=\".json\" mimeType=\"application\/json\" \/>\n <\/staticContent><\/code><\/pre>\n\n\n\nexploit.pHp<\/code> \u00e8 in realt\u00e0 un file .php<\/code>. Se il codice che successivamente mappa l\u2019estensione del file su un tipo MIME non<\/strong> \u00e8 case sensitive<\/em>, questa discrepanza consente a file PHP dannosi di sgattaiolare la convalida e alla fine essere eseguito dal server.<\/p>\n\n\n\n\n
exploit.php.jpg<\/code>;<\/li>\n\n\n\nexploit.php<\/code>;<\/li>\n\n\n\nexploit%2Ephp<\/code>;<\/li>\n\n\n\nexploit.asp<\/code>, .jpg<\/code> o exploit.asp%00.jpg<\/code>;<\/li>\n\n\n\nxC0 x2E<\/code>, xC4 xAE<\/code> or xC0 xAE<\/code> possono essere tradotte in x2E se il filename \u00e8 analizzato come stringa UTF-8, ma poi convertito in caratteri ASCII prima di essere utilizzato in un percorso.<\/li>\n<\/ul>\n\n\n\n.php<\/code> dal seguente nome file:<\/p>\n\n\n\nexploit.p.php<\/mark>hp<\/code><\/p>\n\n\n\nContent-Type<\/code> specificato in una richiesta, i server pi\u00f9 sicuri cercano di verificare che il contenuto del file corrisponda effettivamente a ci\u00f2 che \u00e8 previsto.<\/p>\n\n\n\nFF D8 FF<\/code>.<\/p>\n\n\n\nuniqid()<\/code> di PHP, pu\u00f2 potenzialmente essere rafforzato.<\/p>\n\n\n\n<script><\/code> per creare payload XSS archiviati.<\/p>\n\n\n\n.doc<\/code> o .xls<\/code>, questo potrebbe essere un potenziale vettore per gli attacchi di iniezione XXE.<\/p>\n\n\n\nPUT<\/code>. Se non sono in atto difese appropriate, ci\u00f2 pu\u00f2 fornire un mezzo alternativo per caricare file dannosi, anche quando una funzione di caricamento non \u00e8 disponibile tramite l\u2019interfaccia Web.<\/p>\n\n\n\nPUT \/images\/exploit.php HTTP\/1.1\nHost: vulnerable-website.com\nContent-Type: application\/x-httpd-php\nContent-Length: 49\n\n<?php echo file_get_contents('\/path\/to\/file'); ?><\/code><\/pre>\n\n\n\nOPTIONS<\/code> a endpoint diversi per testare qualsiasi supporto per pubblicizzare per il metodo PUT<\/code>.<\/p>\n\n\n\n\n
..\/<\/code>);<\/li>\n\n\n\n