Host Header Attack - Avvelenamento della reimpostazione della password - API Web ASP.NET 2 ospitata come servizi di app di Azure

Question

Host Header Attack - Avvelenamento della reimpostazione della password - API Web ASP.NET 2 ospitata come servizi di app di Azure

#1 da (0 voti)

0

Attualmente sto testando un sito in cui viene utilizzata l'intestazione host per la creazione di un link email di ripristino. Tuttavia, quando provo a manipolare l'intestazione host in Burp, ottengo un messaggio HTTP 400 che dice che sto usando un nome host non valido. Ottengo questo errore anche se provo a manomettere l'intestazione host per GET / o qualsiasi altra richiesta.

Il mio pensiero iniziale era che, essendo un servizio app su Azure, l'host non era stato trovato e non aveva alcun binding sul server e quindi non funzionava. Tuttavia, sullo stesso server del servizio app, c'è un'altra applicazione ospitata su cui mi è stato permesso di testare. Quando ho aggiunto un'intestazione host che conosco esiste su quel server, ricevo comunque lo stesso errore HTTP 400.

Che cosa sta facendo Microsoft per impedirlo?

Ping verificando che i domini si trovino sullo stesso server:

Esempiodirichiesta,modificadihostedestinazionemaentrambiidominisitrovanosullostessoserver.

Ilmessaggioèsemprelostesso:

HTTP/1.1400BadRequestContent-Type:text/html;charset=us-asciiServer:Microsoft-HTTPAPI/2.0Date:Fri,06Oct201707:28:25GMTConnection:closeContent-Length:334<!DOCTYPEHTMLPUBLIC"-//W3C//DTD HTML 4.01//EN""http://www.w3.org/TR/html4/strict.dtd">
<HTML><HEAD><TITLE>Bad Request</TITLE>
<META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii"></HEAD>
<BODY><h2>Bad Request - Invalid Hostname</h2>
<hr><p>HTTP Error 400. The request hostname is invalid.</p>
</BODY></HTML>

Posso aggiungere una X-Forwarded-Host: mydomain.com alla richiesta e passerà attraverso ma non raccoglierò l'intestazione come host.

link

injection burp-suite

posta Ogglas 06.10.2017 - 09:49

fonte

1 risposta

Leggi altre domande sui tag injection burp-suite

Archiviazione chiave di crittografia per l'utente medio Mettere un proxy HTTP di fronte a Server 2003 mitiga qualche rischio?

score 0 · Answer 1

Dagli un colpo e rispondi a me stesso. Il codice responsabile dell'invio dell'e-mail è il seguente:

await emailRepository.SendResetPasswordTokenAsync(Url.Action("ResetPassword", "Authentication", new { token.Token }, Request.Url.Scheme), model.Email, token.User.FullName);

La parte vulnerabile è questo bit:

Url.Action("ResetPassword", "Authentication", new { token.Token }, Request.Url.Scheme)

Ho creato un'applicazione sul mio computer e ho provato a creare URL con IIS Express e ho cambiato host e ottenuto lo stesso errore. Penso che questo errore si verifichi perché non esiste alcun binding predefinito e poiché la richiesta viene emessa utilizzando HTTPS. Se cambio la richiesta di utilizzare l'HTTP standard, l'intestazione dell'host viene interpretata e nella richiesta di sotto torno a domain2 .

Comunquel'hoprovatoancheusandoilmioIISlocaleconbindingpercatturaretuttosullaporta80.Usandolostessocodicedell'applicazionevulnerabileeroingradodimanipolarel'host:

Codice:

publicActionResultIndex(){varhost=Request.Headers["host"];

    ViewBag.Title = $"Host: {host} Url Created: {Url.Action("Index", "Home", "", Request.Url.Scheme)}";

    return View();
}