Sichere Programmierstandards Durchsetzung sicherer Codierpraktiken mit SAST

Anbieter zum Thema

Parasoft® Deutschland GmbH

MicroConsult Microelectronics Consulting & Training GmbH

RTI Real-Time Innovations

Verwendet man bei der Softwareentwicklung sichere Codierstandards führt das zu weniger Sicherheitsfehlern und letztlich zu einer besseren Qualität, die sowohl für Entwickler als auch für Benutzer eine stabilere Erfahrung bedeutet. Dieser Beitrag befasst sich mit den Grundlagen von sicheren Programmierstandards, Best Practices und der Frage, wie und wann sie eingesetzt werden sollten.

Sichere Programmierung bedeutet, dass Entwickler eine Reihe von Codierstandards oder Richtlinien für sichere Codierung anwenden, die sie in den Quellcode implementieren, um gängige Schwachstellen, die oft zu Cyberangriffen führen, zu verhindern und zu entschärfen. Das Implementieren sicherer Programmierpraktiken im Code ist die erste Verteidigungslinie, die vor der Ausnutzung von Software durch böswillige Akteure schützt und Angriffsflächen beseitigt, auf die Angreifer häufig mit Malware abzielen. Halten Unternehmen die Best Practices für sichere Kodierung gewissenhaft ein, können sie die Kosten für die Wartung von Software senken. Zugleich bleibt den Entwicklern mehr Zeit für Innovationen, anstatt sich mit der Behebung von Fehlern zu beschäftigen.

Sichere Programmierpraktiken gewährleisten, dass Sicherheitskontrollen in den Code implementiert werden, um durch schlecht entwickelten Code entstehende Sicherheitsprobleme zu verringern. Es ist zwingend notwendig, dass Unternehmen sichere Codierpraktiken festlegen. Auf diese Weise können sie ein Minimum an Software-Sicherheitsstandards zum Schreiben von Code festlegen, die das Unternehmen mit automatisierter statischer Analyse oder statischen Anwendungstests (SAST) durchsetzen und validieren kann. Diese Tools analysieren den Quellcode mit Regeln und Prüfprogrammen auf Syntaxverletzungen, undefinierte Variablen, Codequalität, Verschlüsselungs- und Sicherheitsverletzungen sowie Programmierfehler (um nur einige zu nennen).

Die statischen Analysetools von Parasoft verwenden sichere Codierstandards wie die CERT, die OWASP Top 10 (Teil der OWASP Secure Coding Guidelines), die MITRE Common Weakness Enumeration (CWE) und die DISA Application Security and Development STIGS in Regeln und Checks, wie in der folgenden Tabelle dargestellt.

Mangelhafte Programmierpraktiken führen zu Sicherheitsproblemen

Entwickler müssen sich über die Folgen ihrer Kodierungs- und Überarbeitungsaktivitäten im Klaren sein, wenn sie Sicherheitslücken in der Software schaffen und preisgeben. Nachfolgend sind einige gängige Dinge aufgeführt, die schief gehen können, wenn Entwickler keine sicheren Codierpraktiken befolgen und anwenden. Im Anschluss daran stellen wir bewährte Verfahren zum Eindämmen und Beheben dieser Sicherheitsprobleme vor.

Problemfall SQL-Injection: Dies geschieht, wenn ein Angreifer unsichere Eingaben in eine SQL-Abfrage einspeist, oft durch eine einfache String-Kette. SQL-Injection bedeutet ein höchst gefährliches Sicherheitsrisiko für Anwendungen, da es relativ leicht zu missbrauchen ist und dazu führen kann, dass der Angreifer die gesamte Datenbank verändert, löscht oder stiehlt. Die Angreifer können die Anwendung auch nutzen, um gefährliche Befehle auf dem Betriebssystem auszuführen, auf dem die Datenbank läuft, und sich so Zugang zu Ihrem Netzwerk verschaffen.

Problemfall Fehlerhafte Authentifizierung und Sitzungsverwaltung: Oft implementieren Entwickler die mit der Sitzungsverwaltung und Authentifizierung verbundenen Anwendungsaufgaben falsch. Dadurch können Angreifer Schlüssel, Kennwörter und Sitzungs-Tokens kompromittieren und es böswilligen Akteuren ermöglichen, Benutzeridentitäten zu ihrem Vorteil zu nutzen.

Problemfall Defekte Zugangskontrolle: Systeme setzen oft nicht korrekt durch, was authentifizierte Benutzer tun dürfen. Böswillige Akteure können solche Schwachstellen nutzen, um sich Zugang zu Funktionen und Daten zu verschaffen, z. B. zu Benutzerkonten und Dateien, zur Änderung von Daten oder zur Änderung von Zugriffsberechtigungen.

Problemfall Cross-Site Scripting (XSS): Dieses Problem tritt immer dann auf, wenn die Anwendung verdächtige Daten ohne ordnungsgemäße Authentifizierung auf einer neuen Webseite zulässt. Über XSS können Hackern Skripte im Browser des Ziels implementieren, die Websites zerstören oder Benutzer auf bösartige Websites schicken und Benutzersitzungen kontrollieren.

Best Practices: Beste Vorgehensweisen für Sicheren Code

Angesichts der zunehmenden Zahl von Cyberangriffen, die auf schlecht entwickelte Software zurückzuführen sind, ist es unerlässlich, dass Entwickler sichere Programmierverfahren einhalten. Wenn sie dies tun, verbessert sich die Produktivität, und die Bereitstellung der Software wird beschleunigt, da weniger Sicherheitsprobleme zu lösen sind. Dies erhöht die Wahrscheinlichkeit, dass der Entwurf (Build) genehmigt wird. Ein bestandener Build bedeutet: Alle kritischen und schwerwiegenden Probleme wurden behoben und es besteht kein wesentliches Risiko für das Unternehmen. Beispielsweise könnte ein Unternehmen Schwellenwerte (in Bezug auf den Schweregrad) festlegen und/oder bestimmte Probleme identifizieren, die nicht verhandelbar sind und bei deren Identifizierung der Build unterbrochen wird, bis die Probleme behoben sind.

Eine Möglichkeit, um sicherzustellen, dass ein Build erfolgreich ist, besteht darin, sichere Programmierpraktiken und eine Konformitätsüberprüfung mit statischer Analyse als Teil der automatisierten Tests durchzusetzen. Nachfolgend finden Sie bewährte Sicherheitspraktiken, die Entwickler im Rahmen der sicheren Programmierung befolgen können.

SQL-Injektionen entschärfen

1. Sichere Konfiguration verwenden: Oft enthalten Datenbankmanagementsysteme keine standardmäßige Sicherheitskomponente. Die Entwickler müssen sicherstellen, dass die Sicherheitskontrollen in der Hosting-Plattform und im Datenbankmanagementsystem (DBMS) funktionieren und korrekt konfiguriert sind. Für die meisten gängigen DBMS gibt es Leitfäden, Standards und Benchmarks. Der Datenbank Spickzettel bietet eine schnelle Anleitung für das Entwickeln einer sicheren Konfiguration.

2. Sichere Authentifizierung verwenden: Authentifizieren Sie alle Zugriffe auf eine Datenbank ordnungsgemäß. Verwenden Sie eine sichere Methode zur Authentifizierung des DBMS. Authentifizieren Sie sich nur über einen sicheren Kanal und sichern Sie die Anmeldedaten ordnungsgemäß, bevor Sie sie zur Verfügung stellen.

3. Sichere Kommunikation verwenden: Fast alle DBMS unterstützen eine Reihe von Kommunikationsmethoden wie APIs, Dienste usw., die sowohl unsicher (unverschlüsselt oder nicht authentifiziert) als auch sicher (verschlüsselt oder authentifiziert) sind. Für Entwickler ist es ratsam, nur die sicheren Kommunikationsmöglichkeiten zu nutzen, die mit Protect Data Everywhere (siehe unten) zur Verfügung stehen. Der Datenbank Spickzettel bietet schnelle Hilfe bei der Bereitstellung von sicherer Kommunikation.

Entschärfung fehlerhafter Authentifizierung und Sitzungsverwaltung

NIST 800-63b definiert drei Stufen für die Authentifizierungssicherheit, auch bekannt als AAL oder Authentication Assurance Level.

1. Passwörter: Stufe 1 gilt für Anwendungen mit geringem Risiko, die keine PII (persönliche Informationen) enthalten. Sie erfordert nur eine Ein-Faktor-ID, in der Regel ein Passwort. Zu den besten Vorgehensweisen gehören:

• Einsatz von Passwörtern mit mindestens 8 Zeichen bei Nutzung von MFA (Multi-Faktor-Authentifizierung) bzw. 10 Zeichen ohne MFA;

• Verwenden aller druckbaren ASCII-Zeichen, zusätzlich zum Leerzeichen;

• Förderung von langen Passphrasen und Passwörtern;

• Abschaffen der Komplexitätsanforderungen (lt. Entwicklern nicht sehr effektiv);

• Keine gängigen Passwörter verwenden, insbesondere solche, die schon einmal kompromittiert wurden;

• Wiederherstellung von Passwörtern, die MFA-Elemente implementiert;

• Sicheres Speichern von Passwörtern mit kryptografischen Kontrollen.

1. Mehrstufige Authentifizierung: Diese Stufe ist für risikoreichere Anwendungen gedacht, die personenbezogene, von Nutzern online eingegebene Daten enthalten. AAL-Stufe 2 erfordert MFA, einschließlich der Implementierung von QTP (Quick Test Professional). MFA bestätigt, dass ein Benutzer derjenige ist, der er vorgibt zu sein, und verlangt, dass sich die Person mit zwei oder mehr der folgenden Kombinationen identifiziert:

• Eine PIN oder ein Passwort;

• Ein Telefon oder Token;

• Biometrie z.B. Fingerabdruck oder Gesichtserkennung

3. Kryptografisch gestützte Authentifizierung: Wenn ein betroffenes System zu erheblichen finanziellen Verlusten, persönlichen Schäden, straf- oder zivilrechtlichen Verstößen oder einer erheblichen Beeinträchtigung des öffentlichen Interesses führen kann, ist eine Authentifizierung der Stufe 3 erforderlich. Die Entwickler verwenden in der Regel kryptografische Module, um dieses hohe Maß an Sicherheit zu erreichen.

• Sitzungsverwaltung: Eine Anwendung kann die Authentifizierung für eine begrenzte Zeitspanne verfolgen. Das ermöglicht dem Besucher die weitere Nutzung der Anwendung, ohne sich bei jeder Anfrage erneut authentifizieren zu müssen. Diese Nachverfolgung bezeichnet man als Sitzungsverwaltung.

• Erstellung und Ablauf von Sitzungen: Das System verfolgt den Zustand des Benutzers während einer Sitzung. Der Server speichert die Sitzung und fügt dem Benutzer einen Sitzungskennung zu, damit die Benutzerinformation die Sitzung mit den richtigen Daten für den Benutzer identifizieren kann. Weil der Client lediglich die Kennung verwaltet, sind auch vertrauliche serverseitige Sitzungsinformationen vor dem Client geschützt. Zu den Sicherheitskontrollen, die bei der Implementierung oder dem Aufbau von Sitzungsverwaltungssystemen zu berücksichtigen sind, gehören:
  – Sicherstellen, dass die Sitzungs-ID eindeutig, lang und zufällig ist.
  – Sicherstellen, dass die Anwendung eine neue Sitzung generiert oder zumindest die Sitzungs-ID während der Authentifizierung und erneuten Authentifizierung wechselt.
  – Sicherstellen, dass die Anwendung nach einer gewissen Zeit der Inaktivität eine Leerlaufzeit einführt und eine maximale Lebensdauer für jede Sitzung festlegt. Danach muss sich der Benutzer erneut authentifizieren.

• Cookies: Anwendungen verwenden in der Regel Browser-Cookies, um Sitzungskennungen von Webanwendungen zu speichern, wenn Systeme Sitzungsverwaltungsmethoden einsetzen. Ein paar Schutzmaßnahmen sind:
  – Nur eine kleine Anzahl von Domänen sollte auf die Cookies zugreifen können. Die Anwendung sollte ihre Pfade so markieren, dass die Tags am Ende oder kurz nach dem Ende der Sitzung ablaufen.
  – Setzen der „secure"-Tags, um sicherzustellen, dass das System nur über einen sicheren Kanal überträgt.
  – Setzen des „HttpOnly-Flags", um den Zugriff von JavaScript auf das Cookie zu verhindern.
  – Hinzufügen von „samesite"-Merkmalen zu Cookies, was einige aktuelle Browser daran hindert, Cookies zu senden, die seitenübergreifende Anforderungen enthalten. Dies schützt vor Angriffen mit Informationslecks und Fälschungen von Cross-Site-Demands.

• Tokens: Bei einigen Arten der Authentifizierung können serverseitige Sitzungen einschränkend sein. „Zustandslose Dienste" ermöglichen es dem System, über die Verwaltung der Sitzungsdaten die Leistung zu verbessern. Dies führt zu weniger Aufwand zum Überprüfen und Speichern von Benutzersitzungen auf dem Server. Eine „zustandslose" Anwendung erstellt ein temporäres Zugriffstoken, das das System zur Authentifizierung einer Client-Anfrage ohne die Anmeldedaten des Benutzers nach der ersten Authentifizierung verwendet.

• JSON-Web-Token (JWT): Bei diesem offenen Standard handelt es sich um eine in sich geschlossene, kompakte Methode zur sicheren Übermittlung von Informationen zwischen Einheiten in Form von JSON (JavaScript Object Notation). Das System kann die Informationen verifizieren, da sie digital signiert sind. Bei der Authentifizierung erstellt das System ein JWT-Token, das vom Server vor der Verarbeitung überprüft wird. Der Server speichert das JWT nicht immer. Das System erhält die Integrität des Tokens mit einer digitalen Signatur aufrecht, so dass ein späterer Server bestätigen kann, dass das JWT weiterhin gültig ist und niemand es seit der Erstellung des Tokens durch das System beschädigt hat.
  Diese Methode ist portabel und zustandslos, d. h. auch wenn Server- und Client-Technologien unterschiedlich sin, können sie dennoch interagieren.

Ungeschützte Daten vermeiden

Gehen Sie wie folgt vor, um ungeschützte Daten zu vermeiden:

• Klassifizieren Sie die Informationen in der Anwendung nach dem Grad der Sensibilität und ordnen Sie jeder Datenkategorie die entsprechende Schutzregel zu.

• Verschlüsseln Sie die im Transit befindlichen Daten. Zum Schutz von Webanwendungsdaten über ein Netzwerk verwenden Entwickler in der Regel ordnungsgemäß konfiguriertes TLS (Transport Layer Security).

• Verschlüsseln Sie Daten im Ruhezustand. Wenn möglich, vermeiden Sie das Speichern sensibler Daten. Wenn Sie sie allerdings speichern müssen, sollten Sie sie unbedingt kryptografisch schützen.

• Sichern Sie die lokale Speicherung auf mobilen Geräten. Weil diese oft gestohlen werden oder verloren gehen, können die darauf gespeicherten Informationen leicht nach außen gelangen. Die Besitzer sollten nur ein Minimum an sensiblen Daten auf ihren Geräten speichern und diese in dem angegebenen Datenspeicherverzeichnis ablegen.

• Verwalten Sie die Lebenszyklen von geheimen Schlüsseln. Entwickler verwenden geheime Schlüssel in Anwendungen für vertrauliche Funktionen, z. B. zum Schutz von Kreditkarten und zum Signieren von JWTs. Verwalten Sie Schlüssel richtig, indem Sie:
  - Sicherstellen, dass alle geheimen Schlüssel gegen unbefugte Nutzung geschützt sind;
  – Unabhängige Schlüssel verwenden, wenn mehrere Schlüssel benötigt werden;

• – Schlüssel ordnungsgemäß aufbewahren, am besten ingeheimen Tresoren;
  – Anwendungen zur Änderung von Schlüsseln und Algorithmen bei Bedarf entwickeln; und
  – Funktionen zur Unterstützung der Schlüsselrotation entwickeln.

• Verwalten Sie Anwendungsgeheimnisse. Anwendungen verfügen über viele für den sicheren Betrieb notwendige „Geheimnisse" wie Kennwörter, Zertifikate und Kodierungsschlüssel. Wenn jemand diese Geheimnisse kompromittiert, kann dies zu einem kompletten Systemausfall führen.
  So verwalten Sie Anwendungsgeheimnisse:
  – Übergeben Sie sie nicht über Umgebungsvariablen und speichern Sie sie nicht in Konfigurationsdateien oder Code.
  – Bewahren Sie sie sicher in geheimen Tresoren auf.

Vermeiden von defekten Zugangskontrollen

Entwickler können die folgenden Maßnahmen zur Zugangskontrolle bereits in der Entwurfsphase berücksichtigen:

• Die Zugangskontrolle von Anfang an integrieren; außerdem Anpassungen zulassen.

• Alle Anfragen müssen die Zugriffskontrollen zwingend durchlaufen.

• Standardmäßig verweigern, wenn das Programm die Anfrage nicht ausdrücklich erlaubt.

• Gemäß dem „Prinzip der geringsten Privilegien" sicherstellen, dass alle Programme, Prozesse und Benutzer so wenig Zugriff wie möglich erhalten.

• Keine feste Programmierung der Rollen. Zu viele Programme verwenden standardmäßig eine rollenbasierte Zugriffskontrolle, die anfällig ist und keine Mehrmandantenfähigkeit sowie keine horizontalen und datenspezifischen Zugriffskontrollregeln zulässt. Außerdem ist sie schwer zu überprüfen.

• Protokollieren Sie jeden Fehler bei der Zugriffskontrolle. Diese können auf Angreifer hindeuten, die die Anwendung nach Schwachstellen durchsuchen.

Entschärfen von Cross-Site Scripting (XSS)

Escaping und Kodierung sind Verteidigungsmethoden, die Injektions-Hacks verhindern helfen. Beim Escaping fügt der Programmierer ein bestimmtes Zeichen vor der Zeichenfolge hinzu, um deren Fehlinterpretation zu verhindern, beispielsweise einen Backslash ( \ ) vor einem doppelten Anführungszeichen ( " ), damit das System es als Text und nicht als Signal zum Schließen einer Zeichenfolge interpretiert. Kodierung, auch Ausgabekodierung genannt, bedeutet, dass der Entwickler Sonderzeichen in eine andere, aber gleiche Form umwandelt, so dass sie im Interpreter nicht gefährlich sind. Zum Beispiel wird < in die Zeichenkette < geändert, wenn man in HTML schreibt.

Weitere Methoden zum Schutz vor Injektionen sind die kontextbezogene Ausgabecodierung, die Entwickler beim Erstellen einer Benutzeroberfläche implementieren; die Neutralisierung bestimmter Metazeichen bei der Eingabe in einen Befehl eines Betriebssystems; die Unicode-Codierung als eine Methode zur Speicherung von Zeichen unter Verwendung mehrerer Bytes; und die Kanonisierung, bei der Systeme Daten in eine Standard- oder einfache Form umwandeln.

Mit SAST die Codier-Praktiken verbessern

Softwareentwickler nutzen SAST (Static Application Security Testing) für automatisierte Tests zur Analyse des Quellcodes, ohne den Code auszuführen oder zu starten. Ziel ist die Identifizierung von Verletzungen des Codes und Sicherheitslücken, die Software-Schwachstellen enthüllen könnten. SAST gilt als „White Box"-Testansatz, da es Zugriff auf den Quellcode hat, der das Design, das Framework und die Implementierung des Systems und/oder der Anwendung dokumentiert.

SAST verwendet die im Quellcode dokumentierten Details zusammen mit der Codestruktur, um das Einhalten der Standards und Richtlinien für sichere Programmierung zu gewährleisten. SAST nutzt Regeln und Checker, um die Konformität durchzusetzen und zu bestätigen sowie Verstöße gegen die Programmierpraktiken der Entwickler aufzudecken. Entwicklungsteams können zu Beginn des Entwicklungsprozesses mithilfe verschiedener sicherer Codierungsstandards und -richtlinien wie CERT Secure Coding Standards und CWE sicherstellen, dass die Software bestimmte Qualitäts- und Sicherheitsanforderungen erfüllt.

Es ist anzumerken, dass leistungsstarke und erfahrene Softwareentwicklungsunternehmen mithilfe dieser Standards und Praktiken Sicherheitsrichtlinien und Regeln für Entwicklungsteams festlegen. Viele Unternehmen fügen zusätzliche Richtlinien für die Schulung und Sensibilisierung von Entwicklern hinzu. Die OWASP Top 10 und die Seven Pernicious Kingdoms spielen eine Schlüsselrolle bei der Schärfung des Bewusstseins für Dinge, die bei der Programmierung schiefgehen können.

Da die SAST-Software nicht ausgeführt werden muss, um eine Analyse durchzuführen, können Entwickler sie nahtlos in ihre bestehenden Entwicklungs-Workflows implementieren, um den Code in Echtzeit zu analysieren und alle Code-Verletzungen, die durch Code-Regeln und -Prüfer ausgelöst werden, sofort zu erkennen. Das hilft beim Auffinden von kritischen Qualitäts- und Sicherheitsprobleme innerhalb des Arbeitsablaufs des Entwicklers, wo die Kosten für die Behebung von Sicherheitsproblemen am niedrigsten sind (siehe Grafik). Das Ergebnis ist eine qualitativ hochwertigere Software mit weniger Sicherheitsproblemen oder Schwachstellen – damit gewinnen Unternehmen Vertrauen in eine schnellere Softwareimplementierung und -bereitstellung.

Static Application Security Testing (SAST) – Statische Analyse nicht erst am Ende beginnen

Statische Analyse zur Sicherheitstest-Toolbox hinzufügen

Die Integration von SAST in die Arbeitsabläufe von Entwicklern unterstützt beim Sichten von Code-Verletzungen. SAST kann aber auch nahtlos in eine automatisierte Pipeline integriert werden, um Code-Commits zu analysieren, bevor die Software für die Produktion freigegeben wird. Jeder Commit kann automatisch einen Scan durch ein SAST-Tool auslösen.

Die SAST-Tools von Parasoft nutzen KI/ML für inkrementelle Scans, die nur den Code analysieren, der im Rahmen dieser Übergabe geändert wurde. Dies ermöglicht eine effizientere Nutzung von SAST und bietet Entwicklungsunternehmen eine historische Ansicht der Scans. Die Integration von SAST in den CI/CD-Prozess ist ein wesentlicher Bestandteil bei der Erstellung von hochwertigem, zuverlässigem und sicherem Code während der Integration und vor der endgültigen Auslieferung. Sie entspricht dem Konzept der kontinuierlichen Software Assurance, bei dem Software Assurance-Praktiken in die Entwicklungsaktivitäten automatisiert werden, um eine schnelle Softwarebereitstellung und -auslieferung zu gewährleisten.

* Kevin E. Greene ist Director of Security Solutions bei Parasoft.

(ID:48083059)