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. BIM Berliner Immobilienmanagement GmbH, Berlin
  2. OHB System AG, Bremen, Oberpfaffenhofen
  3. SWP Stadtwerke Pforzheim GmbH & Co. KG, Pforzheim
  4. über Hays AG, Düsseldorf

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Blu-ray-Angebote
  1. (u. a. Logan, John Wick, Alien Covenant, Planet der Affen Survival)
  2. (u. a. 3 Blu-rays für 15€, 2 Neuheiten für 15€)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Smartphone-Kaufberatung: Viel Smartphone für wenig Geld
Smartphone-Kaufberatung
Viel Smartphone für wenig Geld

Auch zum diesjährigen Weihnachtsfest verschenken sicher viele Menschen Smartphones - oder wünschen sich selbst eins. Der Markt ist so groß wie unüberschaubar. Wir haben 2018 viele getestet und geben Empfehlungen für Geräte unter 300 Euro.
Von Tobias Költzsch

  1. Vivo Nex Dual Screen Vivo stellt Smartphone mit zwei Displays vor
  2. Smartphone-Kaufberatung Mehr Smartphone für mehr Geld
  3. CDU-Generalsekretärin Alle Behördengänge sollen am Smartphone erfolgen können

Resident Evil 2 angespielt: Neuer Horror mit altbekannten Helden
Resident Evil 2 angespielt
Neuer Horror mit altbekannten Helden

Eigentlich ein Remake - tatsächlich aber fühlt sich Resident Evil 2 an wie ein neues Spiel: Golem.de hat mit Leon und Claire gegen Zombies und andere Schrecken von Raccoon City gekämpft.
Von Peter Steinlechner

  1. Resident Evil Monster und Mafia werden neu aufgelegt

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

  1. FTTC: Die geheimnisvolle Vectoringnachfrage der Telekom
    FTTC
    Die geheimnisvolle Vectoringnachfrage der Telekom

    Die Deutsche Telekom bietet Vectoring für fast eine Viertelmillion Haushalte. Auch bei dieser neuen Welle des Netzausbaus werden keine genauen Angaben dazu gemacht, wie die Kunden dies buchen.

  2. Docsis 3.1: Kabelnetzbetreiber sehen sich bei Gigabit als Marktführer
    Docsis 3.1
    Kabelnetzbetreiber sehen sich bei Gigabit als Marktführer

    Zum Jahresende ziehen die Kabelnetzbetreiber Bilanz. Durch den Docsis-3.1-Ausbau seien 7,3 Millionen Anschlüsse mit Gigabit-Datenraten verfügbar. Doch ist das wirklich Gigabit wie Glasfaser?

  3. Final Fantasy 15: Erstes Spiel mit DLSS-Kantenglättung verfügbar
    Final Fantasy 15
    Erstes Spiel mit DLSS-Kantenglättung verfügbar

    Wer eine Geforce RTX mit Turing-Chip hat, kann Deep Learning Super Sampling mittlerweile in Final Fantasy 15 nutzen. Die Kantenglättung funktioniert nur in 4K, aber mit einem Trick klappt DLSS auch ohne 4K-Display. Die Framerate überzeugt, die Bildqualität meistens.


  1. 16:59

  2. 14:30

  3. 14:04

  4. 13:35

  5. 13:02

  6. 12:48

  7. 12:30

  8. 12:01