Öffentliche Aufgaben und Richtlinien

Sicheres Programmieren in der Praxis

Informieren Sie sich über Richtlinien für sicheres Programmieren, um Software-Sicherheitslücken wie die OWASP Top 10 zu verstehen und zu beheben, und nehmen Sie an geführten Trainingsmissionen teil, um praktische App-Simulationen zu üben.

Eine Demo buchen
BG lernen
Öffentliche Missionen
Richtlinien

Durchsuche alle Missionen

Inhaltsverzeichnis
SQL-InjektionSpring MVC Matchers anfragenTrojaner-Quelle — Verwendung von Komponenten aus nicht vertrauenswürdigen QuellenPsychische Signaturen — Verwendung bekannter anfälliger KomponentenApache Path Traversal — Verwendung bekannter anfälliger KomponentenCodestashbin – Unsichere Passwort-Zurücksetzen-FunktionLog4j – Verwendung bekannter anfälliger KomponentenSeitenübergreifendes Scripting (XSS) in „ChatterGPT”
Mehr ansehen
Steigern Sie die Produktivität
SQL-Einschleusung
Wir erhielten Berichte von einem Benutzer, dass er eine SQL-Injection-Schwachstelle in der Transaktionssuchfunktion der Internetbank-Lösung ausnutzen konnte. Er gab an, dass er in der Lage war, Transaktionen einzusehen, die anderen Benutzern gehören, und wies darauf hin, dass diese Schwachstelle es einem Angreifer ermöglichen könnte, alle möglichen unangenehmen Dinge mit der Datenbank anzustellen, z. B. Tabellen zu löschen, Daten aus anderen Tabellen einzusehen, Daten einzufügen usw. Versuchen Sie, das nachzuvollziehen, was der Benutzer in dieser Mission getan hat.
Probieren Sie es jetzt ausBlogbeitrag lesen
Steigern Sie die Produktivität
Spring MvcRequestMatchers
Im März 2023 veröffentlichte Spring einen Fix für eine intern entdeckte Schwachstelle mit der Bezeichnung CVE-2023-20860, bei der die Verwendung eines doppelten Platzhalters ** in mvcRequestMatchers zu einer Musterabweichung zwischen Spring Security und Spring MVC führen kann. Dies könnte letztendlich dazu führen, dass Benutzer unbefugten Zugriff auf bestimmte Endpunkte erhalten. Wir haben eine sehr vereinfachte Bankanwendung mit einigen wenigen Endpunkten eingerichtet. Folgen Sie den Anweisungen und versuchen Sie, die Auswirkungen dieser Schwachstelle in der Zugriffskontrolle zu reproduzieren.
Probieren Sie es jetzt ausBlogbeitrag lesen
Steigern Sie die Produktivität
Psychische Signaturen - Verwendung bekannter anfälliger Komponenten
CVE-2022-21449 hat den coolsten Alias für eine Sicherheitslücke, Psychic Signatures in Java. Wie kam sie zu diesem Namen? Es ist eine Anspielung auf die übersinnlichen Papiere von Doctor Who. Wenn diese leeren Zettel jemandem gezeigt wurden, füllte er sie mit dem aus, was er zu sehen erwartete. Etwas Ähnliches passierte 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 einreichen, aber Java wird sie für gültig halten. Wollen Sie sehen, wie das funktioniert? Dann fangen wir an.
Probieren Sie es jetzt ausBlogbeitrag lesen
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 durch Pfadumgehung und Remotecodeausführung verursacht wurde und auch als CVE-2021-41773 bekannt ist. Am 7. Oktober 2021 wurde Version 2.4.51 veröffentlicht, da der Hotfix für Version 2.4.50 nicht vollständig war. Diese Schwachstelle wurde als CVE-2021-42013 verfolgt. Probieren Sie diese Mission aus, um selbst zu sehen, wie diese Sicherheitslücke ausgenutzt werden kann.
Probieren Sie es jetzt ausBlogbeitrag lesen
Steigern Sie die Produktivität
Log4j - Verwendung bekannter verwundbarer Komponenten
Die Ankündigung einer 0-Day-Schwachstelle (CVE-2021-44228) in der sehr beliebten Protokollierungsbibliothek Log4j Anfang Dezember 2021 schlug in der Java-Community wie eine Bombe ein. Der Exploit mit dem Namen Log4Shell betrifft die Log4j v2-Versionen 2.0-beta9 bis 2.14.1 und könnte zur Remotecodeausführung führen. Wir haben eine Umgebung eingerichtet, in der der Exploit simuliert wird, so dass Sie die Auswirkungen aus erster Hand sehen können. Probieren Sie es jetzt aus.
Probieren Sie es jetzt ausBlogbeitrag lesen
Steigern Sie die Produktivität
Trojaner-Quelle - Verwendung von Komponenten aus nicht vertrauenswürdigen Quellen
Einer unserer Viking Bank-Entwickler hat naiverweise Code aus einer nicht vertrauenswürdigen Quelle im Internet kopiert, der potenziell angreifbare Komponenten enthält, um eine Administratorberechtigungsprüfung für die Verwaltung von Kreditkarten zu schreiben. Wir haben festgestellt, dass Benutzer ihr Kreditkartenlimit geändert haben, obwohl nur Administratoren diese Berechtigung haben sollten. Wir glauben, dass mit diesem Code etwas nicht stimmt. Probieren Sie die Mission aus, um den Code zu untersuchen.
Probieren Sie es jetzt ausBlogbeitrag lesen
Steigern Sie die Produktivität
Codestashbin - Unsichere Passwort-Rücksetzfunktion
CodeStashBin ist einer der weltweit größten Anbieter von Code-Versionskontrollen. Gerüchten zufolge ist der Prozess zum Vergessen des Passworts mit einer unsicheren Schwachstelle in der Funktion zum Zurücksetzen des Passworts behaftet. Es könnte möglich sein, das Passwort eines privilegierten Benutzers zu ändern und Zugang zu seinem Konto zu erhalten. Beginnen Sie mit dieser Mission, um das Problem zu untersuchen.
Probieren Sie es jetzt ausBlogbeitrag lesen
Steigern Sie die Produktivität
Cross-Site-Scripting (XSS) in 'ChatterGPT'
Diese Mission offenbart die vertraute Schnittstelle eines beliebten LLM und verwendet einen echten Codeausschnitt, der Ende November 2023 erstellt wurde. Die Benutzer können dieses Snippet interpretieren und mögliche Sicherheitslücken untersuchen, wenn es für den beabsichtigten Zweck verwendet werden sollte.
Probieren Sie es jetzt ausBlogbeitrag lesen

Alle Richtlinien durchsuchen

Durchsuchen nach:
Filter ausblenden
Auswahl
Filter einblenden
Auswahl
Filter löschen
Schlagwort
Super-Symbol [★]
Thema
Mehr ansehen

Unzureichende Protokollierung und Überwachung

Bewährte Verfahren:

Audit-Protokollierung für sensible Funktionen
Fehlerprotokollierung
Speicherung von Protokollen an einem zentralen Ort
Aufbewahrung von Protokollen für einen bestimmten Zeitraum
Regelmäßige Überprüfung von Protokollen auf PII

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.

Richtlinien anzeigen

Verwendung von Komponenten mit bekannten Sicherheitslücken

{
„Abhängigkeiten“: {
„foo“: „1,0,0-2,9999,9999",
„bar“: „>=1.0.2 <2.1.2"
}
}

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.

Richtlinien anzeigen

SQL-Einschleusung

importiere mysql.connector
db = mysql.connector.connect
#Bad -Praxis. Vermeide das! Das ist nur zum Lernen.
(host="localhost „, user="newuser „, passwd="pass „, db="sample „)
cur = db.cursor ()
name = raw_input ('Name eingeben: ')
cur.execute („SELECT * FROM Sample_DATA WHERE Name = '%s';“% name) für Zeile in cur.fetchall (): print (row)
db.schließen ()

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.

Richtlinien anzeigen

Sicherheitsfehler

Viele Frameworks verfügen auch über eine Reihe von Endpunkten, die aktiviert werden können, sodass die Anwendung überwacht werden kann, unabhängig davon, ob sich diese in einer Produktions- oder Test-/Entwicklungsumgebung befindet. Diese können beinhalten:

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

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.

Richtlinien anzeigen

Serverseitige Anforderungsfälschung

ts
lass url = request.params.url;

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

render.export () zurückgeben;

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.

Richtlinien anzeigen

Speicherung von Passwörtern

Merkmal Kryptographischer Hash Passwort-Hash Geschwindigkeit Sehr schnell Absichtlich langsam Arbeitsfaktor kann angepasst werden Nein Ja

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.

Richtlinien anzeigen

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>

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.

Richtlinien anzeigen

Fehlkonfiguration der Sicherheitseinstellungen — XXE detailliert

xml
<? xml-Version = „1.0"? >
<! DOCTYPE Äußeres Element [
<! ] >
<outerElement>&Externe Entität;</outerElement>

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.

Richtlinien anzeigen

Injektion — Pfaddurchquerung

Pseudo-
lass BaseFolder = „/var/www/api/documents/“;
let path = BaseFolder + request.params.filename;

gib file.read (Pfad) zurück;

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.

Richtlinien anzeigen

Authentifizierung und Autorisierung

cs

// Ensure the default behaviour is to authenticate requests, and check if they are admin
[Authenticate]
[Authorize("Admin")]
public class SecureController : Controller
{

}

public class MyController : SecureController
{

    // Overrides the Authorize attribute inherited to allow any user to access the page

Richtlinien anzeigen

Injektion - XSS

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

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.

Richtlinien anzeigen

Injektion 101

Einige der häufigsten Injektionsarten sind:

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

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.

Richtlinien anzeigen

Datei hochladen

öffentliche Zeichenfolge uploadProfilePicture (formFile uploadedFile)
{
//Generieren Sie den Pfad zum Speichern der hochgeladenen Datei unter
var-Pfad = $“. /uploads/avatare/ {request.user.ID}/{uploadedFile.filename}“;

//Speichere die Datei
var LocalFile = file.openWrite (Pfad);
Lokaldatei.write (hochgeladene Datei.readToEnd ());
Lokaldatei.flush ();
Lokaldatei.close ();

//Aktualisiere das Profilbild
userProfile.updateUserProfilePicture (request.User, Pfad)

Rückweg;
}

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.

Richtlinien anzeigen

Befehlsinjektion

let ip = request.params.IPAddress;

system („ping" + ip);

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.

Richtlinien anzeigen