Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-22 20:53:37 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/network-services-pentesting/pentesting-web/special-http-headers.md

12 KiB
Raw Blame History

Besondere HTTP-Header

{% hint style="success" %} Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Unterstützen Sie HackTricks
{% endhint %}

Wortlisten & Tools

Header zur Änderung des Standorts

Ändern Sie IP-Quelle:

  • X-Originating-IP: 127.0.0.1
  • X-Forwarded-For: 127.0.0.1
  • X-Forwarded: 127.0.0.1
  • Forwarded-For: 127.0.0.1
  • X-Forwarded-Host: 127.0.0.1
  • X-Remote-IP: 127.0.0.1
  • X-Remote-Addr: 127.0.0.1
  • X-ProxyUser-Ip: 127.0.0.1
  • X-Original-URL: 127.0.0.1
  • Client-IP: 127.0.0.1
  • X-Client-IP: 127.0.0.1
  • X-Host: 127.0.0.1
  • True-Client-IP: 127.0.0.1
  • Cluster-Client-IP: 127.0.0.1
  • Via: 1.0 fred, 1.1 127.0.0.1
  • Connection: close, X-Forwarded-For (Überprüfen Sie die Hop-by-Hop-Header)

Ändern Sie Standort:

  • X-Original-URL: /admin/console
  • X-Rewrite-URL: /admin/console

Hop-by-Hop-Header

Ein Hop-by-Hop-Header ist ein Header, der dafür ausgelegt ist, vom Proxy, der die Anfrage derzeit bearbeitet, verarbeitet und konsumiert zu werden, im Gegensatz zu einem End-to-End-Header.

  • Connection: close, X-Forwarded-For

{% content-ref url="../../pentesting-web/abusing-hop-by-hop-headers.md" %} abusing-hop-by-hop-headers.md {% endcontent-ref %}

HTTP-Anforderungs-Schmuggel

  • Content-Length: 30
  • Transfer-Encoding: chunked

{% content-ref url="../../pentesting-web/http-request-smuggling/" %} http-request-smuggling {% endcontent-ref %}

Cache-Header

Server-Cache-Header:

  • X-Cache in der Antwort kann den Wert miss haben, wenn die Anfrage nicht im Cache war, und den Wert hit, wenn sie im Cache ist
  • Ähnliches Verhalten im Header Cf-Cache-Status
  • Cache-Control gibt an, ob eine Ressource im Cache gespeichert wird und wann die Ressource das nächste Mal wieder im Cache gespeichert wird: Cache-Control: public, max-age=1800
  • Vary wird oft in der Antwort verwendet, um zusätzliche Header anzugeben, die als Teil des Cache-Schlüssels behandelt werden, auch wenn sie normalerweise nicht als Schlüssel verwendet werden.
  • Age definiert die Zeit in Sekunden, die das Objekt im Proxy-Cache war.
  • Server-Timing: cdn-cache; desc=HIT zeigt ebenfalls an, dass eine Ressource im Cache gespeichert wurde

{% content-ref url="../../pentesting-web/cache-deception/" %} cache-deception {% endcontent-ref %}

Lokale Cache-Header:

  • Clear-Site-Data: Header, um anzugeben, welcher Cache entfernt werden soll: Clear-Site-Data: "cache", "cookies"
  • Expires: Enthält Datum/Uhrzeit, wann die Antwort ablaufen soll: Expires: Wed, 21 Oct 2015 07:28:00 GMT
  • Pragma: no-cache dasselbe wie Cache-Control: no-cache
  • Warning: Der Warning allgemeine HTTP-Header enthält Informationen über mögliche Probleme mit dem Status der Nachricht. Mehr als ein Warning-Header kann in einer Antwort erscheinen. Warning: 110 anderson/1.3.37 "Response is stale"

Bedingte Anfragen

  • Anfragen, die diese Header verwenden: If-Modified-Since und If-Unmodified-Since werden nur mit Daten beantwortet, wenn der Antwortheader Last-Modified eine andere Zeit enthält.
  • Bedingte Anfragen, die If-Match und If-None-Match verwenden, nutzen einen Etag-Wert, sodass der Webserver den Inhalt der Antwort sendet, wenn sich die Daten (Etag) geändert haben. Der Etag wird aus der HTTP-Antwort entnommen.
  • Der Etag-Wert wird normalerweise basierend auf dem Inhalt der Antwort berechnet. Zum Beispiel zeigt ETag: W/"37-eL2g8DEyqntYlaLp5XLInBWsjWI" an, dass der Etag der Sha1 von 37 Bytes ist.

Bereichsanfragen

  • Accept-Ranges: Gibt an, ob der Server Bereichsanfragen unterstützt und, falls ja, in welcher Einheit der Bereich ausgedrückt werden kann. Accept-Ranges: <range-unit>
  • Range: Gibt den Teil eines Dokuments an, den der Server zurückgeben soll.
  • If-Range: Erstellt eine bedingte Bereichsanfrage, die nur erfüllt wird, wenn der angegebene Etag oder das Datum mit der entfernten Ressource übereinstimmt. Wird verwendet, um das Herunterladen von zwei Bereichen aus inkompatiblen Versionen der Ressource zu verhindern.
  • Content-Range: Gibt an, wo in einer vollständigen Nachrichtenkörper eine partielle Nachricht gehört.

Informationen zum Nachrichtenkörper

  • Content-Length: Die Größe der Ressource, in dezimalen Bytes.
  • Content-Type: Gibt den Medientyp der Ressource an
  • Content-Encoding: Wird verwendet, um den Komprimierungsalgorithmus anzugeben.
  • Content-Language: Beschreibt die menschliche Sprache(n), die für das Publikum bestimmt sind, sodass es einem Benutzer ermöglicht, entsprechend der bevorzugten Sprache des Benutzers zu unterscheiden.
  • Content-Location: Gibt einen alternativen Standort für die zurückgegebenen Daten an.

Aus der Sicht eines Pentests sind diese Informationen normalerweise "nutzlos", aber wenn die Ressource geschützt ist durch eine 401 oder 403 und Sie einen Weg finden können, um diese Info zu erhalten, könnte dies interessant sein.
Zum Beispiel kann eine Kombination aus Range und Etag in einer HEAD-Anfrage den Inhalt der Seite über HEAD-Anfragen leaken:

  • Eine Anfrage mit dem Header Range: bytes=20-20 und mit einer Antwort, die ETag: W/"1-eoGvPlkaxxP4HqHv6T3PNhV9g3Y" enthält, leakt, dass der SHA1 des Bytes 20 ETag: eoGvPlkaxxP4HqHv6T3PNhV9g3Y ist.

Server-Info

  • Server: Apache/2.4.1 (Unix)
  • X-Powered-By: PHP/5.3.3

Kontrollen

  • Allow: Dieser Header wird verwendet, um die HTTP-Methoden zu kommunizieren, die eine Ressource verarbeiten kann. Zum Beispiel könnte es als Allow: GET, POST, HEAD angegeben werden, was darauf hinweist, dass die Ressource diese Methoden unterstützt.
  • Expect: Wird vom Client verwendet, um Erwartungen zu übermitteln, die der Server erfüllen muss, damit die Anfrage erfolgreich verarbeitet werden kann. Ein häufiges Anwendungsbeispiel ist der Header Expect: 100-continue, der signalisiert, dass der Client beabsichtigt, eine große Datenmenge zu senden. Der Client wartet auf eine 100 (Continue)-Antwort, bevor er mit der Übertragung fortfährt. Dieser Mechanismus hilft, die Netzwerknutzung zu optimieren, indem er auf die Bestätigung des Servers wartet.

Downloads

  • Der Content-Disposition-Header in HTTP-Antworten gibt an, ob eine Datei inline (innerhalb der Webseite) oder als Anhang (heruntergeladen) behandelt werden soll. Zum Beispiel:
Content-Disposition: attachment; filename="filename.jpg"

Dies bedeutet, dass die Datei mit dem Namen "filename.jpg" zum Herunterladen und Speichern vorgesehen ist.

Sicherheitsheader

Content Security Policy (CSP)

{% content-ref url="../../pentesting-web/content-security-policy-csp-bypass/" %} content-security-policy-csp-bypass {% endcontent-ref %}

Trusted Types

Durch die Durchsetzung von Trusted Types über CSP können Anwendungen vor DOM XSS-Angriffen geschützt werden. Trusted Types stellen sicher, dass nur speziell gestaltete Objekte, die den festgelegten Sicherheitsrichtlinien entsprechen, in gefährlichen Web-API-Aufrufen verwendet werden können, wodurch JavaScript-Code standardmäßig gesichert wird.

// Feature detection
if (window.trustedTypes && trustedTypes.createPolicy) {
// Name and create a policy
const policy = trustedTypes.createPolicy('escapePolicy', {
createHTML: str => str.replace(/\</g, '&lt;').replace(/>/g, '&gt;');
});
}

// Assignment of raw strings is blocked, ensuring safety.
el.innerHTML = 'some string'; // Throws an exception.
const escaped = policy.createHTML('<img src=x onerror=alert(1)>');
el.innerHTML = escaped;  // Results in safe assignment.

X-Content-Type-Options

Dieser Header verhindert MIME-Typ-Sniffing, eine Praxis, die zu XSS-Schwachstellen führen könnte. Er stellt sicher, dass Browser die vom Server angegebenen MIME-Typen respektieren.

X-Content-Type-Options: nosniff

X-Frame-Options

Um Clickjacking zu bekämpfen, schränkt dieser Header ein, wie Dokumente in <frame>, <iframe>, <embed> oder <object>-Tags eingebettet werden können, und empfiehlt, dass alle Dokumente ihre Einbettungsberechtigungen ausdrücklich angeben.

X-Frame-Options: DENY

Cross-Origin Resource Policy (CORP) und Cross-Origin Resource Sharing (CORS)

CORP ist entscheidend für die Festlegung, welche Ressourcen von Websites geladen werden können, um Cross-Site-Leaks zu mindern. CORS hingegen ermöglicht einen flexibleren Mechanismus für das Cross-Origin-Ressourcenteilung, der die Same-Origin-Policy unter bestimmten Bedingungen lockert.

Cross-Origin-Resource-Policy: same-origin
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true

Cross-Origin Embedder Policy (COEP) und Cross-Origin Opener Policy (COOP)

COEP und COOP sind entscheidend für die Ermöglichung von Cross-Origin-Isolation und reduzieren erheblich das Risiko von Angriffen wie Spectre. Sie steuern das Laden von Cross-Origin-Ressourcen und die Interaktion mit Cross-Origin-Fenstern.

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin-allow-popups

HTTP Strict Transport Security (HSTS)

Zuletzt ist HSTS eine Sicherheitsfunktion, die Browser zwingt, nur über sichere HTTPS-Verbindungen mit Servern zu kommunizieren, wodurch die Privatsphäre und Sicherheit verbessert wird.

Strict-Transport-Security: max-age=3153600

Referenzen

{% hint style="success" %} Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Unterstütze HackTricks
{% endhint %}