Öffentliche Aufgaben und Leitlinien

Sichere Kodierung in der Praxis

Entdecken Sie Richtlinien für sicheres Codieren, um Schwachstellen in Software zu verstehen und zu minimieren, wie beispielsweise die Top 10 der OWASP, und tauchen Sie ein in geführte Schulungsmissionen, um in realistischen Anwendungssimulationen zu üben.

Eine Vorführung buchen
BG lernen
Öffentliche Aufträge
Richtlinien

Entdecke alle Missionen

Inhaltsverzeichnis
SQL-InjektionSpring MVC-AnforderungsabgleicherTrojanische Quelle: Verwendung von Komponenten aus nicht vertrauenswürdigen QuellenPsychische Signaturen: Verwendung bekannter verwundbarer KomponentenApache Path Traversal: Verwendung bekannter anfälliger KomponentenCodestashbin – Unsichere Funktion zum Zurücksetzen des PasswortsLog4j: Verwendung bekannter anfälliger KomponentenCross-Site-Scripting (XSS) in „ChatterGPT”
Mehr sehen
Steigern Sie die Produktivität
SQL-Injektion
Wir erhielten Berichte von einem Benutzer, der angab, eine SQL-Injection-Sicherheitslücke in der Transaktionssuchfunktion der Internet-Banking-Lösung ausnutzen zu können. Er gab an, dass er die Transaktionen anderer Benutzer einsehen konnte, und wies darauf hin, dass diese Schwachstelle es einem Angreifer ermöglichen könnte, alle Arten von schädlichen Aktionen in der Datenbank durchzuführen, wie z. B. Tabellen löschen, Daten aus anderen Tabellen einsehen, Daten einfügen usw. Versuchen Sie, die Handlungen des Benutzers in dieser Aufgabe nachzuvollziehen.
Probieren Sie es jetzt ausLesen Sie den Blogbeitrag
Steigern Sie die Produktivität
Spring MVC-Anforderungsabgleicher
Im März 2023 veröffentlichte Spring eine Lösung für eine intern entdeckte Sicherheitslücke mit der Bezeichnung CVE-2023-20860, bei der die Verwendung eines doppelten Platzhalters ** in MVCRequestMatchers zu einer Musterinkongruenz zwischen Spring Security und Spring MVC führen konnte. Letztendlich hätte dies dazu führen können, dass Benutzer unbefugten Zugriff auf bestimmte Endpunkte erhielten. Wir haben eine stark vereinfachte Bankanwendung mit wenigen Endpunkten erstellt. Befolgen Sie die Anweisungen und versuchen Sie, die Auswirkungen dieser Sicherheitslücke bei der Zugriffskontrolle zu reproduzieren.
Probieren Sie es jetzt ausLesen Sie den Blogbeitrag
Steigern Sie die Produktivität
Psychische Signaturen: Verwendung bekannter verwundbarer Komponenten
CVE-333321449 hat den coolsten Alias für eine Sicherheitslücke: Psychic Signatures in Java. Wie kam es zu diesem Namen? Es ist eine Anspielung auf die psychischen Dokumente aus Doctor Who. Wenn man sie jemandem zeigt, füllen sich diese leeren Zettel mit dem, was man zu sehen hofft. Ähnliches geschah bei der Implementierung des ECDSA-Algorithmus in Java (Versionen 15 bis 18), was sich auf die Überprüfung von JWT-Signaturen auswirkt. Wir können eine ungültige Signatur senden, aber Java wird sie für gültig halten. Möchten Sie sehen, wie das funktioniert? Dann legen wir los.
Probieren Sie es jetzt ausLesen Sie den Blogbeitrag
Steigern Sie die Produktivität
Apache Path Traversal: Verwendung bekannter anfälliger Komponenten
Am 4. Oktober 2021 veröffentlichte das Apache-Team die Version 2.4.49 von Apache, um eine Schwachstelle in Apache 2.4.48 zu beheben, die als CVE-2021-41773 bekannt ist und das Ausführen von Code aus der Ferne ermöglicht. Am 7. Oktober 2021 veröffentlichten sie die Version 2.4.51, da die Korrektur in Revision 2.4.50 nicht vollständig war. Diese Sicherheitslücke wurde als CVE-2021-42013 registriert. Testen Sie diese Mission, um selbst zu überprüfen, wie diese Sicherheitslücke ausgenutzt werden kann.
Probieren Sie es jetzt ausLesen Sie den Blogbeitrag
Steigern Sie die Produktivität
Log4j: Verwendung bekannter anfälliger Komponenten
Die Ankündigung eines Zero-Day-Exploits (CVE-2021-44228) in der beliebten Log4j-Bibliothek Anfang Dezember 2021 schlug in der Java-Community wie eine Bombe ein. Der Exploit mit dem Namen Log4Shell betrifft die Versionen 2.0-beta9 bis 2.14.1 von Log4j v2 und könnte zur Remote-Ausführung von Code führen. Wir haben eine Umgebung erstellt, um den Exploit zu simulieren, damit Sie die Auswirkungen aus erster Hand sehen können. Probieren Sie es jetzt aus.
Probieren Sie es jetzt ausLesen Sie den Blogbeitrag
Steigern Sie die Produktivität
Trojanische Quelle: Verwendung von Komponenten aus nicht vertrauenswürdigen Quellen
Einer unserer Entwickler bei Viking Bank hat in gutem Glauben einen Code aus einer nicht vertrauenswürdigen Quelle im Internet kopiert, der möglicherweise Sicherheitslücken enthält, um eine Verwaltungsberechtigung für die Verwaltung von Kreditkarten zu erstellen. Wir haben festgestellt, dass Benutzer das Limit ihrer Kreditkarten geändert haben, obwohl nur Administratoren diese Berechtigung haben sollten. Wir glauben, dass es ein Problem mit diesem Code gibt. Versuchen Sie, den Code zu untersuchen.
Probieren Sie es jetzt ausLesen Sie den Blogbeitrag
Steigern Sie die Produktivität
Codestashbin – Unsichere Funktion zum Zurücksetzen des Passworts
CodeStashBin ist eines der weltweit größten Hosting-Unternehmen für Versionskontrolle von Code. Es gibt Gerüchte, dass der Prozess zum Zurücksetzen des Passworts fehlerhaft ist und eine Sicherheitslücke in der Funktion zum Zurücksetzen des Passworts aufweist. Es ist möglich, das Passwort eines privilegierten Benutzers zu ändern und auf dessen Konto zuzugreifen. Nehmen Sie an dieser Mission teil, um das Problem zu untersuchen.
Probieren Sie es jetzt ausLesen Sie den Blogbeitrag
Steigern Sie die Produktivität
Cross-Site-Scripting (XSS) in „ChatterGPT”
Diese Mission zeigt die vertraute Benutzeroberfläche eines beliebten LLM und verwendet einen echten Codeausschnitt, der Ende November 2023 generiert wurde. Benutzer können diesen Ausschnitt interpretieren und mögliche Sicherheitsprobleme untersuchen, wenn er für den vorgesehenen Zweck verwendet würde.
Probieren Sie es jetzt ausLesen Sie den Blogbeitrag

Alle Richtlinien einsehen

Navigieren durch:
Filter ausblenden
Auswahl
Filter anzeigen
Auswahl
Filter löschen
Etikette
Super-Symbol [★]
Thema
Mehr sehen

Unzureichende Registrierung und Überwachung

Bewährte Verfahren:

Prüfprotokoll für sensible Funktionen
Fehlerprotokollierung
Speicherung von Protokollen an einem zentralen Ort
Aufbewahrung von Protokollen für einen festgelegten Zeitraum
Regelmäßige Prüfung der PII-Protokolle

Die Protokollierung und Überwachung sind oft eine nachträgliche Idee, wenn bereits etwas schiefgelaufen ist, aber in Wirklichkeit kann es sehr kostspielig sein, wenn keine angemessene Protokollierung und Überwachung gewährleistet ist. Einerseits ist es bei einem Vorfall (unabhängig davon, ob er sicherheitsrelevant ist oder nicht) aufgrund fehlender oder unzureichender Protokolle unmöglich, herauszufinden, was tatsächlich passiert ist. Andererseits kann die Protokollierung zu vieler Daten zu Datenschutzproblemen und damit zu Problemen mit den Aufsichtsbehörden führen. Lesen Sie unseren Leitfaden zu bewährten Verfahren, um unzureichende Protokollierung und Überwachung zu vermeiden.

Siehe Richtlinien

Verwendung von Komponenten mit bekannten Schwachstellen

{
«dependencias»: {
«foo»: «1.0.0 - 2.9999.9999",
«barra»: «>=1.0.2 <2.1.2»
}
}

Die meisten Anwendungen verwenden eine Vielzahl von Komponenten von Drittanbietern. Diese Komponenten bieten alle möglichen Funktionen, von der Registrierung über die Erstellung von Vorlagen bis hin zum Zugriff auf Datenbanken und vieles mehr. Dies erleichtert die Softwareentwicklung erheblich und spart viel Zeit. Aber auch sie werden von Menschen entwickelt, was bedeutet, dass einige davon zwangsläufig Schwachstellen enthalten. Weitere Informationen finden Sie im Leitfaden.

Siehe Richtlinien

SQL-Injektion

importar mysql.connector
db = mysql.connector.connect
Práctica #Bad. ¡Evita esto! Esto es solo para aprender.
(host="localhost», user="newuser», passwd="pass», db="sample»)
cur = db.cursor ()
name = raw_input ('Ingresar nombre: ')
cur.execute («SELECT * FROM sample_data WHERE Name = '%s';»% name) para la fila de cur.fetchall (): print (row)
db.cerrar ()

SQL-Injection (SQLi) injiziert Code in SQL-Anweisungen, um eine Anwendung anzugreifen und wichtige Informationen zu sammeln. Es handelt sich um eine Sicherheitslücke im Web. Es ist die häufigste Hacking-Technik, mit der Datenbanken manipuliert und wichtige Informationen daraus extrahiert werden.

Siehe Richtlinien

Falsche Sicherheitseinstellungen

Viele Frameworks verfügen auch über eine Reihe von Endpunkten, die zur Überwachung der Anwendung aktiviert werden können, sei es in einer Produktions- oder einer Test-/Entwicklungsumgebung. Dazu können gehören:

Metriken (Prometheus)
Protokolle
Informationen zur Umgebung
Pfad-/URL-Zuordnungen

Eine fehlerhafte Sicherheitskonfiguration ist ein allgemeiner Begriff, der häufige Schwachstellen umfasst, die aufgrund der Konfigurationseinstellungen einer Anwendung und nicht aufgrund von fehlerhaftem Code auftreten. Es handelt sich um ein sehr umfangreiches Thema, das in hohem Maße von Faktoren wie der verfügbaren Technologie abhängt. Oftmals scheint die Behebung dieser Probleme einfach zu sein, beispielsweise durch Ändern einer Konfigurationsdatei oder sogar einer einzigen Codezeile, aber die Auswirkungen und Folgen dieser Sicherheitslücken können schwerwiegend sein. Lesen Sie unseren Leitfaden, um mehr über diese Sicherheitslücke und deren Behebung zu erfahren.

Siehe Richtlinien

Fälschung von Anfragen auf Serverseite

ts
let url = request.params.url;

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

devuelve render.export ();

Schwachstellen bei der Fälschung von Anfragen auf Serverseite treten auf, wenn ein Benutzer eine Anwendung dazu bringen 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 auch dazu bringen, Anfragen an interne Server zu senden. In diesem Leitfaden werden wir dies anhand einiger Beispiele genauer betrachten, um besser zu verstehen, wie dies in der Praxis aussieht.

Siehe Richtlinien

Speicherung von Passwörtern

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

Wenn Ihre Anwendung für die Benutzer authentisch ist, kümmert sie sich höchstwahrscheinlich auch um die Passwörter. Die Verwaltung der Passwörter der Benutzer ist eine sehr wichtige Angelegenheit, und ihre ordnungsgemäße Verwaltung ist noch wichtiger. Es ist schwer, sich ein schlimmeres Szenario vorzustellen als einen Angriff auf eine Anwendung und die Veröffentlichung der Passwörter der Benutzer im Internet, sodass sie für alle sichtbar sind. Wie können Passwörter sicher und gemäß den Best Practices gespeichert werden? Schauen wir uns einige Möglichkeiten an.

Siehe Richtlinien

Massenzuweisung

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

Die Masszuweisung ist eine Schwachstelle, bei der die Endpunkte der API nicht einschränken, welche Eigenschaften ihres zugehörigen Objekts ein Benutzer ändern kann. Diese Schwachstelle kann auftreten, wenn eine Bibliothek oder ein Framework verwendet wird, das die automatische Verknüpfung von HTTP-Parametern mit einem Modell ermöglicht, das anschließend ohne jegliche Validierung verwendet wird. Manchmal kann die automatische Verknüpfung einer Anfrage mit einem Objekt äußerst nützlich sein, aber auch zu Sicherheitsproblemen führen, wenn das Modell Eigenschaften enthält, auf die der Benutzer nicht zugreifen soll. Weitere Informationen finden Sie im Leitfaden.

Siehe Richtlinien

Sicherheitskonfigurationsfehler: XXE detailliert

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

Die Schwachstelle „XML External Entities“ (XXE) ist ein Sicherheitsfehler, der XML-Parser betrifft. Der XML-Standard enthält Möglichkeiten, auf „Entitäten“ wie Dateien und URLs zu verweisen. Parser lösen externe Entitäten standardmäßig vollständig auf, was bedeutet, dass XML-Dokumente zur Offenlegung von Dateien und anderen vertraulichen Informationen gegenüber potenziellen Angreifern führen können. Weitere Informationen finden Sie im vollständigen Leitfaden.

Siehe Richtlinien

Injektion: Bewegungsbahn

falso
let BaseFolder = «/var/www/api/documents/»;
let path = baseFolder + request.params.filename;

devuelve el archivo.read (ruta);

Path Traversal ist eine weitere recht häufige Art von Injektionsschwachstelle. Sie tritt in der Regel auf, wenn die Konstruktion einer URI (sei es für eine URL, einen Dateipfad oder einen anderen Typ) nicht ausreichend sicherstellt, dass der vollständig aufgelöste Pfad nicht außerhalb des gewünschten Stammpfads liegt. Die Auswirkungen einer Path Traversal-Sicherheitslücke hängen stark vom Kontext ab, in dem die Überquerung stattfindet, sowie vom Grad der allgemeinen Absicherung, die darauf angewendet wurde. Weitere Informationen finden Sie im Leitfaden.

Siehe Richtlinien

Authentifizierung und Autorisierung

cs

//Asegúrese de que el comportamiento predeterminado es autenticar las solicitudes y comprobar si son de administrador
[Autenticar]
[Autorizar («Administrador»)]
clase pública SecureController: Controller
{

}

clase pública MyController: SecureController
{

//Anula el atributo Authorize heredado para permitir que cualquier usuario acceda a la página

Siehe Richtlinien

Injektion – XSS

```html
<!--- UNSAFE: The htmlSnippet will get interpreted without any escaping --->
@Html .Raw (fragmento HTML)
```

Cross-Site Scripting, auch bekannt als XSS, ist eine weitere Art von Injektionsschwachstelle, die dazu führt, dass ein von einem Angreifer kontrolliertes Skript im Browser eines anderen Benutzers ausgeführt wird. XSS kann auch als HTML/JavaScript-Injektionsschwachstelle betrachtet werden. Sehen wir uns die Arten von XSS an, denen Sie begegnen können.

Siehe Richtlinien

Injektion 101

Einige der häufigsten Arten von Injektionen sind:

SQL-Injektion
Cross-Site-Skripting (HTML/Javascript-Injektion)
Cross-Path (Pfad-/URL-Injektion)
Befehlsinjektion
Code-Injektion

Eine der bekanntesten Arten von Sicherheitslücken sind Injektionsschwachstellen, insbesondere – was niemanden überrascht – die unbestrittene Vorreiterin: die SQL-Injektion. Es ist schwer, in der Welt der Technologie nichts von SQL-Injektionen zu hören, daher werden wir nun darüber sprechen. Lesen Sie weiter, um eine kurze Einführung in Injektionsschwachstellen zu erhalten.

Siehe Richtlinien

Dateien hochladen

cadena pública Cargar imagen de perfil (archivo de formulario archivo subido)
{
//Generar la ruta para guardar el archivo subido en
var path = $». /uploads/avatars/ {request.user.id}/{UploadedFile.filename}»;

//Guarda el archivo
var localFile = archivo.openWrite (ruta);
LocalFile.write (UploadedFile.readToEnd ());
archivo local.flush ();
local.close file ();

//Actualiza la imagen de perfil
UserProfile.UpdateImagen de perfil de usuario (request.user, ruta)

ruta de regreso;
}

Es kommt häufig vor, dass Anwendungen zu irgendeinem Zeitpunkt den Benutzern ermöglichen müssen, eine Datei (entweder zur Verwendung oder nur zur Speicherung) an einer bestimmten Stelle in der Anwendung hochzuladen. Auch wenn dies recht einfach erscheint, kann die Art und Weise, wie diese Funktion implementiert wird, aufgrund der möglichen Risiken, die mit der Verwaltung von Datei-Uploads verbunden sind, von entscheidender Bedeutung sein. Weitere Informationen finden Sie im Leitfaden.

Siehe Richtlinien

Befehlseingabe

let ip = request.params.ipAddress;

sistema («ping" + ip);

Sehen wir uns Command Injection einmal genauer an. Wir werden uns hauptsächlich auf einige verschiedene Beispiele konzentrieren, damit Sie besser verstehen, wie es in der Praxis aussieht. Zur kurzen Wiederholung: Command-Injection-Schwachstellen treten auf, wenn die Benutzereingabe einen Teil eines Betriebssystembefehls verwendet. Weitere Informationen finden Sie im Leitfaden.

Siehe Richtlinien