Der iX-Workshop IT-Sicherheit: Aktuelle Angriffstechniken und ihre Abwehr beschäftigt sich mit aktuellen Angriffstechniken und den erforderlichen Schutzmaßnahmen gegen Angriffe auf Ihre IT-Systeme. Ausgehend von der aktuellen Bedrohungslage im Bereich der IT-Sicherheit lernen Sie praktische Strategien und Techniken zur Abwehr häufig auftretender Angriffe kennen. In einer Laborumgebung demonstriert Referent Oliver Ripka typische Angriffstechniken und stellt nützliche Tools vor, mit denen Sie selbst Angriffe erkennen und abwehren können.

Am Ende des zweitägigen Workshops haben Sie ein Verständnis dafür entwickelt, wie Angreifer vorgehen und welche konkreten Schutzmaßnahmen Sie ergreifen können, um Ihre Systeme zu sichern. Auf Basis dieses Wissens lernen Sie, die Schwachstellen und Angriffsmöglichkeiten Ihrer eigenen IT-Infrastruktur zu bewerten und die Wirksamkeit der eingesetzten Sicherheitsmaßnahmen einzuschätzen.

Ihr Trainer Oliver Ripka ist ein erfahrener Sicherheitsberater und Trainer bei Söldner Consult. Als Experte für Netzwerksicherheit liegen seine fachlichen Schwerpunkte in den Bereichen offensive Sicherheit und Netzwerkanalyse.

Der Sicherheitsworkshop richtet sich an IT-Administratoren, die ihren Blick für IT-Sicherheit schärfen wollen, sowie an Interessierte, die einen Überblick über die Funktionsweise von Cyberangriffen erhalten möchten.

(ilk)

Lohnt es sich, eine eigene Programmiersprache samt Syntax-Highlighting, Code Completion anderen Features im Editor nur für ein einzelnes Projekt zu erstellen? Was sich auf den ersten Blick nach viel Arbeit anhört, ist dank Language Server Protocol (LSP) deutlich einfacher geworden. Durch die reichhaltigen Möglichkeiten zur Interaktion mit Texteditoren wie Visual Studio Code eignen sich domänenspezifische Sprachen (Domain Specific Languages, DSL) als eine vollwertige und auch unterschätzte Möglichkeit der Gestaltung einer UX.

Anwenderinnen und Anwender jenseits der Informatik nehmen Spezifikationen oft mit Formularen vor. Je komplexer die Anforderungen sind, desto komplizierter wird die Umsetzung per Formular. Ein grotesk wirkendes Beispiel zeigt Abbildung 1: Anweisungen für einen Compiler, über ein Formular zu spezifizieren.

Gleich mehrere Gründe machen diese Idee so absurd:

• Die Spezifikation ist völlig aufgebläht: Die noch unvollständige Implementierung des Heron-Verfahrens zum Wurzelziehen lässt sich auch mit nur drei Zeilen Code umsetzen.
• Als direkte Folge davon ist das Formular deutlich schwerer verständlich.
• Für erfahrene Nutzer ist eine Programmiersprache sehr viel effizienter, weil sie in der gleichen Zeit wesentlich mehr Spezifikationen verfassen können.
• Es ist nur schwer vorstellbar, wie man eine formularbasierte Programmspezifikation versionieren kann. Textbasierte Algorithmen, wie Git sie verwendet, funktionieren hier vermutlich nicht.

Eine komplexe Spezifikation ist keine Besonderheit der Informatik, auch in anderen Fachbereichen gibt es schwierige Probleme, die immer mehr mithilfe von Computern gelöst werden sollen. Das kann die Automatisierung von Workflows sein, die Planung von Bauteilen oder Gebäuden, die Dokumentation von manuellen Prozessen oder vieles mehr. Ein Erfolgsfaktor von Programmiersprachen ist sicherlich, dass Programme sowieso abstrakt sind, während sich physische Bauteile oder Gebäudepläne schon immer auch grafisch haben repräsentieren lassen. Das Beispiel von Prozessautomatisierung zeigt aber, dass in vielen Bereichen ebenfalls abstrakte Konzepte auftreten.

Innerhalb der Informatik haben sich textuelle Sprachen auch jenseits des Programmierens bewährt. Admins legen Infrastrukturen in der Cloud schon lange nicht mehr per Formular an (diese Praxis wird eher als ClickOps geschmäht), sondern in Textform per Infrastructure-as-Code. Die Gründe sind dieselben: die Spezifikation ist schlanker, verständlicher, einfacher zu versionieren und man ist damit schneller.

Einfacher zu versionieren als Formulare, sind generische Formate wie JSON oder XML. Sie sind allerdings ursprünglich nicht dafür gedacht, für Menschen lesbar zu sein, sondern für Maschinen. Da viele Anwendungen ohnehin eine maschinenlesbare Sprache benötigen, ist es bequem, diese auch als alternative Schnittstelle anzubieten.

Aber auch solche Konfigurationsdateien erreichen nicht die Prägnanz, Lesbarkeit und Effizienz einer domänenspezifischen Sprache, zumal auch Validierungstechnologien wie XML Schema oder JSON Schema nur die Struktur der Dokumente validieren, aber wenig zur fachlichen Analyse beitragen können.

DSL als Alternative zu Formularen und Konfigurationsdateien

Komplexe Vorgänge, die Menschen gern sehr prägnant, lesbar und versionierbar ausdrücken wollen, kann man vorteilhaft mit einer domänenspezifischen Sprache spezifizieren, mit der gleichen Editorunterstützung wie bei Programmiersprachen. Beispiele wären Reisekostenabrechnungen, Nebenkostenabrechnungen, Steuererklärungen, Umsatzabfragen, Prozessautomatisierungen oder Bauplanungen.

LLM-basierte Chatfunktionen sind dabei kein Ersatz für domänenspezifische Sprachen, umgekehrt aber können domänenspezifische Sprachen die Intention eines KI-Systems einfacher überprüfbar machen. Anstatt agentenbasierte Systeme kritische Dinge tun zu lassen (was zumindest in der EU per AI Act streng reglementiert ist), kann man KI-Systeme auch eine in natürlicher Sprache vorliegende Beschreibung in eine DSL umformulieren lassen.

Das Language Server Protocol als Enabler für eine DSL-UX

Die Entwicklung einer domänenspezifischen Sprache reduziert sich nicht nur auf einen Parser: Nutzerinnen und Nutzer sind den Komfort von Syntax-Highlighting, Code Completion, bequemes Springen zur Definition oder zu Referenzen gewohnt, die wesentlich für eine gute UX und gesteigerte Produktivität sind. In den letzten Jahren ist dies durch das von Microsoft entwickelte Language Server Protocol (LSP) deutlich einfacher geworden. Dieses Prinzip hat sich auf weitere Bereiche ausgeweitet, zum Beispiel auf grafische Sprachen mit dem Graphical Language Server Protocol (GLSP). LSP und GLSP erlauben es, weitgehend auf die Entwicklung von UI-Komponenten zu verzichten und sich stattdessen auf die Semantik einer Sprache zu konzentrieren.

Aus diesem Grund können Editoren wie Visual Studio Code mit beliebigen Programmiersprachen umgehen: Während sie als Frontend immer dasselbe UI verwenden (im Fall von Visual Studio Code den Monaco-Editor), liefert ein LSP-Server die sprachspezifische Editorunterstützung. Da LSP auf JSON-RPC basiert, das keine Transportschicht definiert, lässt sich LSP wahlweise über stdin/stdout oder über Websockets betreiben. Das ermöglicht viele Optionen für das Deployment: Der Client kann in einer Desktopanwendung (in Fall von Visual Studio Code via Electron) oder im Browser laufen, während der Server entweder in die IDE eingebettet oder auf einem entfernten Rechner arbeitet.

Mittlerweile gibt es für die Entwicklung von LSP-Servern mehrere Frameworks, je nachdem, mit welcher Programmiersprache man die DSL entwickeln will. Für die Beschreibung der Grammatik der DSL kommt ebenfalls eine DSL zum Einsatz. Daraus generiert das Framework Parser, Klassen für den abstrakten Syntaxbaum und die Editorunterstützung. Entwicklerinnen und Entwickler können das Ergebnis durch manuellen Code ergänzen oder überschreiben. Beispiele für entsprechende Tools sind Xtext für Java (siehe auch: [1]), Langium für TypeScript und AnyText für .NET (siehe auch [2]).

Eine neue DSL entwickeln

Der Startpunkt für die Entwicklung einer neuen DSL ist mit allen dreien der genannten Frameworks eine Grammatik, die auch die abstrakte Syntax der Sprache ausdrückt. Die abstrakte Syntax ist hierbei die Definition der Konzepte, die die Sprache ausmachen. Für die Grammatik werden bei Xtext und Langium kontextfreie LL(k)-Grammatiken verwendet, bei AnyText Parse-Expression-Grammatiken (PEGs). Beide Klassen von Grammatiken arbeiten mit Nichtterminalen (= Platzhaltern) und Produktionsregeln, die bestimmen, wie ein Nichtterminal ersetzt werden kann. Diese Produktionsregeln lassen sich bequem über die Metasprache Erweiterte Backus-Naur-Form (EBNF) spezifizieren, die zusätzlich noch um Zuweisungen ergänzt wird, um auch die abstrakte Syntax angeben zu können.

Praktischerweise bietet Langium mit dem Playground eine Möglichkeit an, mit der Entwicklung einer DSL ohne Installation einer Software direkt im Browser zu beginnen. Für Xtext oder AnyText bieten die Tutorials gute Einstiegspunkte.

Um beispielsweise die (hier vereinfachte) Deklaration einer Klasse in einer Programmiersprache zu spezifizieren, genügt das folgende Fragment:

Class: ‘class’ name=ID ‘{‘ members+=ClassMember* ‘}’;

Dieses Beispiel geht davon aus, dass es weitere Nichtterminale ID und ClassMember gibt, die regeln, wie ein Identifier genau aussieht und was zulässige Member einer Klasse sein können. Der Postfixoperator * erlaubt hierbei beliebig viele Member. Alternativ sind auch + oder ? möglich, um mindestens oder höchstens ein Vorkommen zu beschreiben. Der Operator | erlaubt auch Alternativen, was unterschiedliche Arten von Membern ermöglicht. Besteht eine Regel ausschließlich aus Alternativen, dann wird das in der abstrakten Syntax durch Inheritance abgebildet.

Die Zuweisung = bzw. += weist das System darüber hinaus an, das Ergebnis des Nichtterminals ID bzw. ClassMember dem abstrakten Element des Nichtterminals zuzuordnen. Das geht entweder als einwertige Eigenschaft (beispielsweise, dass das Ergebnis von ID den Namen bilden soll) oder als mehrwertige Eigenschaft, dass das Ergebnis von ClassMember zur Auflistung members hinzugefügt werden soll.

Aus diesen Zuweisungen lassen sich dann auch Klassen ableiten, um die abstrakten Elemente der Sprache im Speicher darstellen zu können. Sowohl Xtext und Langium als auch AnyText unterstützen den Operator [], mit dem sich Referenzen abbilden lassen, dass also an einer gegebenen Stelle nur eine Referenz auf ein anderes syntaktisches Element erscheinen soll.

Die Konstruktion des Parsers bleibt zwar weitestgehend vor den Entwicklern verborgen, allerdings haben manche Klassen von Grammatiken Einschränkungen, die Entwickler einer DSL berücksichtigen müssen. So sind die Produktionen bei kontextfreien Grammatiken ungeordnet, bei PEGs aber geordnet, weswegen es konstruktionsbedingt keine Mehrdeutigkeiten gibt. Gängige Parser für kontextfreie Grammatiken unterstützen keine Linksrekursionen, für PEGs aber schon.

Die Unterstützung von Linksrekursionen ist vor allem für Ausdrücke wichtig, da man damit sehr intuitiv Formeln umsetzen kann. Insbesondere sind binäre Ausdrücke selbst Ausdrücke, beginnen aber auch mit einem Ausdruck. Für PEGs haben Warth und andere [3] eine Erweiterung von Packrat-Parsern entwickelt, die Linksrekursionen parsen kann, wobei das lineare Laufzeitverhalten von Packrat-Parsern erhalten bleibt.

In AnyText lässt sich daher eine einfache Expression-Grammatik wie in Listing 1 unten dargestellt implementieren. Hierbei überschreibt das Schlüsselwort returns, welche Klasse der abstrakten Syntax das Nichtterminal zurückgibt. Im Beispiel dient es dazu, nicht für jedes einzelne Nichtterminal eine Klasse einführen zu müssen. Das Schlüsselwort enum kommt zum Einsatz, um eine fixe Menge von Werten abzubilden. Ferner beschreibt das Schlüsselwort parantheses ein Nichtterminal für Klammerungen und terminal ein Terminal, dargestellt durch einen regulären Ausdruck.

grammar Expressions (exp)
root Expression

Expression:
  AdditiveBinary | Multiplicative;
AdditiveBinary returns BinaryExpression:
  left=Expression operator=AdditiveOperator right=Expression;
enum AdditiveOperator returns BinaryOperator:
  Add => '+'
  Subtract => '-';
Multiplicative returns Expression:
  MultiplicativeBinary | LiteralExpression | VariableExpression | ParanthesisExpression;
MultiplicativeBinary returns BinaryExpression:
  left=Multiplicative operator=MultiplicativeOperator right=Multiplicative;
enum MultiplicativeOperator returns BinaryOperator:
  Multiply => '*'
  Divide => '/';
LiteralExpression:
  value=Number;
VariableExpression:
  variable=Identifier;
parantheses ParanthesisExpression:
  '(' Expression ')';
terminal Number returns nmeta.Integer:
  /\d+/;
terminal Identifier:
  /[a-zA-Z]\w*/;

UX-Interaktionen im Editor über LSP

LSP ist nicht nur auf das Parsen von Text begrenzt, sondern erlaubt auch praktische Interaktionen mit einem Text in der IDE. Programmiererinnen und Programmierern sind Features wie Code Lenses oder Code Fixes geläufig. Sie erlauben es, Analyseergebnisse wie die Anzahl der Referenzen oder Autor und Datum der letzten Änderung an einer Methode einfach in das Sichtfeld einzublenden. Interaktionen wie Refactorings lassen sich ebenfalls direkt aus dem Code heraus starten.

Zu Features dieser Art gehören:

• Diagnostics: In den seltensten Fällen lassen sich Einschränkungen allein durch die Grammatik ausdrücken, auch domänenspezifische Analysen können auf Fehler hindeuten. Beispielsweise könnte man in einer DSL für Überweisungen eine Analyse des Empfängernamens einbauen und Fehler melden, sollte der Name nicht zur IBAN passen.
• Code Lenses: Code Lenses können an einer beliebigen Stelle im Text eine beliebige Zeichenkette anzeigen. Damit lassen sich viele Arten von Analysen darstellen. Code Lenses können auch Aktionen anbieten, zum Beispiel öffnet sich beim Klicken auf die Anzeige der Referenzen üblicherweise ein Fenster mit Details. Einige Editoren bieten auch an, Unit Tests per Code Lens zu starten. Recht generisch könnte man Code Lenses verwenden, um in einer DSL den derzeitig beschriebenen Zustand auf ein modelliertes System anzuwenden.
• Code Actions: Von Editoren wie der Visual-Studio-Familie mit einem Lampensymbol dargestellt, erlauben es Code Actions, zum Kontext passende Interaktionen auszuführen.
• Inlays: Inlays blenden Texte im Editor ein, die eigentlich gar nicht dort stehen. Während dieses Feature in Programmiersprachen vor allem dazu dient, inferrierte Typsignaturen oder Parameternamen einzublenden, lässt es sich prinzipiell für beliebige Analysen verwenden.
• Hover: Verweilt ein Nutzer mit der Maus auf einem Token, kann ein LSP-Server Kontextinformationen dazu liefern. Eine sehr clevere Nutzung ist beispielsweise, einen Hovertext für Schlüsselwörter mit Erklärungen dazu anzubieten. Gerade weil eine DSL nur für einen eingeschränkten Nutzerkreis gedacht ist, kann eine solche Unterstützung die Anwendung leichter zugänglich machen.

AnyText macht die Entwicklung dieser Features besonders einfach, indem es für jede Regel in der Grammatik eine Klasse generiert, in der Entwickler meist nur eine entsprechende Methode überschreiben müssen, um das jeweilige Feature zu aktivieren. Aber auch mit Langium oder Xtext lassen sich diese Features einfach nutzen.

Fazit: Alternative UX-Technologie

Domänenspezifische Sprachen haben neben Formularen oder KI-Agenten einen eigenen Platz als Möglichkeit verdient, mit der Endanwender spezifizieren, welche Probleme der Computer lösen soll. DSLs richten sich dabei vor allem an Expertinnen und Experten, die solche Spezifikationen häufiger verfassen müssen, für die also Produktivität, einfache Versionierbarkeit und Interoperabilität textueller Sprachen besonders vorteilhaft sind.

Dabei hat sich die Entwicklung neuer DSLs durch Innovationen wie das Language Server Protocol und Frameworks wie Langium, Xtext oder AnyText dramatisch vereinfacht. Wo Developer Parser früher per Hand schreiben mussten, können sie diese heute mit Editorunterstützung weitgehend aus der Spezifikation einer Grammatik ableiten, was den Aufwand stark reduziert. Daher sollten DSLs als alternative UX-Technologie durchaus in Betracht gezogen werden.

Literaturverzeichnis

[1] M. Eysholdt und H. Behrens, „Xtext: implement your language faster than the quick and dirty way,“ in Proceedings of the ACM International Conference Companion on Object Oriented Programming Systems Languages and Applications Companion, Reno/Tahoe, Nevada, USA, Association for Computing Machinery, 2010, pp. 307–309.

[2] G. Hinkel, A. Hert, N. Hettler und K. Weinert, „AnyText: Incremental, left-recursive Parsing and Pretty-Printing from a single Grammar Definition with first-class LSP support,“ Proceedings of the 18th ACM SIGPLAN International Conference on Software Language Engineering, SLE 2025, pp. 98–111, 12–13 Juni 2025.

[3] A. Warth, J. R. Douglass und T. Millstein, „Packrat parsers can support left recursion,“ in Proceedings of the 2008 ACM SIGPLAN Symposium on Partial Evaluation and Semantics-Based Program Manipulation, San Francisco, California, USA, Association for Computing Machinery, 2008, pp. 103–110.

(who)

Die c’t Foto-Community zeigt in dieser Woche eindrucksvoll, wie vielseitig Fotografie sein kann. Bekannte Motive erscheinen in neuem Licht, während einfache Objekte durch ungewöhnliche Techniken überraschend wirken. Mal stehen klare Formen und starke Kontraste, mal weiche Übergänge und reduzierte Farben im Vordergrund. Licht wird gezielt eingesetzt, um Strukturen sichtbar zu machen oder Stimmungen zu erzeugen.

Auffällig ist das Spiel mit Perspektive und Nähe. Enge Ausschnitte holen Details heran, während grafische Kompositionen den Blick lenken. Auch experimentelle Ansätze finden ihren Platz und erweitern den klassischen fotografischen Blick. So entsteht eine abwechslungsreiche Auswahl, die Technik, Gestaltung und Idee gleichermaßen verbindet.

Der Mond von SonyAlpha380

Ein bekanntes Motiv, das hier jedoch ganz neu entdeckt wird. Krater reiht sich an Krater über die Oberfläche des Mondes. Feine Strukturen und helle Ebenen treten klar hervor, während der Rand hart ins schwarze All abfällt. Das seitliche Licht modelliert jede Vertiefung und bringt die raue Landschaft deutlich zur Geltung. Die schräge Aufteilung verstärkt den Kontrast zwischen Licht und Dunkel. Der enge Ausschnitt holt den Mond überraschend nah heran und lenkt den Blick über seine vielen Details.

Aus gegebenem Anlass von der Onkel Werner

Ein Bild, das Raum für Gedanken über Glaube, Geschichte und Gegenwart lässt. Eine Christusfigur am Kreuz hebt sich sanft aus einem gelben Hintergrund hervor. Die Konturen verschwimmen und die Arme und der Körper wirken, als seien sie in Bewegung. Feine Linien im Hintergrund setzen klare Kanten und geben dem Bild Halt. Die Mischung aus Unschärfe und klaren Flächen zieht den Blick sofort an. Durch die reduzierte Farbwelt wird die Wirkung noch verstärkt und alles bleibt bewusst schlicht.

Siegel-Ei von vicia-faba

Ein einfaches Motiv wird hier zum visuellen Experiment. Die Aufnahme entsteht als Scan-Art direkt mit dem Scanner. Das Ei zerfließt, wobei die zeilenweise Abtastung die typischen horizontalen Verschiebungen erzeugt. Helles Gelb trifft auf tiefes Schwarz, weiche Verläufe auf harte Kanten.

Fotografin Erika Weber-Lange berichtet ausführlich: „Ich betreibe die Technik, mit dem Flachbett-Scanner Bilder anzufertigen, seit 26 Jahren und habe dabei diverse Vorgehensweisen entwickelt, die ich aber im Detail nicht preisgeben will. Das Bild Siegel-Ei entstand mit einem echten Ei auf der Glasplatte, das ich im Rüttel-Verfahren einscannte. Dies genau zu beschreiben wäre ohnehin kaum machbar, man muss da von Hand experimentieren, bis ein gutes Ergebnis entsteht.“

Bernadette von Thomas Ruppel

Eine Frau blickt ruhig in die Kamera und hat eine Hand locker auf der Stirn. Weiches Licht fällt auf ihr Gesicht und hebt Augen und Haut sanft hervor. Unscharfe Elemente im Vordergrund rahmen das Porträt und lenken den Blick in die Bildmitte. Die enge Perspektive schafft Nähe. Der gezielte Fokus auf das Gesicht sorgt für Klarheit und Ruhe, während Licht und Schatten für Tiefe sorgen.

Viele Gipfel von Lightpix84

Das Foto spielt mit der Idee von Landschaft in der Stadt. Die markante Glasfassade der Elbphilharmonie ragt wie ein Gebirgszug aus Glas und Stahl in den Himmel. Ihre geschwungene Dachlinie bildet mehrere klare Gipfel, die sich gegen den hellen, beinahe leeren Hintergrund abzeichnen. Der minimalistische Eindruck wird durch die reduzierte Farbgebung verstärkt und lenkt den Blick auf Form und Struktur. Die klare Perspektive betont die Höhe und lässt die Architektur fast grafisch wirken.

bedröppelt von uschi1956

Eine noch geschlossene Küchenschelle im Tau. Wassertropfen sitzen auf den feinen Härchen von Knospe und Blättern und heben jede Struktur klar hervor. Die Makroaufnahme zeigt die Pflanze formatfüllend, der ruhige, unscharfe Hintergrund trennt sie deutlich vom Umfeld. Die Mitte bleibt der visuelle Anker, während die Tropfen die Details liefern.

pozdrav suncu, zadar, croatia, 2022 von Marie Himmel

Sandalen auf Glas, darüber ein leichtes, rosafarbenes Kleid. Die spiegelnde Fläche verdoppelt die Szene und verwandelt einen einfachen Moment in ein grafisches Spiel. Die klaren Linien der Platten treffen auf die weichen Stoffstrukturen. Die tiefe Perspektive zieht den Blick direkt in die Reflexion. So verschmelzen Realität und Spiegelbild zu einer ruhigen, fast schwebenden Szene.

(vat)