Das Paradigma der client-seitigen Webentwicklung verschiebt sich. Während JavaScript traditionell den Standard darstellt, ermöglichen Technologien wie WebAssembly (WASM) zunehmend die Ausführung kompilierter Sprachen direkt im Browser. Im Enterprise-Umfeld etabliert sich hierbei besonders Microsofts Blazor-Framework, welches die Ausführung von C#-Code im Client realisiert. Für uns als Penetration-Tester stellt sich bei dieser Architektur eine zentrale Frage: Bietet der Wechsel von interpretiertem JavaScript zu kompiliertem C# in der WASM-Sandbox einen messbaren Sicherheitsgewinn – oder verlagern wir bekannte Schwachstellen lediglich auf neue, komplexere Angriffsvektoren? Dieser Artikel analysiert die tatsächlichen Auswirkungen von Blazor WASM auf die Web Application Security.

Aus Sicht der Entwicklung bietet der Technologiewechsel klare architektonische Anreize:

• Homogener Tech-Stack: Die Nutzung von C# für sowohl Client- als auch Server-Logik minimiert Brüche in der Datenhaltung und reduziert Fehler bei der Schnittstellenkommunikation.
• Performance: WASM führt kompakten, vorkompilierten Bytecode aus, was das ressourcenintensive Parsing von Klartext-Skripten im Browser umgeht.
• Strenge Typisierung (Strong Typing): Im Gegensatz zum dynamisch typisierten JavaScript prüft C# Datentypen strikt zur Compile-Zeit. Dies verhindert nicht nur klassische Laufzeitfehler, sondern erschwert auch bestimmte Payload-Injections, da unerwartete Datentypen vom Compiler oder der Runtime direkt abgelehnt werden.

Doch aus der Security-Perspektive bleibt kritisch zu evaluieren: Führen diese Eigenschaften tatsächlich zu robusteren Anwendungen und einer kleineren Angriffsfläche, oder ändert sich lediglich die Art und Weise, wie wir beim Reverse Engineering vorgehen müssen?

Security-Vorteile von Blazor

Backend und Frontend können gemeinsame Logik teilen, beispielsweise für die Validierung von Benutzereingaben. Somit ist es leichter, im Backend die gleichen Validierungen vom Frontend erneut durchzuführen. Bei klassischen Webapplikationen werden teilweise Validierungen nur im Frontend durchgeführt, was dazu führen kann, dass Angreifende schädliche Anfragen direkt an das Backend senden können.

Zudem hat JavaScript als Sprache einige Features, welche teilweise zu Problemen wie beispielsweise Prototype-Pollution-Angriffen führen können. Diese sind in C# aufgrund der starken Typisierung nicht möglich.

Security-Nachteile von Blazor

Ein verbreiteter Irrglaube ist, dass Blazor WebAssembly sicherer sei, weil der Code als binäre Datei vorliegt. Tatsächlich ist das Gegenteil der Fall: C# wird in die sogenannte Intermediate Language (IL) kompiliert. Diese Metadaten sind extrem strukturiert und enthalten fast alle Informationen des ursprünglichen Quellcodes, inklusive Variablennamen und Logikstrukturen. Mit frei verfügbaren Tools wie ILSpy oder dotPeek lässt sich dieser Prozess mit nur einem Klick umkehren und der Quellcode ist (bis auf einige fehlende Verschönerungen von Blazor) fast wie im Original lesbar.

Einen Spezialfall bilden mit Ahead-of-Time-Kompilierung (AOT) gebaute Blazor-Anwendungen. Hierbei wird die Applikationslogik in WebAssembly kompiliert, wodurch ein Reverse Engineering deutlich komplexer und zeitaufwändiger wird. Jedoch bleiben in den .NET-DLLs weiterhin für Angreifende interessante Informationen wie die URL-Pfade (Routen) von allen Seiten erhalten. Theoretisch können mit sogenannten .NET Obfuskatoren auch Klassen und Methoden umbenannt werden, dies führt jedoch häufig zu Problemen mit .NET Features wie Reflection und Dependency Injection und wird daher oft nicht genutzt.

Im Vergleich dazu ist JavaScript zwar im Klartext lesbar, wird aber in der Praxis meist minifiziert und gebündelt. Das bedeutet, Variablennamen werden durch zufällige, kurze Namen ersetzt, Leerzeichen werden entfernt und alle Quellcodedateien werden in einer Datei kombiniert. Während JavaScript-Code dadurch oft zu einem (ohne LLMs oder ähnliche Tools) schwer lesbaren Zeichensalat wird, bleibt die Logik in dekompilierten C#-Dateien erschreckend transparent. Während sensible Geschäftslogik oder hardcoded Credentials im Frontend generell nicht gespeichert werden sollen, sind sie in Blazor somit einfacher zu finden.

Unveränderte Security-Probleme

Obwohl Blazor durch seine Architektur einige client-seitige Angriffsvektoren etwas minimiert, bleibt das Fundament der Websicherheit identisch: Das Backend ist die einzige Vertrauenszone. Viele Entwickler wiegen sich in falscher Sicherheit, da die Kommunikation zwischen Blazor-Frontend und dem .NET-Backend oft nahtlos wirkt. Doch genau hier lauern die klassischen Gefahren:

• Autorisierungsfehler: Nur weil eine Schaltfläche im Blazor-Frontend für einen normalen Benutzer ausgeblendet ist, bedeutet das nicht, dass die dahinterliegende API-Schnittstelle geschützt ist. Angreifende können die API-Endpunkte direkt aufrufen und so unberechtigten Zugriff auf Daten erhalten.

• Klassische Backend-Schwachstellen: Jede Blazor-Applikation ist auf Web-APIs angewiesen. Diese Schnittstellen sind das primäre Ziel für Injections oder Mass-Assignment-Angriffe. Eine starke Typisierung in C# schützt nicht vor einer fehlerhaft implementierten Datenbankabfrage auf dem Server.

• Unsicheres API-Design: Unsicheres Design von Abläufen und Logikfehler, die es erlauben, Prozesse zu manipulieren (zum Beispiel Preise im Warenkorb zu verändern oder Validierungen zu umgehen), sind in Blazor genauso präsent wie in JavaScript-basierten Anwendungen.

Fazit

Zusammenfassend lässt sich sagen: Die Technologie ändert sich, aber die Angriffsziele bleiben dieselben. Angreifende brauchen den Code im Browser gar nicht vollständig zu verstehen, weil das Backend die grösste Angriffsoberfläche bietet. Wenn ein höherer Schutz des Frontend-Codes gewünscht ist, so kann die Ahead-of-Time-Kompilierung aktiviert werden. Jedoch bringt dies gewisse Performanceunterschiede mit sich, wie eine grössere Anwendung, welche beim ersten Aufruf länger lädt, und einen deutlich längeren Kompilierungsprozess.

In jedem Fall empfehlen wir, Anwendungen vor dem Go-Live auf Schwachstellen zu prüfen. Wir unterstützen Sie gerne bei der Planung und Durchführung eines Pentests gegen Ihre Anwendungen. Melden Sie sich bei uns und planen dabei einen ausreichenden Projektvorlauf ein, damit wir Ihre Applikation auch zu dem von Ihnen gewünschten Zeit testen können.