Abo
  1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › Sicherheitslücke: Caches von CDN…

Wo ist nun die Sicherheitslücke...

  1. Thema

Neues Thema Ansicht wechseln


  1. Wo ist nun die Sicherheitslücke...

    Autor: Anonymer Nutzer 27.07.17 - 19:47

    ...in den Caches der CDN Anbieter?

    Aber nichts neues bei Artikeln des Autors...

  2. Re: Wo ist nun die Sicherheitslücke...

    Autor: Anonymer Nutzer 27.07.17 - 20:01

    die erste annahme ist:
    https://www.example.com/account/invalid.css und https://www.example.com/account/ liefern das gleiche ergebnis, da die webanwendung am server nicht zwischen den urls unterscheidet, obwohl sie es tun sollte.

    zweite annahme:
    der angreifer verleitet das opfer statt https://www.example.com/account https://www.example.com/account/invalid.css aufzurufen.

    dritte annahme:
    es wird unter https://www.example.com/account/invalid.css der inhalt von https://www.example.com/account/ gecacht. zb information über den account.

    vierte annahme:
    der angreifer ruft jetzt https://www.example.com/account/invalid.css auf und bekommt diese daten geliefert.

    jetzt klar?

  3. Re: Wo ist nun die Sicherheitslücke...

    Autor: Anonymer Nutzer 27.07.17 - 20:05

    Artikel:
    Sicherheitslücke: Caches von CDN-Netzwerken führen zu Datenleck

    Alles von dir beschriebene ist keine Sicherheitslücke in den Caches der CDN Netzwerke die tun genau das was sie sollen.

    Jetzt klar? ;-)

  4. Re: Wo ist nun die Sicherheitslücke...

    Autor: Anonymer Nutzer 27.07.17 - 20:22

    doch. sie cachen etwas, was nicht gecacht werden sollte.

    erzeugt eine webseite bei https://www.example.com/account/invalid.css statt css code html webseiten mit sensitiven daten, schreibt sie trotzdem die richtigen cache header. mittlerweile tun das alle frameworks richtig. die cdn ignorieren diese aber und cachen trotzdem.

  5. Re: Wo ist nun die Sicherheitslücke...

    Autor: Technik Schaf 27.07.17 - 20:38

    MysticaX schrieb:
    --------------------------------------------------------------------------------
    > Artikel:
    > Sicherheitslücke: Caches von CDN-Netzwerken führen zu Datenleck
    >
    > Alles von dir beschriebene ist keine Sicherheitslücke in den Caches der CDN
    > Netzwerke die tun genau das was sie sollen.
    >
    nein, sie tun nicht was sie tun sollen. Die Anforderung ist:
    > sei ein Zwischenspeicher für nicht individuelle Daten.
    Sie speichern aber auch sensible Daten. - > Aufgabe nicht erfüllt!

    nach deiner Logik gäbe es keine Sicherheits Lücken in Software. software acht immer das was sie soll, sprich: wie sie programmiert/konfiguriert ist. Sie ist deterministisch.
    der Fehler liegt so gesehen immer beim Programmierer.
    trotzdem spricht man von Sicherheitslücken in der Software.
    > Jetzt klar? ;-)
    jetzt klar?

  6. Re: Wo ist nun die Sicherheitslücke...

    Autor: Geddo2k 27.07.17 - 22:14

    grundsätzlich sollten die cdns den cache header respektieren das stimmt. aber auf der anderen seite definiere ich doch sehr genau was ins cdn kommt und was nicht und pfade in denen sicherheitsrelevante inhalte liegen haben im cdn nichts verloren bzw. nimmt man i.d.r. ja auch nur den pfad der öffentlichen assets mit ins cdn und verweigert alles andere.

  7. Re: Wo ist nun die Sicherheitslücke...

    Autor: Anonymer Nutzer 27.07.17 - 22:53

    Technik Schaf schrieb:
    --------------------------------------------------------------------------------
    > MysticaX schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Artikel:
    > > Sicherheitslücke: Caches von CDN-Netzwerken führen zu Datenleck
    > >
    > > Alles von dir beschriebene ist keine Sicherheitslücke in den Caches der
    > CDN
    > > Netzwerke die tun genau das was sie sollen.
    > >
    > nein, sie tun nicht was sie tun sollen. Die Anforderung ist:
    > > sei ein Zwischenspeicher für nicht individuelle Daten.
    > Sie speichern aber auch sensible Daten. - > Aufgabe nicht erfüllt!
    >
    > nach deiner Logik gäbe es keine Sicherheits Lücken in Software. software
    > acht immer das was sie soll, sprich: wie sie programmiert/konfiguriert ist.
    > Sie ist deterministisch.
    > der Fehler liegt so gesehen immer beim Programmierer.
    > trotzdem spricht man von Sicherheitslücken in der Software.
    > > Jetzt klar? ;-)
    > jetzt klar?

    Nö, es geht darum das der Titel suggeriert die Lücke wäre der Cache von den CDN's, die Lücke ist aber nicht dort, wenn der Server dahinter Sachen ausliefert die er nicht sollte, ist dort die Lücke nicht im Cache eines CDN.

  8. Re: Wo ist nun die Sicherheitslücke...

    Autor: Anonymer Nutzer 28.07.17 - 01:12

    siehe dazu mein posting noch mal. der server sagt dem cdn per header, dass es nicht gecacht werden soll. das cdn tut es trotzdem. das ist falsches verhalten der cdns. das es nicht _nur_ an den cdns liegt, ist wohl richtig. aber eben auch.

  9. Re: Wo ist nun die Sicherheitslücke...

    Autor: tbone 28.07.17 - 10:02

    MysticaX schrieb:
    --------------------------------------------------------------------------------
    > Nö, es geht darum das der Titel suggeriert die Lücke wäre der Cache von den
    > CDN's, die Lücke ist aber nicht dort, wenn der Server dahinter Sachen
    > ausliefert die er nicht sollte, ist dort die Lücke nicht im Cache eines
    > CDN.

    doch die Lücke ist zumindest teilweise im CDN, da dort Cache Header ignoriert werden und html gecached wird, nur weil die url mit css endet.

    der backend server kann vielleicht aus legacy gründen nicht einfach url enden unterbinden.

  10. Re: Wo ist nun die Sicherheitslücke...

    Autor: SCF 28.07.17 - 11:29

    Es ist eben eine Kombination aus beidem. Würde der Server die URL richtig prüfen wäre alles gut und es könnte nichts gecached werden, was nicht gecached werden sollte. Das CDN ist an der Stelle "dumm", Request kam für URL, Server gab Antwort, also wird für diesen Request diese Antwort gecached. Gut den Header prüfen wäre cool, aber wahrscheinlich machen die das eben nicht weil sonst das schöne Caching nicht so gut laufen würde, eventuell auch weil viele Seiten diese Header nicht korrekt setzen.
    Würde es das CDN dazwischen nicht geben würde der Angriff auch nicht funktionieren, es sei denn der Server bzw. die Server-Infrastruktur hat selber einen Cache mit genau dem gleichen problematischen Verhalten.

  11. Re: Wo ist nun die Sicherheitslücke...

    Autor: Anonymer Nutzer 28.07.17 - 12:17

    > Das CDN ist an der Stelle "dumm", Request kam für
    > URL, Server gab Antwort, also wird für diesen Request diese Antwort
    > gecached. Gut den Header prüfen wäre cool,
    nicht dumm und header prüfen ist nicht nur cool. das verhalten ist definitiv absolut falsch. da gibt's nichts zu rütteln oder anders zu interpretieren.

    > aber wahrscheinlich machen die
    > das eben nicht weil sonst das schöne Caching nicht so gut laufen würde,
    > eventuell auch weil viele Seiten diese Header nicht korrekt setzen.
    das verhalten ist komplett falsch. webseiten mit logins zu cachen ist fast immer ein fehler. ich kann die private webseite eines benutzers cachen, nur damit schön gecacht ist.

    > Würde es das CDN dazwischen nicht geben würde der Angriff auch nicht
    > funktionieren, es sei denn der Server bzw. die Server-Infrastruktur hat
    > selber einen Cache mit genau dem gleichen problematischen Verhalten.
    die meiste standardsoftware (z.b. varnish) ignoriert die header aber nicht (in den default einstellungen).

    das verhalten der cdns ist falsch. nur weil zwei seiten was falsch machen, heißt das nicht, dass das verhalten des einen deshalb plötzlich richtig wird.

  12. Re: Wo ist nun die Sicherheitslücke...

    Autor: schauma 28.07.17 - 17:22

    IMHO
    Die Sicherheitslücke liegt im Verhalten des Webservers. Er erstellt aus einer Session-abhängigen Information eine Session-unabhängige Information. Die Entscheidung was zwischen Nutzer und Server durch x-beliebige Systeme( auch CDN) gecacht wird, darf für die Sicherheit der Nutzer nicht relevant sein.

    Ein Seitenbetreiber kann ja nicht für alle Cachingdienste auf dem Weg garantie geben, dass diese richtig konfiguriert sind. Als Beispiel können wir hier Caching Proxies nehmen, die Firmen bei dem Aufbrechen von SSL -In manchen Branchen üblich- verwenden.

    Betrachten wir den Datenfluss ist auch klar, dass die Server-Response gecacht wird. Als das, was vom Server auf dem Rückweg gespeichert wird. Der Webserver kann also das Antworten auf nicht existente Dateien unterbinden.

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Bosch Gruppe, Berlin
  2. OKI EUROPE LIMITED, Branch Office Düsseldorf, Düsseldorf
  3. Giesecke+Devrient Mobile Security GmbH, München
  4. CSL Behring GmbH, Marburg, Hattersheim am Main

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. 119,90€
  2. (reduzierte Überstände, Restposten & Co.)
  3. täglich neue Deals bei Alternate.de


Haben wir etwas übersehen?

E-Mail an news@golem.de


Gaming-Tastaturen im Test: Neue Switches für Gamer und Tipper
Gaming-Tastaturen im Test
Neue Switches für Gamer und Tipper

Corsair und Roccat haben neue Gaming-Tastaturen auf den Markt gebracht, die sich vor allem durch ihre Switches auszeichnen. Im Test zeigt sich, dass Roccats Titan Switch besser zum normalen Tippen geeignet ist, aber nicht an die Geschwindigkeit des Corsair-exklusiven Cherry-Switches herankommt.
Ein Test von Tobias Költzsch

  1. Azio RCK Retrotastatur wechselt zwischen Mac und Windows-Layout
  2. OLKB Planck im Test Winzig, gerade, programmierbar - gut!
  3. Alte gegen neue Model M Wenn die Knickfedern wohlig klackern

Google Nachtsicht im Test: Starke Nachtaufnahmen mit dem Pixel
Google Nachtsicht im Test
Starke Nachtaufnahmen mit dem Pixel

Gut einen Monat nach der Vorstellung der neuen Pixel-Smartphones hat Google die Kamerafunktion Nachtsicht vorgestellt. Mit dieser lassen sich tolle Nachtaufnahmen machen, die mit denen von Huaweis Nachtmodus vergleichbar sind - und dessen Qualität bei Selbstporträts deutlich übersteigt.
Ein Test von Tobias Költzsch

  1. Pixel 3 Google patcht Probleme mit Speichermanagement
  2. Smartphone Google soll Pixel 3 Lite mit Kopfhörerbuchse planen
  3. Google Dem Pixel 3 XL wächst eine zweite Notch

IMHO: Valves Ka-Ching mit der Brechstange
IMHO
Valves "Ka-Ching" mit der Brechstange

Es klingelt seit Jahren in den Kassen des Unternehmens von Gabe Newell. Dabei ist die Firma tief verschuldet - und zwar in den Herzen der Gamer.
Ein IMHO von Michael Wieczorek

  1. Artifact im Test Zusammengewürfelt und potenziell teuer
  2. Artifact Erste Kritik an Kosten von Valves Sammelkartenspiel
  3. Virtual Reality Valve arbeitet an VR-Headset und Half-Life-Titel

  1. Kryptowährungen: Nutzer können für Razer minen und erhalten Spielgeld
    Kryptowährungen
    Nutzer können für Razer minen und erhalten Spielgeld

    Nutzer erhalten virtuelles Silber, wenn sie mit ihrer Grafikkarte für Razer Hashwerte errechnen. Das Geld können sie für Hardware oder Ingame-Inhalte ausgeben. Es ist nicht ganz klar, wie viel Gegenwert Gamer erhalten - der dürfte aber nicht an die Stromkosten heranreichen, die dadurch anfallen.

  2. Mutant Year Zero im Test: Xcom plus postnukleare Ente
    Mutant Year Zero im Test
    Xcom plus postnukleare Ente

    Die Taktiküberraschung der Saison schmeckt nach Geflügel: Das düstere, witzige und fordernde Mutant Year Zero macht vor, wie ein gutes Taktik-Rollenspiel funktioniert. Fans von Fallout und Xcom sollten zubeißen.

  3. Vivo Nex Dual Screen: Vivo stellt Smartphone mit zwei Displays vor
    Vivo Nex Dual Screen
    Vivo stellt Smartphone mit zwei Displays vor

    Nach Nubia stellt mit Vivo der zweite chinesische Hersteller binnen kurzer Zeit ein Smartphone mit zwei Displays vor: Neben dem Hauptbildschirm befindet sich ein zweiter, kleinerer auf der Rückseite. Eine Frontkamera hat das Nex Dual Screen entsprechend nicht mehr.


  1. 14:20

  2. 14:00

  3. 13:30

  4. 13:13

  5. 12:07

  6. 11:36

  7. 10:46

  8. 10:31