Sicheres Coding beseitigt Schwachstellen wie XSS und Speicherlecks frühzeitig, erhöht die Ausfallsicherheit von Software und reduziert Risiken.
Proaktive Praktiken sparen Zeit und Geld, indem sie kostspielige Korrekturen nach der Veröffentlichung verhindern und das Vertrauen der Benutzer stärken.
Zu den Best Practices gehören die Validierung von Eingaben, die Sicherung von Code von Drittanbietern und die Nutzung von Tools wie SAST für kontinuierliche Überprüfungen.
Standards von OWASP, CERT und NIST helfen Entwicklern, sichere und zuverlässige Anwendungen zu erstellen.
Wiz Code unterstützt sichere Codierung mit Echtzeit-Scans, umsetzbarem Feedback und Anleitungen, um Ihren SDLC zu schützen.
Was ist sichere Codierung?
Sichere Codierung ist die Praxis, Software zu entwickeln, die resistent gegen Sicherheitslücken ist, indem bewährte Sicherheitsmethoden, -techniken und -tools frühzeitig in der Entwicklung angewendet werden. Anstatt nur an die Benutzererfahrung zu denken, stimmt Secure Coding jede Funktion mit Sicherheitsmaßnahmen ab – und zwar von Anfang an im Lebenszyklus der Softwareentwicklung.
Beispielsweise kann eine Anwendung, die alle Daten von einem Client akzeptiert, ohne sie zu bereinigen, einfacher zu implementieren, zu verwenden und zu warten. Es öffnet jedoch einen Einstiegspunkt für Angreifer, um bösartigen Code einzuschleusen.
The Secure Coding Best Practices [Cheat Sheet]
With curated insights and easy-to-follow code snippets, this 11-page cheat sheet simplifies complex security concepts, empowering every developer to build secure, reliable applications.
Download Cheat Sheet
Why is secure coding important?
Sicheres Coding bettet Sicherheit in die DNA Ihrer Software ein, um Schwachstellen wie SQL-Injection, Pufferüberläufe, Cross-Site-Scripting und mehr zu verhindern. Es ist nicht nur die Verhinderung von Sicherheitsverletzungen, sondern auch eine Möglichkeit, das Vertrauen der Benutzer zu schützen, die Sicherheit nach links zu verschieben und die strengen Standards der Datenschutzgesetze zu erfüllen.
Der Lohn? Weniger böse Überraschungen nach dem Start, stärkere Apps und besserer Schutz für Benutzer und Ihr Unternehmen.
Sieben sichere Codierungstechniken für die Erstellung sicherer Software
Ein sicherer Softwareentwicklungsprozess beginnt mit der Befolgung der richtigen Codierungspraktiken, die dazu beitragen, Schwachstellen zu vermeiden und Ihre Anwendungen sicher zu halten. Wenn Sie'Wenn Sie auf der Suche nach einer ausführlicheren Ressource sind, lesen Sie unbedingt die OWASP Secure Coding Requirements in ihrem Entwicklerhandbuch.
In der Zwischenzeit finden Sie hier einige wichtige Techniken, mit denen Sie sofort beginnen können, um sicherere Softwaresysteme zu erstellen:
1. Verwenden Sie moderne Sprachen und Tools
Viele speicherbezogene Sicherheitslücken betreffen Programmiersprachen mit manueller Speicherverwaltung und ohne integrierte Speicherprüfungen. Wenn Sie ein neues Projekt starten, stellen Sie sicher, dass Sie wirklich C/C++ dafür benötigen, und wenn Sie dies tun, verwenden Sie Intelligente Zeiger und Statische Code-Analysatoren um die Auswirkungen von Sprachfehlern zu minimieren.
Wenn Sie Systemprogrammierfunktionen benötigen, ist eine modernere Sprache wie Rost kann eine gute Wahl sein, da das Typsystem die Speicherauslastung zur Kompilierzeit überprüft. Zick-Zack könnte auch eine gute Alternative sein, da es keine versteckte Ablaufsteuerung oder Speicherzuweisungen gibt.
Wenn Sie keine Systemprogrammierfunktionen benötigen, kann die Verwendung einer Garbage-Collection-Sprache wie Java oder C# Sie vor vielen Speicherproblemen schützen.
2. Validieren und Bereinigen von Eingabe- und Ausgabedaten
Nicht validierte Benutzerdaten sind der Hauptgrund für Injektionsfehler. Aus diesem Grund ist es von entscheidender Bedeutung, alle Daten zu validieren, die in Ihr System gelangen. Die Hygiene ist ein weiterer Schritt, der die Sicherheit in Schach halten kann, ohne die Benutzerfreundlichkeit zu beeinträchtigen. Anstatt eine Benutzereingabe abzulehnen, wenn sie ungültig ist, schneidet die Bereinigung problematische Eingabeteile (z. B. JavaScript in HTML) aus und verwendet die verbleibenden Daten. Wenn Sie in einer Client-Server-Umgebung ausgeführt werden, stellen Sie sicher, dass diese Überprüfung und Bereinigung auf dem Server erfolgt. Das bedeutet, dass Sie Validatoren und Desinfektionsmittel an alle API-Endpunkte, die Benutzerdaten akzeptieren. Es kann auch bedeuten, dass Sie Datenformate wählen, die leicht zu validieren sind, z. B. einfaches Markdown anstelle von vollwertigem HTML akzeptieren.
Es ist nicht immer möglich, Eingabedaten sauber zu halten. Auch Validierungsbibliotheken weisen Fehler auf. Um sicherzustellen, dass nichts zu Ihren Benutzern durchdringt, zeigen Sie nur Ausgaben, die auf Benutzereingaben basieren, auf sichere Weise an (d. h. rendern Sie kein HTML).
3. Überprüfen der Codeintegrität von Drittanbietern
Bibliotheken und Frameworks von Drittanbietern sind Lebensretter, um die Entwicklung zu beschleunigen, aber sie sind an Bedingungen geknüpft – sie wurden nicht in Ihrem Haus entwickelt. Behandeln Sie sie wie jeden Input für Ihren Build-Prozess: sorgfältig überprüft und unter Kontrolle.
Möchten Sie böse Überraschungen vermeiden? Abhängigkeiten anheften an Bestimmte Versionen oder Hashes um zu verhindern, dass sich ungetestete Updates in die Produktion einschleichen. Das regelmäßige Prüfen und Aktualisieren dieser Bibliotheken ist nicht glamourös, aber es ist der einzige Weg, um zu vermeiden, dass veralteter Code zu Ihrer Achillesferse wird.
4. Strenge Zugriffskontrolle durchsetzen
Die Zugriffssteuerung schränkt ein, wer Code und Ressourcen anzeigen oder ändern kann, um vertrauliche Funktionen und Daten vor nicht autorisierten Benutzern zu schützen. Halten Sie sich an die Prinzip der geringsten Privilegien: Geben Sie den Benutzern nur das, was sie für ihre Arbeit benötigen – nicht mehr und nicht weniger.
Um die Sicherheit zu erhöhen, sollten Sie die Implementierung von rollenbasierten Zugriffssteuerungen (Role-Based Access Controls, RBAC) und Multi-Faktor-Authentifizierung (MFA) in Betracht ziehen. Diese Maßnahmen reduzieren Ihre Angriffsfläche weiter und stellen sicher, dass Unbefugte keinen Zugriff auf kritische Systeme oder Daten haben.
5. Implementieren Sie eine ordnungsgemäße Fehlerbehandlung und -protokollierung
Niemand möchte Angreifern eine Roadmap in die Hand geben, aber genau das können zu detaillierte Fehlermeldungen bewirken. Halten Sie interne Details – z. B. Stack-Traces und Datenbankfehler – von den Benutzern fern. Protokollieren Sie sie stattdessen, sicher und durchdacht, nur für die Augen Ihres Teams.
Gute Protokolle erzählen die Geschichte: Was ist passiert, wann und warum. Überwachen Sie sie auf faule Dinge, aber übertreiben Sie es nicht, indem Sie sensible Daten protokollieren. Ausgewogenheit ist hier der Schlüssel – Sie beheben Fehler, nicht stellen Sie sicher, dass Sie Probleme beheben.
6. Automatisieren von Code-Reviews
Manuelle Überprüfungen sind wichtig, aber Automatisierung ist notwendig. Automatisierte Tools wie Statische Prüfung der Anwendungssicherheit (SAST) Und Linters kennzeichnen Schwachstellen und Codierungsfehler schneller, als es Menschen je könnten.
Binden Sie diese Tools in Ihre CI/CD-Pipeline ein, und jede Codeänderung wird einmal überprüft, bevor sie zusammengeführt wird. Sofortiges Feedback hält die Entwickler auf dem Laufenden und stellt sicher, dass Best Practices für die Sicherheit im Vordergrund stehen.
7. Anwenden von Techniken zur Codeverschleierung
Code-Verschleierung macht Ihre App nicht kugelsicher, aber sie verlangsamt Angreifer. Das Umbenennen von Variablen in Kauderwelsch, das Codieren von Zeichenfolgen und das Umstrukturieren von Code erschweren das Reverse Engineering oder den Diebstahl von geistigem Eigentum.
Betrachten Sie es als zusätzliche Tarnung: Die App läuft für die Benutzer immer noch reibungslos, aber böswillige Akteure werden es viel schwieriger haben, einzudringen oder einen Sinn aus dem zu machen, was sie sehen. Jede Hürde hilft.
Häufige Sicherheitslücken in Codesoftware
Werfen wir einen Blick auf häufige Sicherheitslücken, die Softwareentwickler und Sicherheitsforscher identifiziert haben. Wir gehen von Low-Level-Problemen wie Speicherschwachstellen zu übergeordneten Problemen wie Injection-Angriffen.
Pufferüberläufe
Pufferüberläufe können Ihre Anwendung zum Absturz bringen oder es Angreifern ermöglichen, Daten in andere Puffer zu schreiben.
Systemprogrammiersprachen wie C/C++ sind anfällig für diese Schwachstelle. Sie erlauben und verlangen sogar explizit die Speicherverwaltung, überprüfen den Speicherzugriff jedoch erst, wenn es zu spät ist. Wenn Sie mehr Daten in einen Puffer schreiben, als Sie ihnen zur Definitionszeit zugewiesen haben, überschreibt C alle Speicherdaten, die am Ende des Puffers folgen.
Beispiel für einen Pufferüberlauf in C:
int b[5];
b[5] = 999; Puffer geht nur von 0 bis 4Nach der kostenlosen Nutzung
Die Verwendung nach dem Freigeben erfolgt, wenn Sie Speicher auf dem Heap freigeben, aber weiterhin den alten Zeiger verwenden.
Auch diese Sicherheitsanfälligkeit tritt in Sprachen ohne Garbage Collection auf, z. B. C/C++, in denen Sie den Arbeitsspeicher manuell verwalten müssen. Es gibt zwei Arten von Speicher: den Stapel und den Heap. Die Sprache verwaltet automatisch den Stapel, der keine Daten mit dynamischen Größen aufnehmen kann, die zur Kompilierzeit nicht bekannt sind. Der Heap ist für dynamische Daten vorgesehen, aber Sie müssen manuell Speicherplatz zuweisen und freigeben. Freigeben bedeutet, dass Sie dem Betriebssystem mitteilen, dass Sie den Speicher nicht mehr benötigen, und wenn Sie ihn anschließend mit einem Zeiger verwenden, wird der illegale Zugriff auf einen nicht zugeordneten Speicherort verschoben.
Beispiel für die Verwendung nach free in C:
char* p = (char*)malloc (16);
p = strdup("Etwas Text!");
frei(p);
printf("%s", p); Gibt aus, was sich jetzt im freigegebenen Speicher befindetDoppelzimmer gratis
Im Fall von double free geben Sie Heapspeicher frei, nachdem Sie ihn bereits freigegeben haben.
Double Free ist ein Problem in Sprachen mit manueller Speicherverwaltung, bei denen Sie dem Betriebssystem explizit mitteilen müssen, dass Sie einen bestimmten Speicherbereich nicht mehr benötigen. Wenn Sie dies zweimal tun, führt dies zu einem Absturz, ähnlich wie bei der Verwendung nach der kostenlosen Ausgabe. Dies geschieht normalerweise, wenn Sie mehrere Objekte mit Zeigern aufeinander haben, die zu einem bestimmten Zeitpunkt freigegeben werden. Double free kann den Speicher beschädigen, auf den ein Zeiger vor dem ersten freien Zeiger verweist.
Beispiel für double free in C:
char* p = (char*)malloc (16);
p = strdup("Etwas Text!");
frei(p);
frei(p); wird den Inhalt des freigegebenen Speichers beschädigenUnsichere Deserialisierung
Bei der unsicheren Deserialisierung wird eine externe Datenstruktur (z. B. JSON, XML usw.) ohne ausreichende Prüfungen direkt in eine interne (z. B. Objekte, Arrays usw.) umgewandelt.
Eine unsichere Deserialisierung ist eine häufige Schwachstelle in allen Arten von Anwendungen. Es mag gut sein, nicht bereinigte Daten während der Entwicklung zu akzeptieren, aber Benutzer können bösartige Daten ohne Vorankündigung einschleusen, wenn dies in der Produktion geschieht.
Beispiel für eine unsichere Deserialisierung in JSON:
{
"Name": "Beispiel",
"E-Mail": "email@example.com",
"isAdmin": true // sollte auf dem Server gelöscht werden
}Speicherlecks
Durch Speicherverluste kann Ihre Anwendung unbegrenzt Arbeitsspeicher verbrauchen. Wenn Sie den verfügbaren Arbeitsspeicher ausschöpfen und mehr anfordern, stürzt Ihre Anwendung ab.
Jede hinreichend komplexe Anwendung ist anfällig für diese Schwachstelle. Selbst Garbage-Collection-Sprachen sind nicht vor Speicherlecks sicher. Mit Garbage-Collection-Sprachen können Sie weiterhin Datenstrukturen erstellen, die ein Garbage Collector nicht verwalten kann.
Fehler bei der Einspritzung
Das Ausführen von Benutzereingaben als Code, ohne sie zu validieren, wird als Injektionsfehler bezeichnet.
Dieses Problem kann alle Anwendungen betreffen, unabhängig von der verwendeten Programmiersprache. Eine Möglichkeit, Ihre Anwendung anfällig für Injection-Fehler zu machen, besteht darin, Benutzern zu erlauben, benutzerdefinierten Code als Feature hinzuzufügen und die Ausführung nicht ordnungsgemäß in einer Sandbox durchzuführen. Pufferüberläufe, die es Angreifern ermöglichen, Code in ausführbare Speicherbereiche zu schreiben, sind eine weitere Möglichkeit, wie Ihre Anwendung anfällig für Injection-Fehler werden kann.
Cross-Site-Scripting (XSS)
Cross-Site-Scripting ist eine webspezifische Version einer Injection-Schwachstelle. Hier fügt ein Angreifer benutzerdefiniertes JavaScript ein, das im HTML-Markup versteckt ist.
XSS kann auf allen Websites auftreten. Da Markup und ausführbarer Code im Web eng integriert sind, ist es einfach, JavaScript in HTML einzuschleusen, wodurch sensible Daten preisgegeben werden.
Beispiel für XSS in HTML und JavaScript:
<-- dies wird eine Abrufanforderung gesendet
Wenn sich die Maus über dem Symbol <p> Element-->
<p onmouseover="fetch('//example.com')">Hallo Welt!</p>Externe XML-Entitäten (XXE)
Externe XML-Entitäten sind ein weiteres Beispiel für einen Injection-Fehler. Alle Anwendungen, die XML verwenden, sind anfällig für diesen Angriff. Die Idee hinter externen Entitäten in XML besteht darin, die Wiederverwendung vorhandener XML-Dateien zu ermöglichen. Ein Angreifer kann diese Funktion jedoch verwenden, um Links zu privaten XML-Dateien einzufügen, sodass er private Daten indirekt über seine hochgeladene XML-Datei lesen kann.
Beispiel für eine externe XML-Entitätsinjektion:
<?xml version="1.0" Kodierung="ISO-8859-1"?>
<! DOCTYPE a [
<! ELEMENT a ANY >
<-- dies definiert eine neue Entität mit dem Namen xxe
aus einer privaten Datei -->
<! ENTITÄT xxe-SYSTEM "file:///etc/passwd" >
]>
<-- hier wird die Entität gerendert, um anzuzeigen
Der Dateiinhalt -->
<a>&xxe;</a>Unsichere direkte Objektreferenz (IDOR)
Wenn Sie zulassen, dass öffentliche APIs direkt auf Objekte mit sequenziellen IDs verweisen, können IDORs es Angreifern ermöglichen, die ID aller Objekte auf dem Server zu erraten.
Dieses Problem kann überall dort auftreten, wo sequenzielle IDs verwendet werden, um auf Objekte zu verweisen, und ist besonders schwerwiegend, wenn die IDs verwendet werden, um auf öffentliche und private Objekte zu verweisen, ohne dass eine Autorisierung erforderlich ist.
Beispiel-URLs:
https://example.com/users/4539
https://example.com/users/4540
https://example.com/users/4541
Directory Traversal (auch bekannt als Path Traversal)
Eine weitere Injection-Schwachstelle besteht darin, dass Angreifer Pfade oder Verzeichnisstrukturen über Dateinameneingaben durchlaufen können.
Alle Anwendungen, die die Eingabe von Dateinamen zulassen, können Opfer dieser Sicherheitsanfälligkeit werden. Das Durchlaufen von Verzeichnissen kann auftreten, wenn Benutzer mehrere Dateien hochladen, die über relative Pfade aufeinander verweisen. Angreifer können Dateidurchlaufpfade wie ".." , um von ihrem Upload-Verzeichnis auf dem Server in Verzeichnisse mit Dateien von Administratoren oder anderen Benutzern zu navigieren.
Beispiel für das Durchlaufen von Verzeichnissen in JavaScript auf Node.js:
Dadurch wird eine private Javascript-Datei geladen
const template = require(".. /.. /.. /server/config/database")
render(Vorlage)Sicherheitsstandards für Code
Sichere Codierungsstandards sind eine Reihe von Richtlinien und Best Practices, die Entwickler befolgen, um sichere Software zu erstellen und Schwachstellen zu minimieren. Sie beheben häufige Programmierfehler und Schwachstellen, die von Angreifern ausgenutzt werden können, um widerstandsfähigeren und widerstandsfähigeren Code zu erstellen.
Im Folgenden finden Sie die gängigen Standards für sicheren Code, die Sie befolgen sollten:
1. Sichere Codierungspraktiken von OWASP:
OWASP Secure Coding Practices (SCP) sind Richtlinien des Open Web Application Security Project, die sich auf Schlüsselbereiche zur Verbesserung der Softwaresicherheit konzentrieren, wie z. B. Eingabevalidierung, Authentifizierung, Sitzungsverwaltung, Verschlüsselung und Fehlerbehandlung. Es ist eine Roadmap für sichereren Code, von Ihrem Erstes Commit für die endgültige Bereitstellung.
2. CERT-Standards für sichere Codierung:
CERT Secure Coding Standards (SCS) sind eine Reihe von Richtlinien und Empfehlungen, die vom Software Engineering Institute (SEI) der Carnegie Mellon University entwickelt wurden, um Entwicklern zu helfen, sicheren Code zu schreiben und Schwachstellen zu verhindern. Schwerpunkte:
Sprachspezifische Richtlinien:Empfehlungen für C, C++, Java, Android und Perl, um häufige Sicherheitslücken in diesen Sprachen zu beheben.
Defensive Programmierung:Betonung der Antizipation und des ordnungsgemäßen Umgangs mit Fehlern, um Ausnutzung zu verhindern.
Speicherverwaltung:Konzentrieren Sie sich auf die Vermeidung von Pufferüberläufen und Speicherverlusten, insbesondere in Sprachen wie C und C++.
3. NIST-Richtlinien für sichere Codierung:
Die NIST Secure Coding Guidelines (auch bekannt als NIST Special Publication 800-218) konzentrieren sich auf kritische Bereiche wie Eingabevalidierung, Authentifizierung, Verschlüsselung und Fehlerbehandlung und bieten klare Ratschläge, um Injektionsangriffe, Session-Hijacking und Speicherprobleme von Ihrer Software fernzuhalten. Wenn Sie ein staatlich unterstütztes Gütesiegel auf Ihrem Sicherheitspraktiken für Code, ist dies Ihre Anlaufstelle.
ISO/IEC 27001 ist ein internationaler Informationssicherheitsstandard. Während es'Da es sich nicht speziell um einen sicheren Codierungsstandard handelt, enthält er Anforderungen für sichere Codierungspraktiken als Teil eines umfassenden Sicherheitsmanagementansatzes. Anhang A, Control 8.28: Secure Coding Practices, konzentriert sich speziell auf die sichere Codierung und betont, dass Organisationen:
Entwickeln Sie sichere Codierungsprozesse für die interne Entwicklung und den Code von Drittanbietern.
Bleiben Sie über sich entwickelnde Bedrohungen und Schwachstellen auf dem Laufenden.
Implementieren Sie robuste, sichere Codierungsprinzipien, um diese Probleme zu beheben.
Sorgen Sie für einen sicheren Lebenszyklus der Softwareentwicklung mit Wiz
Sichere Codierung ist eine Praxis, die alle Aspekte der Softwareentwicklung berührt – von der Auswahl der Datenformate und Programmiersprachen über die Planung von Inputs und Outputs bis hin zur Implementierung.
Wir'Ich freue mich, vorstellen zu können Wiz-Code, unsere neueste Innovation, die Entwickler und Sicherheitsteams in die Lage versetzt, robuste sichere Codierungspraktiken während des gesamten Lebenszyklus der Softwareentwicklung zu implementieren und aufrechtzuerhalten!
Wiz Code erweitert unsere Cloud-Sicherheitsplattform um jede Entwicklungsphase und bietet leistungsstarke Funktionen zur Unterstützung Ihrer Initiativen zur sicheren Programmierung:
Integriertes Code-Scanning: Erkennen Sie Schwachstellen, Fehlkonfigurationen und Compliance-Probleme direkt in Ihren IDE- und Code-Repositories und erkennen Sie potenzielle Probleme, bevor sie in die Produktion gelangen.
Sicherheitsfeedback in Echtzeit: Erhalten Sie sofortige Sicherheitseinblicke während der Programmierung, sodass Entwickler Probleme sofort beheben und sichere Codierungspraktiken unterwegs erlernen können.
Cloud-to-Code-Rückverfolgbarkeit: Verfolgen Sie Risiken, die in Produktionsumgebungen entdeckt wurden, bis zum spezifischen Code und den Teams, die sie eingeführt haben, zurück, um eine schnelle Ursachenanalyse und -behebung zu ermöglichen.
Leitfaden zur In-Code-Wartung: Erhalten Sie umsetzbare, kontextbezogene Empfehlungen zur Behebung von Sicherheitsproblemen direkt in Ihrer Entwicklungsumgebung.
Umfassende Sprachunterstützung: Profitieren Sie von Best Practices für die sichere Codierung in einer Vielzahl von Programmiersprachen und Frameworks.
Secure your SDLC from start to finish
See why Wiz is one of the few cloud security platforms that security and devops teams both love to use.
