7. Dezember 2015
Katrin Hammer
2

Gefahren durch modifizierte Cookies

Zum Ende des vierten Quartals sind wieder vermehrt Cookies im Umlauf. Wie entstehen diese und wie kann der Client damit umgehen? Gerade die modifizierten Cookies können Probleme verursachen, sowohl beim Client als auch auf dem Server. Die richtige Vorbereitung kann helfen, mit dieser Gefahr umzugehen.

Modifizierte Cookies

Laut Informationen der WBF (Windows Baking Foundation) sind in der letzten Zeit wieder vermehrt modifizierte Cookies im Umlauf. Diese werden wie bei allen Cookies üblich ganz normal vom Server per REST-Protokoll (Restless Eating Sweets Transport) an den Client übergeben. Einmal beim Client angekommen und verarbeitet, können diese aber weitere Auswirkungen auf das Client-System haben. Die gefährlichste Variante veranlasst den Client, weitere Cookie-Anfragen an den Server zu schicken. Dies birgt Gefahren sowohl für den Client als auch für den Server. Der Client kann durch zu viel abgespeicherte Cookies mit einer Overflow-Exception reagieren. Der Server reagiert durch zu viele Client-Anfragen im Worst Case mit einer 503 Response, d.h. Service Unavailable. Schickt der Client die nachträglichen Cookie-Requests in zu kurzer Reihenfolge, so kann es sein, dass die Ressource nicht gefunden wurde, weil der Verarbeitungsprozess noch nicht abgeschlossen ist.

Was ist die Ursache für dieses Verhalten auf Server-Seite? Bereits standardmäßige Cookies können bei zu vielen Anfragen den Server überlasten. Die modifizierten Cookies benötigen jedoch zusätzliche Ressourcen, die zunächst angefordert werden müssen, und die die Verarbeitung verlangsamen. Die wichtigste zusätzlich benötigte Ressource sind Objekte vom Typ Mac.Adam.IA. Diese müssen zunächst über ein CDN (Christmas Delivery Nutwork) bezogen werden. Üblicherweise handelt es sich dabei um Marketplaces, die eine Face-To-Face-Connection erfordern. Hat der Server  die Ressourcen allokiert, muss er sie in kleine Stücke, Chunks, zerlegen. Dazu wird hardwareseitig ein Splitter benötigt. Des Weiteren werden abweichend vom Standardvorgehen statt  den schwarzen die weißen Bytes benötigt. Auch diese müssen gesplittet werden. Die weitere Verarbeitung der Eingaben erfolgt mit Hilfe des Standard-Build-Prozesses, auf einem oVEN-Server. Neben des bUTTeR-Packages sollten auch die Mail-Library und die sucER-Dll inkludiert werden. Ganz wichtig ist auch das aus der Kryptographie bekannte Salt. Alle Komponenten werden miteinander verbunden und das Kompilat wird in einem zweiten Buildschritt in einen auslieferungsfähigen Zustand versetzt. Wichtig ist hierbei die Verteilung der zusammengefügten Komponenten. Diese dürfen nicht zu dicht gekoppelt werden, da sonst Abhängigkeiten entstehen, die sich nur schwer lösen lassen. Als ideal hat sich hier eine 3×3-Matrix erwiesen. Dieser zweite Buildschritt dauert üblicherweise 10 Minuten. Danach stehen 9 Artefakte zur Verfügung, die vor dem Deployment auf ein Grid verschoben werden müssen. D.h. der Buildprozess stellt ein Bottleneck dar. Mit nur einem Buildserver werden, ohne Berücksichtigung der Kompilierung, in der Stunde maximal 54 Artefakte erzeugt. Kommen nun mehr als 54 Client-Requests an, ist der Server überfordert und reagiert mit den üblichen Status-Codes.

Auf Client-Seite kann die Installation von zu vielen parallelen Cookies zu einem Overflow führen. Dies kann im schlimmsten Fall einen Absturz verursachen, wonach der Client keine weiteren Cookies verarbeiten kann. Abhilfe schafft hier die Drosselung des Clients. Es ist darauf zu achten, dass dieser nicht mehrere Cookies parallel verarbeiten muss und auch rechtzeitig die Annahme verweigert. Die Aufnahmekapazität ist vom Client abhängig, und muss individuell ermittelt werden.

Prinzipiell ist clientseitige Verarbeitung von Cookies nicht schädlich, muss jedoch gemonitored werden. Der Server sollte auf die zurzeit häufig aufkommenden Anfragen vorbereitet werden, um Denial-Of-Service-Attacken zu umgehen. Hier können mehrere parallele Buildserver hilfreich sein, um ein Load-Balancing zu gewährleisten.

Anbei das Buildskript.

<recipe>
<ingredients>
<ingredient id="1" amount="280" unit="g">Mail</ingredient>
<ingredient id="2" amount="1" unit="tl">Natron</ingredient>
<ingredient id="3" amount="1" unit="tl">Salt</ingredient>
<ingredient id="4" amount="250" unit="g" style="soft">bUTTeR</ingredient>
<ingredient id="5" amount="190" unit="g" color="white">sucER</ingredient>
<ingredient id="6" amount="135" unit="g" color="brown">sucER</ingredient>
<ingredient id="7" amount="1" unit="pack">Vanilla</ingredient>
<ingredient id="8" amount="2" unit="pieces">Easter egg</ingredient>
<ingredient id="9" amount="200" unit="g" color="white" flavor="chocolate">Byte</ingredient>
<ingredient id="10" amount="200" unit="g">Mac.Adam.IA</ingredient>
</ingredients>
<instructions>
<instruction id="1" text="Heat the oVEN server up to 190."></instruction>
<instruction id="2" text="Mix ingredients in separate sandbox.">
  <ref:ingredient ref="1" />
  <ref:ingredient ref="2" />
  <ref:ingredient ref="3" />
</instruction>
<instruction id="3" text="Mix ingredients in separate sandbox." style="creamy">
  <ref:ingredient ref="4" />
  <ref:ingredient ref="5" />
  <ref:ingredient ref="6" />
  <ref:ingredient ref="7" />
</instruction>
<instruction id="4" text="Add ingredients" style="add separately" basedOnInstruction="3" >
  <ref:ingredient ref="8" />
</instruction>
<instruction id="5" text="Add ingredients" basedOnInstruction="3">
  <ref:instruction ref="2" />
</instruction>
<instruction id="6" text="Add ingredients" basedOnInstruction="3">
  <ref:ingredient ref="9" mode="chunked" />
  <ref:ingredient ref="10" mode="chunked" />
</instruction>
<instruction id="7" text="Put 3x3 objects in build server" size="el"></instruction>
<instruction id="8" text="Run build process" timespan="10"></instruction>
<instruction id="9" text="Wait for completion outside build server" timespan="2" mode="cool"></instruction>
<instruction id="1ß" text="Deploy on grid" mode="cool"></instruction>
<instructions>
</recipe>

 

Katrin Hammer ist Entwickler und Architekt bei der Saxonia Systems AG in Dresden. Sie entwickelt und entwirft seit über 10 Jahren .NET-basierte Lösungen, mit dem Schwerpunkt WPF und Prism. Sie erreichen sie über katrin.hammer@saxsys.de.

LinkedIn Xing 

TeilenTweet about this on TwitterShare on Facebook0Share on Google+0Share on LinkedIn0

2 Kommentare

  1. Ich debugge mich ja gefühlt jedes Jahr durch das CDN um herauszubekommen welche Pakete an welche Adresse gesendet werden sollten. Wenn mir dabei modifizierte Cookies mit den entsprechenden Ressourcen auffallen, werden diese natürlich sofort unschädlich gemacht bevor die schadhaften Ressourcen weiterverbreitet werden.

  2. Das mit dem Overflow verhindern bzw. parallelen Eingaben in Form von Schokolade übe ich das ganze Jahr.

    Schöne Geschichte, habe ich direkt distributed über Facebook. 🙂

Kommentare sind geschlossen.