Ticketcorner.ch und Eventim.de sind Schwesterunternehmen unter dem Dach von CTS Eventim. Sie arbeiten unabhängig auf ihren nationalen Märkten, teilen sich aber strategische Ressourcen und Infrastruktur sowie Technik.

CTS Eventim AG & Co. KGaA ist ein führender europäischer Anbieter von Ticketing und Live-Entertainment mit Hauptsitz in Bremen, Deutschland. Das Unternehmen ist vor allem durch seine Ticketplattform eventim.de bekannt, über die Eintrittskarten für Konzerte, Sportveranstaltungen, Theater, Festivals und andere Events verkauft werden.

Meine Untersuchung begann mit einer sehr interessanten Entdeckung, die ich aufgrund eigener Käufe auf ticketcorner.ch machen konnte: Ich hatte mir selbst zwei Tickets für unterschiedliche Veranstaltungen in den Monaten August und September gekauft. Während dieser Transaktionen fiel mir ein Muster in der URL-Struktur der PDF-Tickets auf, das mich sofort stutzig machte. Die URLs für den direkten Abruf dieser Tickets folgten einem Schema wie:

https://www.ticketcorner.ch/imageservlet?fun=express_ticket&t=[SEQUENZNUMMER][HEXWERT]

Hierbei schien die Sequenznummer statisch für einen konkreten Kauf erstellt worden zu sein (9-stellig), während der Hexadezimalwert dynamisch (10-stellig) war und sich von Ticket zu Ticket änderte, auch wenn die Sequenznummer hochgezählt wird.

Diese Entdeckung führte mich zu einer Hypothese: Wenn es mir gelänge, diesen dynamischen Hexadezimalwert systematisch durchzuzählen, könnte ich möglicherweise auf gültige Ticketcodes (19-stellig) anderer Käufer stossen. Dies hätte potenziell schwerwiegende Konsequenzen:

• Kompromittierung von Tickets: Jeder, der einen gültigen Ticketcode ermittelt, könnte das zugehörige PDF herunterladen und potenziell unbefugt nutzen. Dies würde eine erhebliche Sicherheitslücke darstellen, da die Tickets nicht nur durch einen sicheren Kaufprozess, sondern auch durch die Unkenntnis der direkten URL geschützt sein müssten.
• Missbrauch und Betrug: Ein unautorisierter Zugriff auf Tickets könnte dazu führen, dass diese mehrfach ausgedruckt und missbräuchlich eingesetzt werden. Dies hätte direkte finanzielle Verluste für Ticketcorner und Veranstalter zur Folge und würde zu erheblichen Problemen beim Einlass führen.
• Datenschutzverletzung: Obwohl die heruntergeladenen PDFs primär das Ticket selbst abbilden, könnten sie je nach Formatierung personenbezogene Daten des ursprünglichen Käufers enthalten oder Rückschlüsse auf Kaufverhalten zulassen. Die unautorisierte Zugänglichkeit dieser Dokumente würde somit eine ernsthafte Verletzung des Datenschutzes darstellen.

Mein primäres Ziel war es daher, einen „Proof of Concept“ (PoC) zu erbringen, der diese potenzielle Sicherheitslücke demonstriert. Ich wollte ein Skript entwickeln, das:

1. Die URLs für Ticket-PDFs durch systematisches Hochzählen des Hexadezimalwerts zu jeder Sequenznummer dynamisch generieren kann.
2. Die PDF-Datei von der generierten URL herunterlädt, falls eine gültige Kombination gefunden wird.
3. Die heruntergeladene Datei entsprechend der jeweiligen Ticketnummer benennt.
4. Diesen gesamten Prozess automatisiert, um die Machbarkeit eines grösseren Scans zu untermauern.

---

2. Angewandte Methoden und Vorgehensweise

Meine Untersuchung begann mit einer schrittweisen Annäherung, um das Problem zu isolieren und die spezifischen Barrieren zu identifizieren, die einem automatisierten Zugriff entgegenstehen.

2.1 Erster Versuch: Direkter HTTP-Request mit cURL (PHP)

Meine Methode: Ich startete mit dem direktesten Weg: Ich versuchte, die URLs mittels PHP und der cURL-Bibliothek aufzurufen. cURL ist ein mächtiges Tool für HTTP-Anfragen und schien ideal für das serverseitige Abrufen von Daten. Ich habe verschiedene HTTP-Header wie User-Agent und Accept gesetzt, um die Anfrage möglichst wie die eines echten Webbrowsers aussehen zu lassen, und habe Weiterleitungen aktiviert.

Warum dieser Versuch scheiterte: Mein Skript schlug konstant mit einem timeout-Fehler fehl. Es konnte keine Daten empfangen. Dieses Verhalten ist für mich ein klares Anzeichen dafür, dass ein Bot-Management-System die Verbindung sehr frühzeitig beendete – noch bevor der Zielserver eine Antwort senden konnte. Es sah so aus, als würde der Server einfach nicht antworten oder die TCP-Verbindung sofort trennen.

2.2 Verdacht und Bestätigung: Akamai Bot Manager

Das typische timeout-Verhalten bei direkten HTTP-Anfragen zu bekannten, stark frequentierten Websites liess bei mir den Verdacht auf ein robustes Bot-Management-System aufkommen. Meine spätere Überprüfung der HTTP-Header einer erfolgreichen Anfrage, die ich manuell in einem echten Browser (mittels der F12-Entwicklertools) an die Ticketcorner-Seite gestellt hatte, bestätigte diesen Verdacht: Ich fand Cookies wie _abck und bm_sz sowie den ak_p-Header in den Antworten. All diese sind charakteristisch für Akamai Bot Manager, einen der führenden Anbieter von Bot-Abwehrlösungen, der für seine fortschrittlichen Techniken im Bereich Browser-Fingerprinting und Verhaltensanalyse bekannt ist. Akamai agiert hier als eine Art „digitaler Türsteher“ vor den eigentlichen Ticketcorner-Servern.

2.3 Zweiter Versuch: Browser-Automatisierung mit Puppeteer (Node.js)

Meine Methode: Da cURL keine JavaScript-Engines ausführen kann (und Akamai JavaScript-Challenges stellt), war der nächste logische Schritt der Wechsel zu einer Browser-Automatisierungsbibliothek. Ich wählte Puppeteer, eine Node.js-Bibliothek, die einen echten Headless-Chromium-Browser steuert. Meine Hoffnung war, dass ein vollwertiger Browser die Akamai-JavaScript-Checks ausführen und die notwendigen Cookies generieren könnte. Für die Debugging-Phase setzte ich headless: false, um den Browser-Vorgang visuell verfolgen zu können. Zusätzlich implementierte ich Massnahmen wie das Setzen eines realistischen User-Agent, eines definierten Viewport und vor allem die Verwendung von puppeteer-extra mit dem puppeteer-extra-plugin-stealth. Dieses Plugin ist darauf ausgelegt, die gängigen Automatisierungs-Erkennungsmethoden (wie die navigator.webdriver Property) zu umgehen.

Warum dieser Versuch scheiterte: Trotz des Einsatzes eines echten Browsers und der Implementierung von Stealth-Massnahmen schlug der Versuch erneut fehl. Das Browserfenster blitzte nur kurz auf und schloss sich sofort wieder. Die Fehlermeldung in der Konsole war diesmal net::ERR_ABORTED. Dies ist das clientseitige Äquivalent zum timeout bei cURL: Akamai erkannte den automatisierten Browser extrem frühzeitig – oft schon auf Netzwerkebene oder durch minimale Browser-Fingerabdrücke, die das Stealth-Plugin nicht vollständig verschleiern konnte – und brach die Verbindung aktiv ab, noch bevor die Seite vollständig geladen oder ein Fehlercode vom Server gesendet werden konnte.

2.4 Analyse des Scheiterns und die Rolle von CORS

Die wiederholten Fehler mit verschiedenen Methoden zeigten mir, dass Akamai nicht durch einfache Header-Manipulationen oder Standard-Browser-Automatisierung zu überlisten ist. Das System prüft Hunderte von Merkmalen, einschliesslich TCP/IP- und TLS-Fingerprinting, der HTTP/2-Frame-Reihenfolge und der detaillierten Ausführungsumgebung der JavaScript-Engine.

Zusätzlich kam die Problematik von CORS (Cross-Origin Resource Sharing) ins Spiel. Ein Test, bei dem ich eine einfache HTML-Datei mit einem fetch-Aufruf lokal in meinem Browser ausführte, um die Ticketcorner-URL abzurufen, scheiterte ebenfalls. Dies bestätigte, dass der Browser selbst solche direkten Cross-Origin-Anfragen aus Sicherheitsgründen blockiert, es sei denn, der Zielserver erlaubt dies explizit über — Access-Control-Allow-Origin-Header — was bei Ticketcorner für solche Anfragen offensichtlich nicht der Fall ist. Dies ist eine zusätzliche, fundamentale Barriere für alle Frontend-basierten Lösungsansätze.

---

3. Was am Ende (eingeschränkt) funktioniert hat: Der „Proof of Concept“ mit dem Bash Script

Angesichts der frustrierenden und fortschrittlichen Bot-Abwehr stellte sich mir die Frage, ob ein automatisierter Zugriff überhaupt möglich ist. Eine entscheidende und aufschlussreiche Erkenntnis lieferte der Test mit dem Linux-Befehl xdg-open auf meinem Debian-System:

Meine Methode: Ich führte den Befehl xdg-open „https://www.ticketcorner.ch/imageservlet?fun=express_ticket&t=…“ direkt in der Konsole aus.

Ergebnis und Bedeutung:

• xdg-open startete meinen Standardbrowser (in diesem Fall Firefox).
• Der Browser navigierte zur URL und lud das PDF erfolgreich herunter, speicherte es an der erwarteten Stelle im Standard-Download-Verzeichnis.
• Dieses Ergebnis war der Schlüssel: Es zeigte, dass die URL an sich gültig war und der Ticketcorner-Server (hinter Akamai) die PDF bereitstellen würde, sofern die Anfrage von einem System kam, das Akamai als „echten“, menschlich agierenden Browser einstufte.

Dieses Experiment lieferte mir den Beweis, den ich suchte: Akamai erkennt den fundamentalen Unterschied zwischen einem echten Browser, der „menschlich“ agiert, und meinen automatisierten Skripten. Das xdg-open-Szenario funktionierte, weil der Browser vom Betriebssystem gestartet wurde, er über alle menschlichen Browser-Eigenschaften (Cookies, History, installierte Plugins, vollständiger JavaScript-Fingerabdruck) verfügte und keine ungewöhnlichen Automatisierungs-Flags sendete oder Verhaltensmuster zeigte, die Akamai als Bot-typisch einstufen würde.

3.1 Der Bash-Skript „Proof of Concept“

Basierend auf dieser kritischen Erkenntnis, dass der manuelle xdg-open-Befehl funktioniert, entwickelte ich ein Bash-Skript als einen weiteren „Proof of Concept“ (PoC).

Meine Methode: Das Bash-Skript sollte:

1. Die Hexadezimalwerte systematisch inkrementieren und die vollständigen Ticketnummern mit einer statischen Sequenznummer generieren.
2. Explizit chromium-browser (anstelle des System-Standardbrowsers) direkt verwenden, um die generierte URL in einem neuen Fenster zu öffnen und den Browser die Datei herunterladen zu lassen.
3. Im Download-Verzeichnis auf das Erscheinen der erwarteten PDF-Datei warten und diese dann in den präzisen Namen [Ticketnummer].pdf umbenennen.
4. Nach jeder Iteration den gestarteten Browserprozess explizit beenden, um eine „frische“ Sitzung für die nächste Kombination zu gewährleisten. Ich musste dabei die Schwierigkeiten und Risiken des Beendens von Browserprozessen in Bash sorgfältig abwägen und implementieren, da es sich um einen invasiven Vorgang handeln kann.

3.2 Warum dies als PoC gilt (und keine echte, praktikable Lösung ist)

Dieses Skript diente als „Proof of Concept“ in zweierlei Hinsicht:

1. Es bestätigte, dass die URL-Struktur an sich gültige PDF-Dateien zurückliefern kann, sofern die Abfrage von einem System kommt, das Akamai als legitim einstuft.
2. Es demonstrierte die extrem hohen Hürden, die selbst eine rudimentäre Automatisierung über diese URLs mit sich bringt. Das Problem lag nicht in der URL selbst, sondern ausschliesslich im Bot-Schutzmechanismus von Ticketcorner.

Es ist jedoch keine praktische oder skalierbare Lösung, um die ursprüngliche Hypothese der Kompromittierung in grossem Massstab zu beweisen oder gar auszunutzen, da:

• Keine Kontrolle über Tabs: Ein reines Bash-Skript kann keine einzelnen Tabs in einem bereits geöffneten Browser-Fenster steuern. Jeder Aufruf vom Befehl „chromium-browser –new-window“ öffnet ein neues Fenster, nicht nur einen neuen Tab. Die gewünschte Effizienz durch Tab-Nutzung ist mit Bash nicht umsetzbar.
• Invasives Browser-Schliessen: Das Beenden des Browsers (kill oder pkill) ist hochproblematisch. Es kann alle laufenden Browser-Instanzen des Benutzers beenden und zu Datenverlust führen. Eine sichere und präzise Kontrolle über Browser-Prozesse ist in Bash nicht möglich. Dies macht den Ansatz für den produktiven Einsatz untauglich und höchstens für isolierte Testumgebungen relevant.
• Anfälligkeit für Akamai: Obwohl es manuell mit xdg-open funktioniert hat, gibt es keine Garantie, dass dies bei wiederholten, schnellen automatisierten Aufrufen in einer Schleife (selbst mit einem echten Browser) stabil bleibt. Akamai könnte ein solches „Öffnen-Herunterladen-Schliessen“-Muster als Bot-Verhalten erkennen und auch diese Anfragen blockieren. Das Bash-Skript ist im Grunde eine Automatisierung des manuellen Tests, unterliegt aber weiterhin den Erkennungsmechanismen von Akamai, sobald die Frequenz oder das Muster vom Normalen abweicht. Die schiere Anzahl der möglichen Hexadezimal-Kombinationen (16^10=1,099,511,627,776 – über eine Billion für 10 Stellen und 16 Zeichen) macht einen Brute-Force-Angriff auf diese Weise, selbst wenn er nicht blockiert würde, rechnerisch unrealistisch. Die Testschleife wurde absichtlich auf einen winzigen Bereich beschränkt, um dies zu verdeutlichen.

---

4. Fazit und Ausblick

Meine Untersuchungen haben soweit gezeigt, dass der automatisierte Abruf von PDFs von Ticketcorner, das durch Akamai Bot Manager geschützt ist, eine enorm schwierige und ressourcenintensive Aufgabe ist.

Die Hypothese, dass Tickets kompromittiert werden könnten, wenn man den Code kennt, wurde grundsätzlich bestätigt: Der Server liefert das PDF, wenn ein „echter“ Browser danach fragt. Die Schwierigkeit liegt allein darin, den Akamai-Schutz zu überwinden, der genau dieses Szenario verhindern soll.

• Direkte HTTP-Anfragen (cURL) scheitern: Sie können JavaScript-Challenges nicht lösen.
• Standard-Browser-Automatisierung (Puppeteer mit Stealth) scheitert: Akamai ist zu ausgefeilt und erkennt selbst gut getarnte automatisierte Browser und kappt die Verbindung sofort.
• Manuelle Browser-Nutzung funktioniert: Ein echter Browser, der „menschlich“ agiert, wird von Akamai durchgelassen.
• Bash-Skript ist nur ein sehr eingeschränkter PoC: Es kann den manuellen Prozess der URL-Übergabe automatisieren und die Dateibenennung übernehmen, leidet aber unter fehlender Feinsteuerung des Browsers (Tabs) und einem riskanten Schliessverhalten. Vor allem löst es nicht das Kernproblem, dass Akamai selbst eine automatisierte Abfolge von Browserstarts als Bot-Verhalten erkennen könnte.

Die Konsequenz für die potenzielle Sicherheitslücke ist, dass Ticketcorner durch Akamai sehr effektiv vor einfachen und selbst fortgeschrittenen automatisierten Brute-Force-Angriffen geschützt ist, die auf das Erraten von Ticketcodes abzielen. Die technischen Hürden für einen Angreifer sind extrem hoch. Das reine Erraten von Ticketcodes reicht nicht aus; die zusätzlichen Akamai-Challenges müssen gemeistert werden, was mit herkömmlichen Mitteln, wie wir sie erprobt haben, quasi unmöglich ist.

Meine Erkenntnisse legen nahe, dass die Ticketcodes aufgrund der robusten Akamai-Schutzmassnahmen höchstwahrscheinlich nicht durch systematisches Brute-Forcing kompromittiert werden können, da die technischen Hindernisse für einen Angreifer, Akamai zu überwinden, als extrem hoch einzuschätzen sind.

Dennoch muss betont werden, dass das Anbieten von Tickets allein über Codes in einem direkten Downloadlink ein inhärentes Risiko birgt. Sollten die Schutzmechanismen von Akamai einmal nicht zur Verfügung stehen oder umgangen werden können – sei es durch Fehlkonfiguration, Ausfall oder die Entdeckung einer neuen Umgehungsmethode –, wären die Tickets direkt über die URL kompromittierbar. Eine Abhängigkeit von einem externen Schutzsystem allein ist aus Sicherheitssicht riskant, da die primäre Ressource (das Ticket-PDF) dann ungeschützt wäre.

Wenn ticketcorner.ch und eventim.de die gleiche Infrastruktur und dieselben Ressourcen nutzen – insbesondere das gleiche System zur Ticketgenerierung und denselben Bot-Manager wie Akamai –, dann würden die gleichen potenziellen Schwachstellen und Schutzmechanismen auch für eventim.de gelten.