Come sfruttare i metodi HTTP

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 extra. Comunque, vale la pena di chiudere anche quelli, dal momento che probabilmente non ne avrai bisogno:

• HEAD, GET, POST, CONNECT - sono completamente sicuri, almeno per quanto riguarda il metodo HTTP stesso. Naturalmente, la richiesta stessa potrebbe avere parametri malevoli, ma questo è separato dal Metodo ... questi sono tipicamente (nota eccezione sotto) 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 supportano ancora questi 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 alcuni attacchi pericolosi.
  Le autorizzazioni per l'accesso ai file dovrebbero essere molto strettamente limitate, se DEVI assolutamente avere questi metodi abilitati. Ma non dovresti, comunque - al giorno d'oggi, ci sono semplici script che puoi usare (se questo è un sito web statico - se è un'applicazione vera e propria, codificalo tu stesso) per supportare questa funzione se ne hai bisogno.
  NOTA: uno scenario valido per abilitare questi metodi (PUT e DELETE) è se si sta sviluppando un'API o un servizio rigorosamente RESTful ; tuttavia, in questo caso il metodo verrà 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 fondamentalmente riporta, sorprendentemente, quali metodi HTTP sono attivi sul server web. In realtà, questo è usato raramente oggigiorno per scopi legittimi, ma concede a un potenziale aggressore un piccolo piccolo aiuto: può essere considerato una scorciatoia per trovare un altro buco.
  Ora, questo di per sé non è davvero una vulnerabilità; ma dal momento che non c'è un vero uso per questo, influisce solo sulla superficie di attacco, e idealmente dovrebbe essere disabilitato.
  NOTA: nonostante quanto sopra, il metodo OPTIONS viene utilizzato per diversi scopi legittimi al giorno d'oggi, ad esempio alcune API REST richiedono una richiesta OPTIONS, CORS richiede richieste di pre-volo e così via. Quindi ci sono sicuramente degli scenari in cui OPTIONS dovrebbe essere abilitato, ma il default dovrebbe comunque essere "disabilitato se non richiesto".

• TRACE - questo è il sorprendente ... Ancora, un metodo diagnostico (come @Jeff menzionato), che restituisce nel corpo della risposta, l'intera richiesta HTTP. Ciò include il corpo della richiesta, ma anche le intestazioni delle richieste, tra cui ad es. cookie, intestazioni di autorizzazione e altro.
  Non troppo sorprendente, questo può essere sostanzialmente abusato, come il classico Cross-Site Tracing (XST) attacco, in cui un vettore XSS può essere utilizzato per recuperare cookie HttpOnly, intestazioni di autorizzazione e così via. Questo dovrebbe sicuramente essere disabilitato.

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

Utilizzando il metodo PUT, puoi caricare qualsiasi file sul server. Questo può essere usato per eseguire Cross Site Scripting (XSS). Oggi ho eseguito questo attacco, quindi rispondo qui con la mia esperienza. Il modo in cui lo fai è spiegato di seguito.

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 con successo".

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, ottieni un pop-up XSS.

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

L'avvertimento principale su TRACE è che è progettato per separare il routing di una richiesta HTTP simile a come si intende traceroute per separare il routing di un pacchetto. La differenza principale è che il comando TRACE implica 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.

Controlla RFC 2616 per ulteriori informazioni su TRACE e spiegazioni su altre intestazioni.