Schlechte Codierungsmuster können zu großen Sicherheitsproblemen führen … warum fördern wir sie also?

Eine Version dieses Artikels erschien bei DZone. Er wurde aktualisiert und hier erneut veröffentlicht.

‍

Seit gefühlt einer Ewigkeit diskutieren wir über das „Shifting Left“ im SDLC, also die Berücksichtigung von Security-Best-Practices von Beginn der Softwareentwicklung an. DevSecOps war ein großer Fortschritt, nicht zuletzt wegen der Betonung der gemeinsamen Verantwortung für Sicherheit und der Fähigkeit sicherheitsbewusster Entwickler, gängige Schwachstellen bereits beim Schreiben des Codes zu verhindern.

Wir wissen auch – ebenfalls seit Ewigkeiten –, dass die Art der Schulung für sicheren Code entscheidend dafür ist, Entwickler einzubinden und weiterzubilden. Lösungen mit geringem Aufwand, die nur auf regulatorische Compliance abzielen, fördern nicht die klugen Sicherheitsköpfe der Zukunft, und das haben die meisten Sicherheitsexperten inzwischen erkannt. Dynamisches, kontextbezogenes Lernen ist am effektivsten, aber es ist entscheidend, die Nuancen dabei zu verstehen.

Wenn wir gegen Angreifer bestehen wollen – und die haben immer einen Vorsprung gegenüber einem Unternehmen –, benötigen Entwickler eine ganzheitliche Lernumgebung mit aufeinander aufbauenden Inhalten, die kontinuierlich Fähigkeiten vermitteln, die auf Best Practices basieren.

Von Entwicklern umgesetzte Sicherheitsmaßnahmen sind kein Selbstläufer.

Unser Ethos basiert darauf, dass der Entwickler im Zentrum einer präventiven Sicherheitsstrategie steht, direkt auf Code-Ebene und darüber hinaus. Das ist selbstverständlich, und sicherheitskompetente Entwickler sind der einfachste Weg, um die Art von häufigen Sicherheitslücken zu verhindern, die durch schlechte Programmiermuster entstehen (wie Log4Shell, um ein aktuelles, verheerendes Beispiel zu nennen).

Die Verteidigungstechniken, die wir zur Weiterbildung von Entwicklern einsetzen können, variieren jedoch, auch wenn sie formal in dieselbe Kategorie von Schulungen fallen.

Stellen Sie sich zum Beispiel vor, man würde Ihnen das Backen eines Kuchens nur mit Anweisungen beibringen, was Sie nicht tun sollen. „Nicht zu lange backen“ und „die Eier nicht vergessen“ lässt viel Spielraum für Interpretationen und führt mit hoher Wahrscheinlichkeit zu einem Ergebnis, das reif für Nailed It! ist. Dasselbe gilt für die Ausbildung in defensiver Sicherheit; was man nicht tun sollte, ist nur ein sehr begrenzter Teil der Diskussion und bietet keine praktischen Ratschläge, um wirklich mit einer defensiven Denkweise zu handeln. Man kann Entwicklern sagen: „Konfiguriere diese API nicht falsch“, aber ohne Verständnis dafür, was eine korrekte und sichere Konfiguration ausmacht, bleibt viel Raum für Fehler.

Entwickler können Schwachstellen nur dann effektiv reduzieren, wenn sie grundlegend verstehen, wie diese entstehen, warum sie gefährlich sind, welche Muster ihnen zugrunde liegen und welche Design- oder Programmieransätze sie in ihrem Arbeitsalltag beheben. Ein stufenweiser Lernansatz vermittelt das nötige Wissen, um sicher zu programmieren, eine Codebasis zu schützen und sich als sicherheitsbewusster Entwickler zu etablieren. Und ja, ein Teil dieses stufenweisen Lernens sollte sich auch mit der Angreiferperspektive befassen; dies ist entscheidend, um das laterale Denken zu schulen, was bei der Bedrohungsmodellierung und der Verteidigungsstrategie von unschätzbarem Wert ist.

Die Verstärkung schlechter Programmiermuster ist eine Falle, die wir nicht ignorieren dürfen.

Eine unglückliche Realität bei einigen Lernmethoden für Entwickler ist, dass der „defensive“ Teil – selbst wenn das Training mit Angriffstechniken strukturiert ist – schlechte Gewohnheiten verstärken kann, auch wenn sie technisch gesehen die Codesicherheit validieren.

Die Produktion von qualitativ hochwertigem Code sollte die Basis jeder Softwareentwicklung sein, aber die Definition von „Qualität“ scheint immer noch umstritten zu sein. Die Realität ist, dass unsicherer Code nicht als Qualitätscode angesehen werden kann, selbst wenn er ansonsten funktional und elegant ist. Der Haken ist, dass sicherer Code nicht automatisch auch qualitativ hochwertig ist. Mit anderen Worten: Schlechte Programmiermuster können zwar ein Sicherheitsproblem beheben, dabei aber ein neues einführen oder die Software möglicherweise komplett beschädigen.

Schauen wir uns ein Beispiel für qualitativ minderwertigen Code in Form eines Fixes für eine fehlerhafte Authentifizierung an, sowie die sicherste Version nach Best Practices:

‍

using System;

using System.Collections.Generic;

using System.Linq;

using System.Threading.Tasks;

using Microsoft.AspNetCore.Authorization;

using Microsoft.AspNetCore.Http;

using Microsoft.AspNetCore.Mvc;

‍

namespace BadFixesAPI.Controllers

{

    [Route("api/[controller]")]

    [ApiController]

    public class AlertsController : ControllerBase

    {

        private DatabaseContext context = new DatabaseContext();

‍

        [HttpGet(Name = "GetAlerts")]

        // Stellt nicht sicher, dass der Benutzer authentifiziert ist

        public IEnumerable<Alert> Get()

        {

            return context.GetAlerts();

        }

‍

        [HttpGet(Name = "GetAlerts")]

        // Stellt sicher, dass der Benutzer authentifiziert ist, prüft jedoch keine Rollen

        [Authorize()]

        public IEnumerable<Alert> GetBadFix()

        {

            return context.GetAlerts();

        }

‍

        [HttpGet(Name = "GetAlerts")]

        // Stellt sicher, dass der Benutzer authentifiziert ist UND die Rolle „Administrator“ besitzt

        [Authorize(Roles = "Administrator")]

        public IEnumerable<Alert> GetGoodFix()

        {

            return context.GetAlerts();

        }

    }

}

‍

Im ersten Beispiel gibt es keine Überprüfung, ob der Benutzer authentifiziert ist – das ist so unsicher, wie es nur geht. Das zweite Beispiel ist zwar besser, da es eine Authentifizierungsprüfung durchführt, versäumt es jedoch, die zugewiesenen Rollen und die erforderlichen Berechtigungen für die angeforderten Informationen zu prüfen. Das dritte Beispiel prüft sowohl die Benutzerauthentifizierung als auch die Zuweisung der Rolle „Administrator“. In einer Zeit, in der das Prinzip der minimalen Rechtevergabe (Least Privilege) der Standard sein sollte, ist es entscheidend, dass Rollen so konfiguriert und geprüft werden, dass Informationen nur nach dem Need-to-know-Prinzip zugänglich sind. 

Die höchste Priorität für Entwickler ist die Erstellung von Funktionen. Sicherheit wird zwar nicht absichtlich vernachlässigt, aber sie verfügen nicht unbedingt über die Fähigkeiten, schlechte Codierungsmuster zu vermeiden, die zu Sicherheitslücken führen. Zudem gehört sichere Programmierung selten zum Maßstab eines guten Ingenieurs. Wir fördern diese schlechten Angewohnheiten indirekt, wenn die Funktionen nur beeindruckend genug sind – und genau diese Denkweise muss sich ändern. Das Problem ist, dass einige Lernpfade zur praktischen Code-Sanierung potenziell Code fördern, der zwar sicher, aber qualitativ minderwertig ist. Durch eine binäre „Sicher/Unsicher“-Bewertung, anstatt tiefer zu prüfen, ob dies wirklich der beste Ansatz zur Fehlerbehebung und Wahrung der Softwareintegrität ist, bleiben Details im Verborgenen, die fatale Folgen haben können. 

Ohne Entwickler durch den gesamten Prozess zu führen, um ein vollständiges Bild sicherer Programmierung zu vermitteln, zementiert dieser Ansatz genau die Probleme, die er lösen soll. Stellen Sie sich vor, wir bekämen alle unseren Führerschein allein dafür, dass wir ein Fahrzeug an ein Ziel bringen – ein Bestehen, obwohl wir rote Ampeln überfahren, durch eine Hecke gefahren sind und nur knapp einen Fußgänger verfehlt haben. Wir haben das Ziel erreicht, aber der Weg dorthin ist das, was wirklich zählt. 

Entwickler müssen dazu befähigt werden, mehr Wert auf die Erstellung sicherer Software zu legen.

Moderne Entwickler müssen viele Bälle gleichzeitig in der Luft halten. Es überrascht daher nicht, dass sie Sicherheitsschulungen als langweilig empfinden, besonders wenn diese nicht auf ihren Arbeitsalltag abgestimmt sind und sie von ihren Fristen und Prioritäten abhalten. Es ist zudem völlig unfair, ihre KPIs auf sichere Programmierung auszurichten, wenn ihnen die Fähigkeiten fehlen, die durch regelmäßige, passgenaue Lernangebote und ergänzende Tools aufgebaut werden müssten. Dennoch kann die Bedeutung sicherer Softwareentwicklung nicht hoch genug eingeschätzt werden, und es ist entscheidend, die Entwickler dafür zu gewinnen. 

Als ehemaliger Entwickler kann ich sagen: Wir wollen im Allgemeinen einen großartigen Job machen, und es ist sehr motivierend, wenn unsere Arbeit als qualitativ hochwertig wahrgenommen wird. Entwickler dazu zu motivieren, ihre Sicherheitskompetenzen kontinuierlich auszubauen, ist ein Selbstläufer – sie sollten dafür belohnt werden, dass sie die Bedeutung von Sicherheit auf Code-Ebene erkennen. Security-Champion-Programme, Bug-Bounties und Hackathons können großartige Gelegenheiten sein, eine positive Sicherheitskultur aufzubauen, und wer sich aktiv einbringt, sollte dafür auch belohnt werden.