Öffentliche Missionen & Richtlinien

Sicheres Programmieren in der Praxis

Entdecken Sie Richtlinien für sicheres Programmieren, um Schwachstellen wie die OWASP Top 10 zu verstehen und zu beheben, und tauchen Sie in geführte Trainingsmissionen ein, um diese in realistischen Anwendungssimulationen zu üben.

Demo buchen
Öffentliche Missionen
Richtlinien

Alle Missionen durchsuchen

Inhaltsverzeichnis

SQL-InjectionSpring MvcRequestMatchersTrojan Source – Verwendung von Komponenten aus nicht vertrauenswürdigen QuellenPsychic Signatures – Verwendung bekannter anfälliger KomponentenApache Path Traversal – Verwendung bekannter anfälliger KomponentenCodestashbin – Unsichere Funktion zum Zurücksetzen von PasswörternLog4j – Verwendung bekannter anfälliger KomponentenCross-Site Scripting (XSS) in „ChatterGPT“
Mehr anzeigen
Skalierbar und motivierend

SQL-Injection

Ein Nutzer hat uns gemeldet, dass er eine SQL-Injection-Schwachstelle in der Transaktionssuche unseres Online-Bankings ausnutzen konnte. Er gab an, Transaktionen anderer Nutzer einsehen zu können, und wies darauf hin, dass ein Angreifer über diese Lücke die Datenbank manipulieren könnte – etwa durch das Löschen von Tabellen, das Auslesen fremder Daten oder das Einfügen eigener Datensätze. Versuchen Sie in dieser Mission, das Vorgehen des Nutzers zu reproduzieren.

jetzt ausprobieren
Skalierbar und motivierend

Spring MvcRequestMatchers

Im März 2023 veröffentlichte Spring einen Fix für eine intern entdeckte Schwachstelle namens CVE-2023-20860. Dabei konnte die Verwendung eines doppelten Platzhalters ** in mvcRequestMatchers zu einer Diskrepanz bei der Mustererkennung zwischen Spring Security und Spring MVC führen. Dies konnte letztlich dazu führen, dass Benutzer unbefugten Zugriff auf bestimmte Endpunkte erhielten. Wir haben eine stark vereinfachte Banking-Anwendung mit einigen Endpunkten eingerichtet. Befolgen Sie die Anweisungen und versuchen Sie, die Auswirkungen dieser Zugriffskontrollschwachstelle zu reproduzieren.

jetzt ausprobieren
Skalierbar und motivierend

Psychic Signatures – Verwendung bekannter anfälliger Komponenten

CVE-2022-21449 hat den coolsten Namen für eine Schwachstelle: Psychic Signatures in Java. Woher kommt dieser Name? Er ist eine Anspielung auf die psychischen Papiere aus Doctor Who. Wenn man sie jemandem zeigt, erscheinen auf diesen leeren Blättern genau die Informationen, die die Person erwartet. Ähnliches geschah in der Java-Implementierung (Versionen 15 bis 18) des ECDSA-Algorithmus, was sich auf die Signaturprüfung von JWTs auswirkt. Wir können eine ungültige Signatur übermitteln, aber Java hält sie für gültig. Möchten Sie sehen, wie das funktioniert? Fangen wir an.

jetzt ausprobieren
Skalierbar und motivierend

Apache Path Traversal – Nutzung bekannter anfälliger Komponenten

Am 4. Oktober 2021 veröffentlichte das Apache-Team die Version 2.4.49, um eine Path-Traversal- und Remote-Code-Execution-Schwachstelle in Apache 2.4.48 zu beheben, die auch als CVE-2021-41773 bekannt ist. Am 7. Oktober 2021 folgte Version 2.4.51, da der Hotfix 2.4.50 unvollständig war. Diese Schwachstelle wurde als CVE-2021-42013 erfasst. Probieren Sie diese Mission aus, um selbst zu sehen, wie diese Schwachstelle ausgenutzt werden kann.

jetzt ausprobieren
Skalierbar und motivierend

Log4j – Verwendung bekannter anfälliger Komponenten

Die Ankündigung einer Zero-Day-Schwachstelle (CVE-2021-44228) in der weit verbreiteten Logging-Bibliothek Log4j Anfang Dezember 2021 schlug in der Java-Community wie eine Bombe ein. Der als Log4Shell bezeichnete Exploit betrifft die Log4j v2-Versionen 2.0-beta9 bis 2.14.1 und kann zur Remote Code Execution führen. Wir haben eine Umgebung eingerichtet, um den Exploit zu simulieren, damit Sie die Auswirkungen aus erster Hand erleben können. Probieren Sie es jetzt aus.

jetzt ausprobieren
Skalierbar und motivierend

Trojan Source – Verwendung von Komponenten aus nicht vertrauenswürdigen Quellen

Einer unserer Entwickler bei der Viking Bank hat leichtfertig Code aus einer unsicheren Quelle aus dem Internet kopiert, um eine Admin-Autorisierungsprüfung für die Kreditkartenverwaltung zu erstellen. Dabei wurden möglicherweise anfällige Komponenten eingebunden. Wir haben festgestellt, dass Benutzer ihre Kreditkartenlimits ändern können, obwohl dies nur Administratoren vorbehalten sein sollte. Wir vermuten, dass mit diesem Code etwas nicht stimmt. Versuchen Sie sich an der Mission, um den Code zu untersuchen.

jetzt ausprobieren
Skalierbar und motivierend

Codestashbin - Unsichere Funktion zum Zurücksetzen von Passwörtern

CodeStashBin ist einer der weltweit größten Anbieter für Code-Versionsverwaltung. Gerüchten zufolge weist der Prozess zum Zurücksetzen von Passwörtern eine Sicherheitslücke auf. Möglicherweise lässt sich das Passwort eines privilegierten Benutzers ändern, um Zugriff auf dessen Konto zu erhalten. Stürzen Sie sich in diese Mission und untersuchen Sie das Problem.

jetzt ausprobieren
Skalierbar und motivierend

Cross-Site Scripting (XSS) in „ChatterGPT“

Diese Mission zeigt die vertraute Benutzeroberfläche eines bekannten LLM und verwendet einen echten Code-Schnipsel, der Ende November 2023 generiert wurde. Nutzer können diesen Code analysieren und potenzielle Sicherheitslücken untersuchen, falls er für seinen vorgesehenen Zweck eingesetzt würde.

jetzt ausprobieren

Alle Richtlinien durchsuchen

Durchsuchen nach:
Filter ausblenden
Auswahl
Filter anzeigen
Auswahl
Filter zurücksetzen
Tag
Super-Icon [★]
Thema
Mehr anzeigen

Unzureichende Protokollierung und Überwachung

Bewährte Verfahren:

Audit-Protokollierung für sensible Funktionen
Fehlerprotokollierung
Zentrale Speicherung von Protokollen
Aufbewahrung von Protokollen für einen definierten Zeitraum
Regelmäßige Prüfung der Protokolle auf personenbezogene Daten

Protokollierung und Überwachung werden oft erst dann bedacht, wenn bereits etwas schiefgelaufen ist. Dabei kann das Fehlen einer ordnungsgemäßen Protokollierung und Überwachung sehr kostspielig sein. Im schlimmsten Fall ist es bei einem Vorfall – ob sicherheitsrelevant oder nicht – ohne oder mit nur wenigen Protokollen unmöglich nachzuvollziehen, was tatsächlich passiert ist. Andererseits kann eine zu umfangreiche Datenerfassung zu Datenschutzproblemen führen, die wiederum Ärger mit den Aufsichtsbehörden nach sich ziehen können. Lesen Sie unseren Leitfaden mit Best Practices, um unzureichende Protokollierung und Überwachung zu vermeiden.

Richtlinien ansehen

Verwendung von Komponenten mit bekannten Sicherheitslücken

{
 "dependencies": {
   "foo": "1.0.0 - 2.9999.9999",
   "bar": ">=1.0.2 <2.1.2"
 }
}

Die meisten Anwendungen nutzen eine Vielzahl von Drittanbieter-Komponenten. Diese Komponenten bieten Funktionen für alles – von Logging und Templating bis hin zu Datenbankzugriffen und mehr. Das erleichtert die Softwareentwicklung erheblich und spart viel Zeit. Da sie jedoch von Menschen entwickelt werden, enthalten einige zwangsläufig Schwachstellen. Lesen Sie den Leitfaden, um mehr zu erfahren.

Richtlinien ansehen

SQL-Injection

import mysql.connector
db = mysql.connector.connect
#Schlechte Praxis. Vermeiden Sie dies! Nur zu Lernzwecken.
(host="localhost", user="newuser", passwd="pass", db="sample")
cur = db.cursor()
name = raw_input('Enter Name: ')
cur.execute("SELECT * FROM sample_data WHERE Name = '%s';" % name) for row in cur.fetchall(): print(row)
db.close()

Bei einer SQL-Injection (SQLi) wird Code in SQL-Anweisungen eingeschleust, um eine Anwendung anzugreifen und wichtige Informationen zu entwenden. Es handelt sich dabei um eine Sicherheitslücke in Webanwendungen. Dies ist die gängigste Hacking-Methode, um Datenbanken zu manipulieren und sensible Daten daraus zu extrahieren.

Richtlinien ansehen

Sicherheitsfehlkonfiguration

Viele Frameworks bieten zudem Endpunkte, die für das Monitoring der Anwendung aktiviert werden können – sei es in einer Produktions- oder einer Test-/Entwicklungsumgebung. Dazu gehören:

Metriken (Prometheus)
Logs
Umgebungsinformationen
Pfad-/URL-Mappings

Sicherheitsfehlkonfiguration ist ein Sammelbegriff für häufige Schwachstellen, die eher durch die Konfigurationseinstellungen einer Anwendung als durch fehlerhaften Code entstehen. 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, etwa durch das Ändern einer Konfigurationsdatei oder sogar nur einer einzigen Codezeile, doch die Auswirkungen und Konsequenzen dieser Schwachstellen können schwerwiegend sein. Lesen Sie unsere Richtlinien, um mehr über diese Schwachstelle und deren Behebung zu erfahren.

Richtlinien ansehen

Server-Side Request Forgery

ts
let url = request.params.url;

let response = http.get(url);
let render = response.render();

return render.export();

Server-Side Request Forgery-Schwachstellen treten auf, wenn ein Benutzer eine Anwendung dazu veranlassen kann, HTTP-Anfragen an eine vom Angreifer festgelegte Domain zu senden. Wenn eine Anwendung Zugriff auf private oder interne Netzwerke hat, könnte ein Angreifer die Anwendung zudem dazu bringen, Anfragen an interne Server zu stellen. In diesem Leitfaden betrachten wir dies anhand einiger Beispiele genauer, um ein besseres Verständnis für die praktische Umsetzung zu erhalten.

Richtlinien ansehen

Passwortspeicherung

Feature Cryptographic hash Password hash Speed Very fast Intentionally slow Work factor can be adjusted No Yes

Wenn Ihre Anwendung Benutzer authentifiziert, werden Sie wahrscheinlich auch mit Passwörtern zu tun haben. Der Umgang mit Benutzerpasswörtern ist eine äußerst sensible Angelegenheit, und eine korrekte Handhabung ist umso wichtiger. Es ist kaum ein schlimmeres Szenario vorstellbar, als dass eine Anwendung angegriffen wird und Benutzerpasswörter im Internet für jeden sichtbar werden. Wie lassen sich Passwörter sicher und nach bewährten Verfahren speichern? Werfen wir einen Blick auf einige Möglichkeiten.

Richtlinien ansehen

Massenzuweisung

html
<form method="POST">
<input name="Id" type="hidden" value="666">
<input name="Name" type="text" value="Bösewicht">
<input name="EmailAddress" type="text" value="hacker@attacker.com">
<input name="IsAdmin" type="hidden" value="true">
<input type="submit">
</form>

Mass Assignment ist eine Schwachstelle, bei der API-Endpunkte nicht einschränken, welche Eigenschaften ihrer zugehörigen Objekte von einem Benutzer geändert werden können. Diese Schwachstelle kann auftreten, wenn Bibliotheken oder Frameworks verwendet werden, die eine automatische Bindung von HTTP-Parametern an ein Modell ermöglichen, das anschließend ohne Validierung weiterverwendet wird. Die automatische Bindung von Anfragen an ein Objekt kann zwar sehr hilfreich sein, führt jedoch zu Sicherheitsrisiken, wenn das Modell Eigenschaften enthält, die für den Benutzer eigentlich nicht zugänglich sein sollten. Weitere Details finden Sie in unserem Leitfaden.

Richtlinien ansehen

Sicherheitsfehlkonfiguration – XXE im Detail

xml
<?xml version="1.0" ?>
<!DOCTYPE outerElement [
   <!ENTITY externalEntity SYSTEM  "file:///etc/passwd" > ]>
<outerElement>&externalEntity;</outerElement>

Die Schwachstellenklasse „XML eXternal Entities“ (XXE) ist eine Sicherheitsfehlkonfiguration, die XML-Parser betrifft. Der XML-Standard bietet Möglichkeiten, auf „Entitäten“ wie Dateien und URLs zu verweisen. Standardmäßig lösen Parser externe Entitäten oft vollständig auf, was dazu führen kann, dass XML-Dokumente Dateien und andere sensible Informationen für potenzielle Angreifer offenlegen. Lesen Sie den vollständigen Leitfaden für weitere Informationen.

Richtlinien ansehen

Injection – Path Traversal

pseudo
let baseFolder = "/var/www/api/documents/"; 
let path = baseFolder + request.params.filename;

return file.read(path);

Path Traversal ist eine weitere recht verbreitete Art von Injection-Schwachstelle. Sie tritt meist dann auf, wenn bei der Erstellung eines URI (sei es für eine URL, einen Dateipfad oder Ähnliches) nicht sichergestellt wird, dass der vollständig aufgelöste Pfad nicht außerhalb des beabsichtigten Stammverzeichnisses liegt. Die Auswirkungen einer Path-Traversal-Schwachstelle hängen stark vom Kontext ab, in dem die Manipulation erfolgt, sowie von der allgemeinen Absicherung des Systems. Lesen Sie die Richtlinie, um mehr zu erfahren.

Richtlinien ansehen

Authentifizierung und Autorisierung

cs

// Sicherstellen, dass Anfragen standardmäßig authentifiziert werden und Admin-Rechte geprüft werden
[Authenticate]
[Authorize("Admin")]
public class SecureController : Controller
{

}

public class MyController : SecureController
{

    // Überschreibt das geerbte Authorize-Attribut, um jedem Benutzer Zugriff auf die Seite zu gewähren

Richtlinien ansehen

Injektion - XSS

```html
<!--- UNSICHER: Das htmlSnippet wird ohne jegliche Maskierung interpretiert --->
@Html.Raw(htmlSnippet)
```

Cross-Site Scripting, kurz XSS, ist eine weitere Form der Injection-Schwachstelle, bei der ein vom Angreifer kontrolliertes Skript im Browser eines anderen Benutzers ausgeführt wird. XSS kann auch als HTML/JavaScript-Injection-Schwachstelle betrachtet werden. Werfen wir einen Blick auf die verschiedenen Arten von XSS, denen Sie begegnen können.

Richtlinien ansehen

Injektionen für Einsteiger

Zu den häufigsten Injection-Arten gehören:

SQL-Injection
Cross-Site Scripting (HTML/Javascript-Injection)
Path Traversal (Pfad-/URL-Injection)
Command-Injection
Code-Injection

Zu den bekanntesten Schwachstellenklassen gehören Injection-Schwachstellen, allen voran – wenig überraschend – das Paradebeispiel schlechthin: SQL-Injection. In der Tech-Welt kommt man kaum an dem Thema vorbei, also sprechen wir direkt darüber. Lesen Sie weiter für eine kurze Einführung in Injection-Fehler.

Richtlinien ansehen

Datei-Upload

public string UploadProfilePicture(FormFile uploadedFile)
{
    // Pfad zum Speichern der hochgeladenen Datei generieren
    var path = $"./uploads/avatars/{request.User.Id}/{uploadedFile.FileName}";

    // Datei speichern
    var localFile = File.OpenWrite(path);
    localFile.Write(uploadedFile.ReadToEnd());
    localFile.Flush();
    localFile.Close();

    // Profilbild aktualisieren 
    UserProfile.UpdateUserProfilePicture(request.User, path)

    return path;
}

Es ist sehr üblich, dass Anwendungen irgendwann die Möglichkeit bieten müssen, Dateien hochzuladen (sei es zur Verwendung oder zur reinen Speicherung). Auch wenn dies einfach erscheint, kann die Art und Weise der Implementierung aufgrund der potenziellen Risiken bei der Handhabung von Datei-Uploads kritisch sein. Lesen Sie den Leitfaden für weitere Informationen.

Richtlinien ansehen

Command Injection

let ip = request.params.ipAddress;

system("ping " + ip);

Schauen wir uns Command Injection einmal genauer an. Wir konzentrieren uns dabei auf verschiedene Beispiele, damit Sie besser verstehen, wie diese Schwachstellen in der Praxis aussehen. Zur kurzen Auffrischung: Command Injection tritt auf, wenn Benutzereingaben Teil eines Betriebssystembefehls werden. Weitere Informationen finden Sie in unseren Richtlinien.

Richtlinien ansehen