Sicheres Programmieren in der Praxis

Unzureichende Protokollierung und Überwachung

Protokollierung und Überwachung sind oft ein nachträglicher Gedanke, wenn bereits etwas schief gelaufen ist, aber in Wirklichkeit kann es sehr kostspielig sein, wenn nicht sichergestellt wird, dass eine ordnungsgemäße Protokollierung und Überwachung erfolgt. Im Extremfall ist es unmöglich, herauszufinden, was tatsächlich passiert ist, wenn ein Vorfall auftritt (ob sicherheitsrelevant oder nicht), wenn nur wenige oder gar keine Protokolle vorliegen. Auf der anderen Seite kann die Protokollierung zu vieler Daten zu Datenschutzproblemen führen, die dann zu Problemen mit den Aufsichtsbehörden führen können. Lesen Sie unseren Leitfaden für bewährte Verfahren zur Vermeidung einer unzureichenden Protokollierung und Überwachung.

알려진 보안 취약점이 있는 구성 요소 사용

Die meisten Anwendungen verwenden große Mengen an Komponenten von Drittanbietern. Diese Komponenten bieten alles, von Logging über Templating bis hin zum Datenbankzugriff und mehr. Dies erleichtert die Softwareentwicklung erheblich und spart viel Zeit. Sie werden aber auch von Menschen gemacht, was bedeutet, dass einige unweigerlich Sicherheitslücken enthalten. Lesen Sie die Richtlinie, um mehr zu erfahren.

SQL 주입

SQL Injection (SQLi) injiziert Code in SQL-Anweisungen, um eine Anwendung aufzurufen und wichtige Informationen von ihnen zu sammeln. Es handelt sich um eine Sicherheitslücke im Internet. Es ist die gebräuchlichste Hacking-Technik, bei der die Datenbank manipuliert und wichtige Informationen daraus extrahiert werden.

보안 설정 오류

Sicherheitsfehlkonfiguration ist so etwas wie ein Überbegriff, der häufig auftretende Sicherheitslücken abdeckt, die eher auf die Konfigurationseinstellungen einer Anwendung als auf schlechten Code zurückzuführen sind. Es handelt sich um ein weitreichendes Thema, das stark von Faktoren wie Ihrem Technologie-Stack abhängt. Oft scheint die Behebung dieser Probleme einfach zu sein, wie das Ändern einer Konfigurationsdatei oder sogar einer einzelnen Codezeile, aber die Auswirkungen und Folgen dieser Sicherheitslücken können schwerwiegend sein. Lesen Sie unsere Richtlinie, um mehr über diese Sicherheitsanfälligkeit zu erfahren und zu erfahren, wie Sie sie beheben können.

서버 측 요청 위조

Sicherheitslücken durch serverseitige Anforderungsfälschung treten auf, wenn ein Benutzer eine Anwendung veranlassen kann, HTTP-Anfragen an eine vom Angreifer bestimmte Domain zu stellen. Wenn eine Anwendung Zugriff auf private/interne Netzwerke hat, kann ein Angreifer die Anwendung auch veranlassen, Anfragen an interne Server zu stellen. Wir werden uns das anhand einiger Beispiele genauer ansehen, um besser zu verstehen, wie es in dieser Richtlinie in Aktion aussieht.

Speicherung von Passwörtern

Wenn Ihre Anwendung Benutzer authentifiziert, wird sie wahrscheinlich auch mit Passwörtern umgehen. Der Umgang mit Benutzerkennwörtern ist eine wirklich große Sache, und der angemessene Umgang mit ihnen ist noch wichtiger. Es ist schwer, sich ein schlimmeres Szenario vorzustellen, als wenn eine Anwendung angegriffen wird und Benutzerkennwörter für alle sichtbar im Internet durchgesickert sind. Wie können Passwörter sicher und gemäß den besten Praktiken gespeichert werden? Schauen wir uns ein paar Möglichkeiten an.

Massenzuweisung

Massenzuweisungen sind eine Sicherheitslücke, bei der API-Endpunkte nicht einschränken, welche Eigenschaften des zugehörigen Objekts von einem Benutzer geändert werden können. Diese Sicherheitsanfälligkeit kann auftreten, wenn eine Bibliothek/ein Framework verwendet wird, das die automatische Bindung von HTTP-Parametern an ein Modell ermöglicht, das dann ohne Überprüfung verwendet wird. Die Verwendung der automatischen Bindung von einer Anfrage an ein Objekt kann manchmal äußerst hilfreich sein, kann aber auch zu Sicherheitsproblemen führen, wenn das Modell Eigenschaften hat, auf die der Benutzer nicht zugreifen kann. Lesen Sie die Richtlinie für weitere Informationen.

Fehlkonfiguration der Sicherheitseinstellungen — XXE detailliert

Bei der Schwachstellenklasse „XML eXternal Entities“ (XXE) handelt es sich um eine Sicherheitsfehlkonfiguration, an der XML-Parser beteiligt sind. Der XML-Standard beinhaltet Möglichkeiten, auf „Entitäten“ wie Dateien und URLs zu verweisen. Es ist oft die Standardeinstellung, dass Parser externe Entitäten vollständig auflösen, was bedeutet, dass XML-Dokumente zur Offenlegung von Dateien und anderen vertraulichen Informationen für potenzielle Angreifer führen können. Lesen Sie die vollständige Richtlinie für weitere Informationen.

Injektion — Pfaddurchquerung

Path Traversal ist eine weitere ziemlich häufige Art von Injektionsanfälligkeit. Sie treten in der Regel auf, wenn durch die Erstellung einer URI (sei es für eine URL, einen Dateipfad oder etwas anderes) nicht ordnungsgemäß sichergestellt wird, dass der vollständig aufgelöste Pfad nicht außerhalb des Stammverzeichnisses des vorgesehenen Pfads zeigt. Die Auswirkungen einer Sicherheitslücke durch Pfaddurchquerung hängen stark vom Kontext ab, in dem die Traversierung stattfindet, und von der Art der Absicherung, die insgesamt vorgenommen wurde. Lesen Sie die Richtlinie, um mehr zu erfahren.

Authentifizierung und Autorisierung

Injektion - XSS

Cross-Site Scripting, auch bekannt als XSS, ist eine weitere Art von Injection-Schwachstelle, die zur Auswertung eines vom Angreifer gesteuerten Skripts im Browser eines anderen Benutzers führt. XSS kann auch als HTML/JavaScript-Injection-Schwachstelle betrachtet werden. Schauen wir uns an, auf welche XSS-Typen Sie stoßen können.

Injektion 101

Eine der bekanntesten Klassen von Sicherheitslücken sind in der Regel Injection-Schwachstellen, insbesondere, und das überrascht niemanden, das unbestrittene Aushängeschild: SQL Injection. Es ist schwer zu vermeiden, in der Technologiewelt von SQL-Injection zu hören, also werden wir einfach darüber sprechen. Lesen Sie weiter, um eine kurze Einführung in Injektionsfehler zu erhalten.

Datei hochladen

Es kommt sehr häufig vor, dass Anwendungen irgendwann Benutzern erlauben müssen, eine Datei (entweder zur Verwendung oder nur zur Speicherung) irgendwo in der Anwendung hochzuladen. Es scheint zwar einfach zu sein, aber die Art und Weise, wie diese Funktion implementiert wird, kann aufgrund der potenziellen Risiken, die mit der Handhabung von Datei-Uploads verbunden sind, ziemlich wichtig sein. Lesen Sie die Richtlinie für weitere Informationen.

Befehlsinjektion

Schauen wir uns Command Injection selbst an. Wir werden uns hauptsächlich auf einige verschiedene Beispiele konzentrieren, damit es einfacher ist, zu sehen, wie es in Aktion aussieht. Zur kleinen Auffrischung: Command Injection-Schwachstellen treten auf, wenn Benutzereingaben einen Teil eines Betriebssystembefehls verwenden. Lesen Sie die Richtlinie für weitere Informationen.