In der Softwareentwicklung gibt es Bereiche, in denen schon ein einziger Fehler katastrophale Folgen haben kann. Besonders anfällig sind dabei Kryptografiebibliotheken und Parser – also genau jene Bausteine, die Daten validieren, entschlüsseln oder die Integrität von Kommunikation sicherstellen.

In diesen Bereichen gilt: Ein vermeintlich kleiner Bug kann globale Auswirkungen haben. Zwei der bekanntesten Vorfälle der letzten Jahre illustrieren das eindrücklich, nämlich Heartbleed und Apples „goto fail“.

Muster 6: Kryptografie- und Parser-Fehler: Wenn eine einzige Codezeile die Sicherheit kippt

Heartbleed war ein Fehler in OpenSSL, einer der meistgenutzten Kryptografiebibliotheken der Welt. Der Bug betraf die Implementierung des TLS-Heartbeat-Mechanismus. Heartbeats sind kleine Nachrichten, mit denen Client und Server prüfen, ob die Verbindung noch lebt. Ein Client sendet (im Falle von TLS) dazu eine Nachricht, in der er unter anderem die Länge der eigenen Daten angibt. Der Server spiegelt diese Daten zurück.

Der fatale Fehler dabei war, dass die angegebene Länge nicht validiert wurde. Ein Angreifer konnte also behaupten, er sende zum Beispiel 64 KByte Daten, sendete tatsächlich aber nur 1 Byte. OpenSSL las daraufhin blind die fehlenden 63.999 Bytes aus seinem Speicher und schickte sie zurück. Diese Out-of-Bounds-Reads erlaubten es, mit ein bisschen Glück sensible Informationen wie Passwörter, Session Keys oder private Schlüssel auszulesen.

Die Tragweite war enorm. Millionen von Webservern waren betroffen, und weil TLS-Private-Keys kompromittiert waren, mussten die Betreiber zahllose Zertifikate austauschen. Der Bug bestand dabei über zwei Jahre in der OpenSSL-Codebasis, obwohl er nur wenige Zeilen lang war.

Fast zeitgleich machte Apple mit einem ebenfalls winzigen, aber folgenschweren Fehler namens goto fail Schlagzeilen. In der Implementierung der SSL-Zertifikatsprüfung in iOS und macOS fand sich eine verdoppelte Codezeile:

if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
    goto fail;
    goto fail;

Die zweite goto fail-Zeile war dabei falsch eingerückt, sodass Reviewer den Fehler schlecht erkennen konnten. Das System führte die zweite Zeile nämlich immer aus, unabhängig vom Ergebnis der if-Anweisung. Das wiederum hatte zur Folge, dass das System einen Teil der sicherheitskritischen Zertifikatsprüfung übersprang. Dadurch konnte ein Angreifer einen Man-in-the-Middle-Angriff durchführen, weil macOS, iOS und andere Apple-Betriebssysteme gefälschte Zertifikate akzeptierten. Wie bei Heartbleed war der betroffene Code winzig, die Folgen jedoch massiv.

Was haben beide Fehler gemein? Sicherheitskritischer Code ist oft alt und wenig verändert: Entwicklerinnen und Entwickler fassen Parser, Krypto-Routinen oder Protokollimplementierungen selten an – und wenn, dann oft unter Zeitdruck.

1. Einzelne Zeilen können sicherheitsentscheidend sein: Die Logik ist komplex, Tests decken selten alle Pfade ab, und Compiler warnen nicht vor falscher Einrückung oder fehlender Längenvalidierung.
2. Fehler bleiben lange unentdeckt: Heartbleed war über zwei Jahre im Code. goto fail fiel erst auf, als unabhängige Forscher den Code analysierten.

Wer sicherheitskritische Software entwickelt oder integriert, sollte daher einige Prinzipien beherzigen:

1. Vier-Augen-Prinzip und Code-Reviews: Kein sicherheitsrelevanter Commit sollte von nur einer Person geschrieben und gemerged werden.
2. Fuzzing und Differential-Tests: Automatisierte Tests, die zufällige und manipulierte Eingaben erzeugen, decken viele Parser- und Memory-Bugs auf.
3. Reproduzierbare Builds und Dependency-Audits: Developer müssen sicherheitskritische Software in derselben Version reproduzierbar bauen und signieren. Änderungen in Libraries müssen sie aktiv verfolgen und bewerten.
4. Minimaler und isolierter Code: Krypto- und Parser-Funktionen sollten möglichst klein und möglichst isoliert sein, um die Angriffsfläche zu minimieren.
5. Proaktive Schlüssel- und Zertifikatsrotation: Selbst wenn ein Fehler wie Heartbleed auftritt, kann ein schneller Schlüsselaustausch die Folgen begrenzen.

Die beiden Fälle zeigen: Security-Bugs entstehen oft in den unscheinbarsten Codezeilen. Wer sie ignoriert, riskiert nicht nur Ausfälle, sondern auch Vertrauensverlust und juristische Folgen. Für Unternehmen ist daher klar: Sicherheitskritische Bereiche benötigen besondere Prozesse, zusätzliche Tests und regelmäßige Audits.

(who)

App-Entwickler, die in Apples App Stores Software verkaufen, können ab sofort mehrere Einreichungen gleichzeitig vom App Review prüfen lassen. Dies teilte der iPhone-Hersteller mit. Mit zusätzlichen Custom Product Pages und der Umstellung auf einheitliche Offer Codes kündigte Apple noch weitere Verbesserungen für Entwickler an.

Bislang war es bei Einreichungen so, dass jeweils pro App immer nur eine gleichzeitig vorgenommen werden konnte. Mit der Änderung ist es möglich, zusätzliche Inhalte unabhängig von bestehenden Einreichungen in die Prüfung zu geben. Damit können Entwickler zum Beispiel In-App-Events einreichen, während noch eine neue App-Version im Review ist. Früher mussten sie immer erst einmal die bestehende Prüfung abwarten. Die Verbesserung soll zum Beispiel auch helfen, kritische Bugfixes getrennt von Custom Product Pages einzureichen.

Zahl der Custom Product Pages verdoppelt

Die maßgeschneiderten Landing Pages, von Apple Custom Product Page genannt, werden in ihrer Zahl von 35 auf 70 verdoppelt. Diese Seiten können zum Beispiel für die Bewerbung von Apps genutzt werden. Wer über den jeweiligen Link geht, bekommt dann zum Beispiel eine App-Store-Seite angezeigt, die andere Schwerpunkte setzt, als die allgemeine Info-Seite zur App im App Store. Wer möchte, kann die speziellen Landing Pages auch anzeigen lassen, wenn Nutzer des App Stores nach bestimmten Keywords suchen. Neu ist auch, dass jetzt Schlüsselwörter (Keywords) jeder einzelnen Custom Product Page zugeordnet werden können.

Offer Codes, die den kostenlosen oder vergünstigten Abruf einer App oder ihrer Inhalte ermöglichen, unterstützen jetzt alle Arten von In-App-Kauf. Sie sind damit für Verbrauchsgüter, Nicht-Verbrauchsgüter und Abonnements verwendbar, die sich nicht erneuern. Eine erweiterte Unterstützung wird für automatisch erneuernde Abonnements angeboten. Diese können so konfiguriert werden, dass sie nach einer Werbephase nicht automatisch verlängert werden. Apple teilte zugleich mit, dass die bisherigen Promo Codes für In-App-Käufe abgeschafft werden. Ab dem 26. März 2026 können keine neuen mehr erstellt werden. Bestehende behalten bis zum Ablauf ihre Gültigkeit. Für kostenlose App-Downloads bleiben Promo Codes bestehen.

Apple hat in der Vergangenheit immer wieder an Verbesserungen des App Review gefeilt. In den Anfangstagen waren vor allem lange Wartezeiten bei Prüfungen ein Ärgernis. Vor 2015 mussten Entwickler oft über eine Woche, manchmal sogar über zwei Wochen lang warten. Mit der Übernahme der App-Store-Leitung durch den früheren Marketingchef und heutigen Fellow Phil Schiller nahm das App Review Tempo auf. Im Mai 2016 betrug die durchschnittliche Wartezeit nur noch 1,95 Tage, zwischen den Jahren 2020 und 2024 lag sie statistisch bei durchschnittlich 11 Stunden.

(mki)

Microsoft hat die stabile Version 1.0.0 des Azure MCP Server veröffentlicht. Er implementiert das Model Context Protocol (MCP) und dient als Schnittstelle zwischen KI-Agenten und Azure-Diensten. So können Entwickler Cloud-Ressourcen über natürliche Sprache oder Code abfragen, verwalten und automatisieren. Das komplette Projekt stellt Microsoft als Open Source zur Verfügung.

KI-Agenten mit Azure kombiniert

Das Model Context Protocol ist ein offener Standard, der eine einheitliche Kommunikation zwischen den von KI-Agenten verwendeten LLMs und Backend-Systemen ermöglicht – unabhängig vom jeweiligen Agent-Framework. Der Azure MCP-Server unterstützt in Version 1.0.0 mehr als 47 Azure-Dienste, darunter Azure AI Foundry, Azure AI Search, Event Hubs, Service Bus, PostgreSQL, Kusto, Function Apps, Storage und Log Analytics.

Insgesamt stehen 170 Befehle zur Verfügung, die Microsoft zu strukturierten Funktionen zusammengeführt hat. Dabei gibt es drei Betriebsmodi: Der Standard-Namespace-Modus gruppiert Werkzeuge nach logischen Bereichen, alternativ lassen sich alle Tools aktivieren oder nur einzelne Funktionen freischalten. Dies soll insbesondere das Onboarding und Testen vereinfachen.

Für den DevOps-Einsatz stellt Microsoft ein Docker-Image über die eigene Container-Registry bereit. Damit lässt sich der Azure MCP Server in CI/CD-Pipelines integrieren. Die Unterstützung für gängige Entwicklungsumgebungen wie Visual Studio Code, Visual Studio und IntelliJ ist über entsprechende Erweiterungen vorgesehen.

Sicherheit und Performance im Fokus

Bei sicherheitskritischen Operationen setzt der Azure MCP Server auf verpflichtende Bestätigungen durch den Nutzer. Alle Interaktionen erfolgen innerhalb der Azure-Sicherheits- und Governance-Mechanismen. Microsoft hat zudem die Performance durch .NET Ahead-of-Time-Kompilierung (AOT) optimiert, was zu kürzeren Startzeiten und geringerem Ressourcenverbrauch führen soll.

Die vollständige Dokumentation und der Quellcode sind über das offizielle GitHub-Repository verfügbar. Für die nächsten Updates plant Microsoft laut Ankündigung eine engere Integration mit Azure-Werkzeugen und erweiterte Unterstützung für Container-Workloads.

(fo)