it-swarm-eu.dev

Come sfruttare i metodi HTTP

Molti scanner di sicurezza come nikto , nessus , nmap e w3af a volte mostrano che alcuni metodi HTTP come HEAD, GET , POST, PUT, DELETE, TRACE, OPTIONS, CONNECT, ecc. Sono vulnerabili agli attacchi.

Cosa fanno queste intestazioni e come possono essere sfruttate?

Sto cercando qualcosa di più creativo degli exploit comuni come POST o GET iniezioni (ad esempio, campi modificati). Mi aiuterebbe a capire se la tua risposta mi ha mostrato un breve esempio del normale utilizzo di l'intestazione rispetto a una tecnica di exploit di un'intestazione.

58
Digital fire

Alcuni di questi metodi sono in genere pericolosi da esporre e alcuni sono semplicemente estranei in un ambiente di produzione, che potrebbe essere considerato una superficie di attacco aggiuntiva. Tuttavia, vale la pena chiudere anche quelli, poiché probabilmente non ne avrai bisogno:

  • HEAD, GET, POST, CONNECT: sono completamente sicuri, almeno per quanto riguarda il metodo HTTP stesso. Naturalmente, la richiesta stessa può avere parametri dannosi, ma è separata dal Metodo ... questi sono in genere (nota l'eccezione di seguito) gli unici che dovrebbero essere abilitati.
  • PUT, DELETE - come menzionato da @Justin, questi metodi erano originariamente intesi come operazioni di gestione dei file.
    Alcuni server Web li supportano ancora nel loro formato originale. Cioè, è possibile modificare o eliminare i file dal file system del server, in modo arbitrario. Ovviamente, se questi sono abilitati, ti apre ad alcuni attacchi pericolosi.
    Le autorizzazioni di accesso ai file devono essere molto rigorosamente limitate, se DEVI assolutamente abilitare questi metodi. Ma non dovresti, comunque - al giorno d'oggi, ci sono semplici script che puoi usare (se si tratta di un sito Web statico - se si tratta di un'applicazione reale, codificalo tu stesso) per supportare questa funzione se ne hai bisogno.
    NOTA: uno scenario valido per abilitare questi metodi (PUT e DELETE) è se stai sviluppando un'API o un servizio rigorosamente RESTful ; tuttavia, in questo caso il metodo verrebbe gestito dal codice dell'applicazione e non dal server Web.

  • OPZIONI - questo è un metodo diagnostico, che restituisce un messaggio utile principalmente per il debug e simili. Questo messaggio riporta sostanzialmente, sorprendentemente, quali Metodi HTTP sono attivi sul server web. In realtà, questo è usato raramente al giorno d'oggi per scopi legittimi, ma concede a un potenziale attaccante un piccolo bit di aiuto: può essere considerato una scorciatoia per trovare un altro buco.
    Ora, questo di per sé non è in realtà una vulnerabilità; ma poiché non vi è alcun reale utilizzo, influenza solo la superficie di attacco e idealmente dovrebbe essere disabilitato.
    NOTA: nonostante quanto sopra, il metodo OPTIONS IS oggi utilizzato per diversi scopi legittimi, ad esempio alcune REST richiedono una richiesta OPTIONS, CORS richiede richieste pre-volo e così via, quindi ci sono sicuramente scenari in cui le OPZIONI dovrebbero essere abilitate, ma il valore predefinito dovrebbe comunque essere "disabilitato se non richiesto".

  • TRACE - questo è quello sorprendente ... Ancora una volta, un metodo diagnostico (come menzionato da @Jeff), che ritorna nel corpo della risposta, l'intera richiesta HTTP. Ciò include il corpo della richiesta, ma anche le intestazioni della richiesta, incluso ad es. cookie, intestazioni di autorizzazione e altro.
    Non troppo sorprendente, questo può essere sostanzialmente utilizzato in modo improprio, come il classico attacco Cross-Site Tracing (XST) , in cui un vettore XSS può essere utilizzato per recuperare HttpOnly cookies, header di autorizzazione, e simili. Questo dovrebbe essere sicuramente disabilitato.

  • Un'altra serie di metodi riporta: TUTTI GLI ALTRI . Per alcuni server web, al fine di abilitare/disabilitare/limitare determinati metodi HTTP, li si imposta esplicitamente in un modo o nell'altro nel file di configurazione. Tuttavia, se non viene impostato alcun valore predefinito, è possibile "iniettare" metodi aggiuntivi, ignorando alcuni controlli di accesso che il server Web potrebbe aver implementato (in modo scadente). Vedi ad esempio qualche informazione in più su OWASP .

46
AviD

Utilizzando il metodo PUT, è possibile caricare qualsiasi file sul server. Questo può essere usato per eseguire Cross Site Scripting (XSS). Oggi ho eseguito questo attacco, quindi ho risposto qui con la mia esperienza. Di seguito viene spiegato come.

PUT /XSS.html HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.myblog.com
Accept-Language: en-us
Connection: Keep-Alive
Content-type: text/html
Content-Length: 182
(Input your XSS script here) 

Il server risponde con un codice di stato 201 che dice "il file è stato creato correttamente".

HTTP/1.1 201 Created
Date: Mon, 05 May 2014 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-type: text/html
Content-length: 30
Connection: Closed

Ora possiamo provare ad accedere a questo file XSS.html caricato nel browser. Non appena accedi a questa pagina, ricevi un pop-up XSS.

Allo stesso modo, questo può essere ulteriormente sfruttato per eseguire anche Command Injection, anche se non l'ho ancora provato. Se l'applicazione utilizza XML, è possibile eseguire anche l'attacco di entità esterna XML. Non l'ho ancora fatto. Anche l'attacco di Directory Traversal potrebbe essere possibile.

4
Dan Rad

L'avvertimento principale su TRACE è che è progettato per separare l'instradamento di una richiesta HTTP simile a come traceroute è inteso per separare l'instradamento di un pacchetto. La differenza fondamentale è che il comando TRACE comporta operazioni sul back-end e la divulgazione di ciò che è stato ricevuto. Questo potrebbe essere un problema se il tuo front-end fornisce chiavi API o qualcosa di simile al tuo back-end.

Dai un'occhiata a RFC 2616 per maggiori informazioni su TRACE e spiegazioni su altre intestazioni.

3
Jeff Ferland