SAST-Regelwartung modernisieren, um Schwachstellen schneller zu erkennen

Snyk Code hebt sich von den meisten Tools zur statischen Codeanalyse ab, indem es Regelsätze für seine Nutzer erstellt und pflegt – und ihnen so hilft, gängige und neu entdeckte Bedrohungen abzuwehren. In einem aktuellen Hub-Artikel wurde eine neue JavaScript-Schwachstelle namens Prototype Pollution beschrieben. Sie ermöglicht es Angreifern, ein JavaScript-Objekt-Prototype zu verändern oder zu „vergiften“ und verschiedene schädliche Aktionen auszuführen.

In diesem Beitrag zeigen wir am Beispiel von Prototype Pollution, wie die Funktionen zur Regelwartung von Snyk Code Entwickler und Sicherheitsexperten dabei unterstützen, ihre Anwendungen zu schützen. Wir gehen hier nicht näher auf Prototype Pollution ein. Wenn Sie mehr darüber erfahren möchten, empfehlen wir Ihnen diese Snyk Learn-Lektion oder den oben erwähnten Hub-Artikel.

Der herkömmliche Ansatz zur Pflege von Regelsätzen

Die Qualität eines Tools für statische Anwendungssicherheitstests (SAST) – und allgemeiner von Tools zur statischen Codeanalyse – hängt maßgeblich von der Qualität seines Regelsatzes ab. Einfach ausgedrückt: Das Tool wandelt den Quellcode in eine Datenstruktur um und sucht mithilfe dieser Regeln nach schädlichen Mustern. In den meisten modernen Scannern werden Regeln in einem eher ungewöhnlichen Stil namens logische Programmierung geschrieben.

Regelsätze zu schreiben und zu pflegen, ist keine leichte Aufgabe. Dafür sind fundierte Kenntnisse in der logischen Programmierung sowie der geprüften Programmiersprache und ihren Bibliotheken erforderlich. Nach dem Schreiben der Regeln stellt das Debuggen eine weitere Herausforderung dar. Bevor sie in der Produktion eingesetzt werden können, müssen sie an echtem Code getestet werden – das kann leicht Stunden dauern. Daher zeigen Untersuchungen1, dass Entwickler die Konfiguration nur selten ändern. In manchen Fällen sind benutzerdefinierte Regeln sinnvoll, doch meistens sollte das Tool einfach funktionieren.

Hinweis: Es gibt nur sehr wenige Fälle, in denen benutzerdefinierte Regeln sinnvoll sind (falls das auf Sie zutrifft, lassen Sie es uns wissen). In den meisten Fällen sollte das Tool einfach funktionieren – ohne dass Nutzer daran herumschrauben müssen!

Snyk Code modernisiert die Regelwartung

Snyk Code verfolgt einen anderen Ansatz. Wir betrachten den Regelsatz als Teil des Produkts und erwarten nicht, dass unsere Kunden diese Regeln pflegen müssen, damit das Tool nutzbar ist. In einer Branche, in der „benutzerdefinierte Regeln“ als notwendige Funktion eines SAST-Tools gelten, bietet Snyk seinen Nutzern eine einfachere Lösung. Unsere Sicherheitsexperten übernehmen die Verantwortung für den Aufbau und die Pflege des Regelsatzes. Dazu nutzen sie die leistungsstarke, schnelle Engine und eine große Zahl von Open-Source-Projekten als Test- und Trainingsdatensatz. Snyks „Human-in-the-Loop“-Ansatz überwacht und prüft die Ergebnisse fortlaufend und stellt die Qualitätskontrolle sicher – damit sich unsere Kunden darum nicht kümmern müssen.

Einer der Snyk-Ingenieure, die an der Regelwartung arbeiten, ist Alessio Della Libera, ein Sicherheitsforscher, der vor etwa einem Jahr zu Snyk kam. Auf die Frage nach dem besonderen Ansatz von Snyk Code beschrieb er ihn als „[…] eine Art Schleife. Änderungen vorzunehmen und sie mit den Ergebnissen des Datensatzes abzugleichen, dauert nur ein paar Minuten. So schnell iterieren zu können, ist äußerst hilfreich.“

Ein genauerer Blick

Der Trainingsdatensatz aus Open-Source-Projekten wird kontinuierlich überwacht und anhand von Scan-Ergebnissen und Nutzer-Feedback aktualisiert. Bei dieser Überwachung stellte Libera fest, dass sich eine unserer bestehenden Regeln nicht wie vorgesehen verhielt.

Nachdem er die Regel angepasst und getestet hatte, fielen zwei Ergebnisse besonders auf. Das Open-Source-Projekt appwrite.io enthielt eine Kopie der Bibliothek litespeed.js. Auf der Website heißt es: „Appwrite ist eine selbst gehostete Lösung, die Entwicklern eine Reihe einfach zu nutzender und integrierbarer REST-APIs für ihre zentralen Backend-Anforderungen bereitstellt.“ Snyk Code meldete dasselbe Problem sowohl in der über den Marketplace bereitgestellten Bibliothek als auch im Projekt selbst.

Auf einer laufenden Instanz von appwrite.io (zum Beispiel unter mywebsite.com) kann ein Angreifer mywebsite.com/auth/signup?__proto__[polluted]=yes aufrufen. In den Entwicklertools des Browsers lässt sich der JavaScript-Zustand überprüfen. Dort sehen Sie dann ein Mitglied namens polluted mit dem Wert yes. Bei der Untersuchung dieser Schwachstelle stellte Libera fest, dass bösartige Websites sie für einen Cross-Site-Scripting-Angriff (XSS) ausnutzen könnten.

Die Maintainer informieren

Nachdem die Maintainer des Projekts bei Appwrite informiert worden waren, veröffentlichten sie rasch Patches für das Paket appwrite/server-ce und das Paket litespeed.js. Da die Anwendung weit verbreitet ist, wurde auch ein CVE-Eintrag in der National Vulnerability Database veröffentlicht.

Nachdem die Schwachstelle behoben worden war, boten die Maintainer von Appwrite Libera eine Geschenkkarte an. Er bat darum, sie der Open-Source-Community zugutekommen zu lassen. Insgesamt können wir Appwrite für den Umgang mit dem Sicherheitsproblem nur loben. Indem das Team das Problem ernst nahm und gemeinsam mit der Community an einer Lösung arbeitete, trug es dazu bei, Open Source sicher zu halten.

Zusammenfassung

Durch die kontinuierliche Weiterentwicklung und Pflege der Regelsätze, auf denen Snyk Code basiert, sorgt Snyk für eine stetig wachsende Erkennungsgenauigkeit. Wir suchen fortlaufend nach neuen Fehlermustern und integrieren sie, während wir bestehende Regeln pflegen. Für uns ist der Regelsatz Teil des Produkts – und es liegt in unserer Verantwortung, ihn aufzubauen und zu pflegen.

Testen Sie Snyk Code noch heute kostenlos und entdecken Sie, wie unsere entwicklerorientierte Sicherheitsplattform Ihnen hilft, effizienter denn je hochwertigen Code zu schreiben.

1 Beller, M., Bholanath, R., McIntosh, S., & Zaidman, A. (2016). "Analyzing the state of static analysis: A large-scale evaluation in open source software". 2016 IEEE 23rd International Conference on Software Analysis, Evolution, and Reengineering, SANER 2016, 1, 470–481. https://doi.org/10.1109/SANER.2016.105