Entdeckung von XSS auf Chess.com
- Während ich Schach als Hobby spielte und mit Technik herumexperimentierte, entdeckte ich auf Chess.com eine XSS-Schwachstelle.
- Chess.com ist die größte Schachseite im Internet mit mehr als 100 Millionen Mitgliedern.
Überblick
- Anfang 2023 begann ich, viel auf Chess.com zu spielen.
- Ich brachte einen Freund dazu, sich auf der Seite anzumelden, und wir wurden über die Freundesfunktion sofort Freunde.
- Ich fragte mich, ob sich ähnlich wie beim MySpace-Wurm automatisch Freunde hinzufügen lassen.
- Ich erstellte ein neues Konto und entdeckte im Netzwerk-Tab der Entwicklertools die URL zum automatischen Hinzufügen von Freunden.
Mittelspiel
- Ich versuchte XSS mit dem TinyMCE-Rich-Text-Editor.
- Mit dem Burp-Proxy fügte ich direkt HTML-Code in die „About“-Beschreibung ein.
- Ich prüfte die TinyMCE-Konfiguration und erstellte mithilfe der Style-Eigenschaft
background-imageeine XSS-Payload. - Ich testete verschiedene Symbole und fand heraus, wie sich XSS ausführen ließ.
- Schließlich entwickelte ich eine Methode, um Cookies und JavaScript-Objekte zu extrahieren.
Endspiel
- Ich arbeitete daran, XSS vollständig zur Ausführung zu bringen.
- Mit dem Attribut
srcsetfand ich eine neue Methode, um breitere JS-Syntax zu verwenden. - Mithilfe von Base64-Kodierung führte ich die XSS-Payload direkt aus.
- Da der TinyMCE-Editor auf der gesamten Website verwendet wird, ist die Auswirkung groß.
Analyse
- Die eigentliche Ursache der Schwachstelle ist die Funktion zum erneuten Hochladen von Bildern.
- Die Prüfung des Bild-Hostings lässt sich umgehen, indem der Domainname von Chess.com eingebunden wird.
- Der Rich-Text-Editor erlaubt verschiedene HTML-Elemente und eignet sich daher gut, um XSS zu erreichen.
- TinyMCE war auf dem neuesten Stand, aber eine Sanitization des finalen HTML fehlte.
- Chess.com sollte das endgültige HTML, das den Nutzern angezeigt wird, sanitizen.
GN⁺-Meinung:
- Dieser Blogpost beschreibt auf interessante Weise den Prozess, Sicherheitslücken zu entdecken und zu melden, die auf großen Online-Plattformen wie Chess.com auftreten können.
- XSS-Schwachstellen können eine ernsthafte Bedrohung für die Sicherheit von Websites darstellen, und das Finden und Beheben solcher Lücken ist für den Schutz der Privatsphäre der Nutzer sehr wichtig.
- Der Beitrag betont für Softwareentwickler und Sicherheitsexperten, wie wichtig es ist, Schwachstellen in Komponenten von Webanwendungen wie Rich-Text-Editoren zu erkennen und zu verhindern.
1 Kommentare
Hacker-News-Kommentare
Ich bin der OP. Vielen Dank für die positiven Kommentare. Als Hintergrund: Ich bin 17, bereite mich in Großbritannien auf meine A-Levels vor und überlege noch, an welche Uni ich gehen soll bzw. ob eine degree apprenticeship für mich infrage kommt.
Mein GitHub-Profil findet ihr hier -> https://github.com/Jayy001
Ich bin eines der Kernmitglieder von HashPals, habe Search-That-Hash entwickelt und bin außerdem Maintainer eines Open-Source-Repositories für kostenlose Software für das ReMarkable-Tablet.
Wenn du mehr darüber sprechen möchtest, melde dich gern; meine E-Mail steht in der Profilbeschreibung.
Und wenn du in die IT gehst, solltest du unbedingt auch Vertragsverhandlung und Finanzen lernen.
Damals, als meine Internet-Erfahrung im Wesentlichen daraus bestand, auf Chess.com als „ehrenamtlicher Bibliothekar“ jedes Mal zu verlieren, habe ich in Live-Partien auf Chess.com unbeholfen escapte Zeichen, schließende Tags, gängige Steuerzeichenketten und sogar OLE-Objekte eingeschleust.
Eric, der Gründer, bat höflich um ein formelleres Audit, aber ich lehnte ab, weil ich nicht offenlegen wollte, dass ich ein 11-jähriger Script-Kiddie war. Stattdessen erklärte ich die regulären Ausdrücke, die für die Moderation der Chaträume nötig waren, und wir befassten uns gemeinsam mit dem größeren Problem, wie man Cheating in einer asynchronen Umgebung erkennt.
Nach einigem Nachdenken sagte ich, die einzig mögliche Methode sei, alle spielentscheidenden, hochwertigen Züge mit den bekannten besten Zügen einer Engine zu vergleichen und per statistischer Inferenz zwischen starken menschlichen Spielern und Cheatern zu unterscheiden.
Natürlich war das damals völlig unrealistisch, und genau darauf lief auch die Schlussfolgerung hinaus. Trotzdem ist es eine ziemlich schöne Internet-Erinnerung geblieben, dass ein Kind gerade erst nach der Grundschule mit einem echten Webmaster über so ein nuanciertes Thema diskutiert hat.
Bei der Stelle „Dass mich dieses Feature an den MySpace-Wurm von etwa 2005 erinnerte – ich war damals noch nicht einmal geboren!“ wurde mir wieder bewusst, dass ich jeden Tag älter werde.
Der Starrsinn, Nutzern zu erlauben, HTML in die Site einzufügen, war ein riesiges Problem. Heutzutage würde man HTML-Eingaben ordentlich parsen und verbotene Attribute und Tags entfernen, aber damals lief das über Regex-Wahnsinn.
Ich weiß nicht, ob das damit zusammenhängt, aber ich habe in Chess.com-Partien schon selbst gesehen und sogar aufgezeichnet, dass jemand anders meine Züge für mich gemacht hat. Es kam auch vor, dass mir eine laufende Partie angezeigt wurde und ich in einer Situation ziehen konnte, in der das eigentlich nicht möglich hätte sein dürfen.
Wenn man googelt, findet man dazu ziemlich viele Threads. Ich weiß nicht, ob Chess.com das in den letzten Monaten behoben hat, aber als ich es melden wollte, wollten sie nichts davon hören.
All diese Partien passierten, während ich nicht auf der Site eingeloggt war. Eingeloggt habe ich es nie erlebt, aber Schach ist schlecht für meinen Blutdruck, deshalb spiele ich nicht oft.
Vom Titel her hatte ich deutlich anfängerhafteren Inhalt erwartet, tatsächlich wurde aber ein Exploit gebaut, der mehrere Stufen der Eingabevalidierung mit cleveren Umgehungen durchbricht. Es wurde sogar eine Subdomain eingerichtet, damit sie wie die Hauptdomain aussieht.
Ich hätte nicht erwartet, dass das funktioniert, und das war schon an sich interessant. Wenn man bedenkt, wie komplex es ist, Domains per Regex zu parsen, wirkt das wie etwas, das man leicht übersieht. Oder vielleicht wurde einfach nur innerhalb einer Variablen auf
'...'geprüft.Der Autor kennt sich in seinem Gebiet gut aus. Es ist beeindruckend, wie lange er sich offenbar in diese Fähigkeiten vertieft hat. Das dürfte eine ziemlich interessante Karriere werden.
Guter Artikel, OP. Viel Erfolg weiterhin auf deiner Hacking-Reise. Falls du es noch nicht kennst: Wenn in Payloads wie
alert(1)Klammern gefiltert oder encodiert werden, kannst du Backticks verwenden undalert\1`` ausprobieren.Wenn du JavaScript-Injection auf das nächste Level bringen willst, sind Brute Logics XSS-Cheat-Sheet und Gareth Heyes’ Javascript for Hackers gute Ressourcen. Manche Leute nehmen Cross-Site-Scripting auf die leichte Schulter, aber es ist immer noch sehr mächtig und weit verbreitet. Besonders dann, wenn – wie plugin-baby angemerkt hat – Session-Cookies nicht mit HttpOnly versehen sind.
Sehr cool. Ich lese gern Bug-Bounty-Analysen, besonders zu XSS. Es sieht immer so leicht zu finden aus, aber das ist nur Bestätigungsfehler; in Wirklichkeit sehe ich wohl die Zeit nicht, die in ergebnislose Tests und Sackgassen geflossen ist.
Bei der Stelle „Dass mich dieses Feature an den MySpace-Wurm von etwa 2005 erinnerte – ich war damals noch nicht einmal geboren!“ fühlte ich mich sofort alt.
Was ich OP zu diesem Vorfall fragen möchte: Wie hast du davon erfahren? War es Darknet Diaries, oder auf anderem Weg?
Ich fand es witzig, dass der Rich-Text-Editor als „Heiliger Gral“ bezeichnet wurde. Chess.com ist eine große Website, aber immer wenn ich auf alten Foren oder ähnlichen Seiten solche Editoren oder übertrieben verspielte Funktionen sehe, frage ich mich, ob die Site nicht voller Löcher ist. Jedenfalls ein hervorragender Artikel.
Die Stelle „Während des Bug-Bounty-Reports und der Prüfung versuchten die Entwickler, eine Sperre zu implementieren, als ich es erneut reproduzieren wollte, und die folgende Fehlermeldung erschien …“ wirkt ziemlich weit vom eigentlichen Sinn eines Bug-Bounty-Programms entfernt.