it-swarm.com.de

So nutzen Sie HTTP-Methoden

Viele Sicherheitsscanner wie nikto , nessus , nmap und w3af zeigen manchmal, dass bestimmte HTTP-Methoden wie HEAD, GET , POST, PUT, DELETE, TRACE, OPTIONEN, CONNECT usw. sind anfällig für Angriffe.

Was machen diese Header und wie können sie ausgenutzt werden?

Ich sehe etwas kreativer aus als übliche Exploits wie POST oder GET-Injektionen (z. B. geänderte Felder). Es würde mir helfen zu verstehen, wenn Ihre Antwort mir ein kurzes Beispiel für die normale Verwendung von zeigt der Header im Vergleich zu einer Exploit-Technik eines Headers.

58
Digital fire

Einige dieser Methoden sind in der Regel gefährlich, und andere sind in einer Produktionsumgebung nur irrelevant, was als zusätzliche Angriffsfläche angesehen werden kann. Trotzdem lohnt es sich, diese auch auszuschalten, da Sie sie wahrscheinlich nicht brauchen werden:

  • HEAD, GET, POST, CONNECT - diese sind absolut sicher, zumindest was die HTTP-Methode selbst betrifft. Natürlich kann die Anfrage selbst schädliche Parameter haben, aber das ist etwas anderes als die Methode ... Dies sind normalerweise (Ausnahme unten beachten) die einzigen, die aktiviert werden sollten.
  • PUT, DELETE - Wie von @Justin erwähnt, waren diese Methoden ursprünglich als Dateiverwaltungsvorgänge gedacht.
    Einige Webserver unterstützen diese weiterhin in ihrem ursprünglichen Format. Das heißt, Sie können Dateien beliebig im Dateisystem des Servers ändern oder löschen. Wenn diese aktiviert sind, können Sie natürlich gefährliche Angriffe ausführen.
    Dateizugriffsberechtigungen sollten sehr streng eingeschränkt sein, wenn Sie diese Methoden unbedingt aktivieren MÜSSEN. Aber Sie sollten es sowieso nicht tun - heutzutage gibt es einfache Skripte, die Sie verwenden können (wenn es sich um eine statische Website handelt - wenn es sich um eine tatsächliche Anwendung handelt, codieren Sie sie einfach selbst), um diese Funktion bei Bedarf zu unterstützen.
    HINWEIS: Ein gültiges Szenario zum Aktivieren dieser Methoden (PUT und DELETE) besteht darin, dass Sie eine streng RESTful API oder einen Dienst entwickeln. In diesem Fall wird die Methode jedoch von Ihrem Anwendungscode und nicht vom Webserver verarbeitet.

  • OPTIONEN - Dies ist eine Diagnosemethode, die eine Nachricht zurückgibt, die hauptsächlich zum Debuggen und dergleichen nützlich ist. Diese Nachricht gibt überraschenderweise an, welche HTTP-Methoden auf dem Webserver aktiv sind. In der Realität wird dies heutzutage nur noch selten für legitime Zwecke verwendet, aber es gewährt einem potenziellen Angreifer eine wenig Hilfe: Es kann als Abkürzung angesehen werden, um ein anderes Loch zu finden.
    Nun, dies ist an sich keine wirkliche Verwundbarkeit; Da es jedoch keine wirkliche Verwendung gibt, wirkt es sich nur auf Ihre Angriffsfläche aus und sollte im Idealfall deaktiviert werden.
    HINWEIS: Trotz alledem wird die OPTIONS-Methode IS wird heutzutage für mehrere legitime Zwecke verwendet, zum Beispiel einige REST APIs erfordern eine OPTIONS-Anforderung, CORS) erfordert Anforderungen vor dem Flug und so weiter. Es gibt also definitiv Szenarien, in denen OPTIONEN aktiviert werden sollten, aber die Standardeinstellung sollte weiterhin "deaktiviert sein, sofern nicht erforderlich".

  • TRACE - dies ist die überraschende ... Wieder eine Diagnosemethode (wie @Jeff erwähnt), die im Antworttext die gesamte HTTP-Anfrage zurückgibt. Dies umfasst den Anforderungshauptteil, aber auch die Anforderungsheader, einschließlich z. Cookies, Autorisierungsheader und mehr.
    Nicht allzu überraschend, dies kann erheblich missbraucht werden, wie der klassische Cross-Site Tracing (XST) Angriff, bei dem ein XSS-Vektor verwendet werden kann, um HttpOnly-Cookies, Autorisierungsheader, abzurufen. und derartige. Dies sollte definitiv deaktiviert sein.

  • Eine andere Reihe von Methoden muss erwähnt werden: ALLE ANDEREN . Bei einigen Webservern legen Sie bestimmte HTTP-Methoden explizit auf die eine oder andere Weise in der Konfigurationsdatei fest, um sie zu aktivieren/deaktivieren/einzuschränken. Wenn jedoch keine Standardeinstellung festgelegt ist, können möglicherweise zusätzliche Methoden "eingefügt" werden, wobei bestimmte Zugriffskontrollen umgangen werden, die der Webserver möglicherweise (schlecht) implementiert hat. Siehe zum Beispiel einige weitere Informationen zu OWASP .

46
AviD

Mit der PUT-Methode können Sie jede Datei auf den Server hochladen. Dies kann verwendet werden, um Cross Site Scripting (XSS) durchzuführen. Heute habe ich diesen Angriff ausgeführt und hier mit meiner Erfahrung geantwortet. Wie Sie dies tun, wird unten erklärt.

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) 

Der Server antwortet mit einem Statuscode 201, der besagt, dass die Datei erfolgreich erstellt wurde.

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

Jetzt können wir versuchen, im Browser auf diese hochgeladene XSS.html-Datei zuzugreifen. Sobald Sie auf diese Seite zugreifen, erhalten Sie ein XSS-Popup.

Ebenso kann dies weiter ausgenutzt werden, um auch Command Injection durchzuführen, obwohl ich dies noch nicht ausprobiert habe. Wenn die Anwendung XML verwendet, kann auch ein Angriff auf eine externe XML-Entität ausgeführt werden. Havent hat das auch noch getan. Möglicherweise ist auch ein Directory Traversal-Angriff möglich.

4
Dan Rad

Die Hauptwarnung zu TRACE besteht darin, dass das Routing einer HTTP-Anforderung getrennt werden soll, ähnlich wie Traceroute das Routing eines Pakets auseinander nehmen soll. Der Hauptunterschied besteht darin, dass der TRACE-Befehl Operationen im Backend und die Offenlegung der empfangenen Daten umfasst. Dies kann ein Problem sein, wenn Ihr Front-End API-Schlüssel oder ähnliches wie Ihr Backend bereitstellt.

Weitere Informationen zu TRACE sowie Erläuterungen zu anderen Headern finden Sie unter RFC 2616 .

3
Jeff Ferland