Tareas públicas y directrices

Programación segura en la práctica

Infórmese sobre las directrices para una programación segura con el fin de comprender y solucionar las vulnerabilidades de seguridad del software, como las 10 principales de OWASP, y participe en misiones de formación guiadas para practicar simulaciones prácticas de aplicaciones.

Reservar una demostración
aprender bg
Misiones públicas
Directrices

Busca todas las misiones

Índice
Inyección SQLSolicitar Spring MVC MatchersFuente de troyanos: uso de componentes procedentes de fuentes no fiables.Firmaciones psíquicas: uso de componentes vulnerables conocidosApache Path Traversal: uso de componentes vulnerables conocidosCodestashbin - Función de restablecimiento de contraseña inseguraLog4j: uso de componentes vulnerables conocidosScripting entre páginas (XSS) en «ChatterGPT»
Ver más
Aumente la productividad
Inyección SQL
Un usuario nos ha informado de que ha sido capaz de explotar una vulnerabilidad de inyección SQL en la función de búsqueda de transacciones de la solución de banca por Internet. Afirmaron que fueron capaces de ver las transacciones que pertenecen a otros usuarios y señaló que esta vulnerabilidad podría permitir a un atacante hacer todo tipo de cosas desagradables a la base de datos como la caída de las tablas, ver los datos de otras tablas, insertar datos, etc. Intenta replicar lo que hizo el usuario en esta misión.
Pruébalo ahoraLeer la entrada del blog
Aumente la productividad
MvcRequestMatchers de Spring
En marzo de 2023, Spring publicó una corrección para una vulnerabilidad descubierta internamente, denominada CVE-2023-20860, en la que el uso de un doble comodín ** en mvcRequestMatchers podía provocar un desajuste de patrones entre Spring Security y Spring MVC. En última instancia, esto podría dar lugar a que los usuarios obtuvieran acceso no autorizado a determinados puntos finales. Hemos configurado una aplicación bancaria muy simplificada con unos pocos endpoints. Siga las instrucciones e intente reproducir el impacto de esta vulnerabilidad de control de acceso.
Pruébalo ahoraLeer la entrada del blog
Aumente la productividad
Firmas psíquicas - Uso de componentes vulnerables conocidos
CVE-2022-21449 tiene el alias más chulo para una vulnerabilidad, Psychic Signatures in Java. ¿Cómo obtuvo ese nombre? Es una referencia a los papeles psíquicos de Doctor Who. Cuando se le mostraban a alguien, estos trozos de papel en blanco se rellenaban con lo que esperaban ver. Algo similar ocurrió en la implementación Java (versiones 15 a 18) del algoritmo ECDSA, que tiene un efecto en la verificación de la firma de los JWT. Podemos enviar una firma inválida, pero Java pensará que es válida. ¿Quieres ver cómo funciona? Empecemos.
Pruébalo ahoraLeer la entrada del blog
Aumente la productividad
Apache Path Traversal - Uso de componentes vulnerables conocidos
El 4 de octubre de 2021, el equipo de Apache publicó la versión 2.4.49 de Apache para solucionar una vulnerabilidad de path traversal y ejecución remota de código en Apache 2.4.48, también conocida como CVE-2021-41773. El 7 de octubre de 2021, lanzaron la versión 2.4.51 debido a que la corrección de la revisión 2.4.50 no estaba completa. Esta vulnerabilidad fue rastreada como CVE-2021-42013. Prueba esta misión para ver por ti mismo cómo se puede explotar esta vulnerabilidad.
Pruébalo ahoraLeer la entrada del blog
Aumente la productividad
Log4j - Uso de componentes vulnerables conocidos
El anuncio a principios de diciembre de 2021 de un exploit de día 0 (CVE-2021-44228) en la muy popular biblioteca de registro Log4j, dejó caer una bomba en la comunidad Java. El exploit, apodado Log4Shell afecta a las versiones 2.0-beta9 a 2.14.1 de Log4j v2, y podría llevar a la ejecución remota de código. Hemos creado un entorno para simular el exploit, para que puedas ver el impacto de primera mano. Pruébalo ahora.
Pruébalo ahoraLeer la entrada del blog
Aumente la productividad
Trojan Source - Uso de componentes de fuentes no fiables
Uno de nuestros desarrolladores de Viking Bank copió ingenuamente un código de una fuente no fiable de Internet, que contiene potencialmente componentes vulnerables, para ayudar a escribir una comprobación de autorización de administrador para gestionar tarjetas de crédito. Nos hemos dado cuenta de que los usuarios han estado cambiando el límite de sus tarjetas de crédito, a pesar de que sólo los administradores deberían tener este privilegio. Creemos que hay algo en ese código. Prueba la misión para investigar el código.
Pruébalo ahoraLeer la entrada del blog
Aumente la productividad
Codestashbin - Función de restablecimiento de contraseña insegura
CodeStashBin es una de las mayores empresas de alojamiento de control de versiones de código del mundo. Se rumorea que el proceso de olvido de contraseña es defectuoso, con una vulnerabilidad insegura en la función de restablecimiento de contraseña. Podría ser posible cambiar la contraseña de un usuario privilegiado y obtener acceso a su cuenta. Entra en esta misión para investigar el problema.
Pruébalo ahoraLeer la entrada del blog
Aumente la productividad
Cross-site scripting (XSS) en 'ChatterGPT'.
Esta misión revela la interfaz familiar de un LLM popular y utiliza un fragmento de código real generado a finales de noviembre de 2023. Los usuarios pueden interpretar este fragmento e investigar cualquier posible fallo de seguridad si se utilizara para el fin previsto.
Pruébalo ahoraLeer la entrada del blog

Buscar en todas las directrices

Buscar:
Ocultar filtro
Selección
Mostrar filtro
Selección
Eliminar filtro
Palabra clave
Súper icono [★]
Tema
Ver más

Unzureichende Protokollierung und Überwachung

Mejores prácticas:

Registro de auditoría para funciones sensibles
Registro de errores
Almacenamiento de registros en una ubicación centralizada
Conservación de registros durante un periodo de tiempo definido
Auditoría periódica de registros para 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.

Ver las directrices

Uso de componentes con vulnerabilidades de seguridad conocidas

{
„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.

Ver las directrices

Inyección SQL

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.

Ver las directrices

Configuración incorrecta de la seguridad

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.

Ver las directrices

Falsificación de solicitudes del lado del servidor

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.

Ver las directrices

Speicherung von Passwörtern

Característica Hash criptográfico Hash de contraseña Velocidad Muy rápida Intencionadamente lenta Factor de trabajo ajustable No Sí

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.

Ver las directrices

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.

Ver las directrices

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.

Ver las directrices

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.

Ver las directrices

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

Ver las directrices

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.

Ver las directrices

Injektion 101

Algunos de los tipos de inyección más comunes son:

Inyección SQL
Cross-Site Scripting (Inyección HTML/Javascript)
Path Traversal (Inyección de ruta/Url)
Inyección de comandos
Inyección de código

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.

Ver las directrices

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.

Ver las directrices

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.

Ver las directrices