Inicio
Soluciones
Público missions y directrices

Codificación segura en la práctica

Explore las directrices de codificación segura para comprender y mitigar las vulnerabilidades del software, como las 10 principales de OWASP, y sumérjase en la formación guiada Missions para realizar prácticas en simulaciones de aplicaciones del mundo real.

Reservar una demostración
Público missions
Directrices

Ver todos missions

Índice
Inyección SQLMvcRequestMatchers de SpringTrojan Source - Uso de componentes de fuentes no fiablesFirmas 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 conocidosCross-site scripting (XSS) en 'ChatterGPT'.
Ver más
Aumentar 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.
Aumentar 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.
Aumentar 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.
Aumentar 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.
Aumentar 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.
Aumentar 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.
Aumentar 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.
Aumentar 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.

Ver todas las directrices

Buscar por:
Ocultar filtros
Mostrar filtros  
Limpiar filtros
Etiqueta
Tema
Ver más

Registro y supervisión insuficientes

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

El registro y la supervisión son a menudo una idea tardía cuando algo ya ha ido mal, pero en realidad, no asegurarse de que hay un registro y supervisión adecuados puede ser muy costoso. En un extremo, cuando se produce un incidente (relacionado con la seguridad o no), tener pocos registros o ninguno hace que sea imposible averiguar qué ha ocurrido realmente. En el otro extremo, registrar demasiados datos puede dar lugar a problemas de privacidad que, a su vez, pueden dar lugar a problemas con los organismos reguladores. Lee nuestra guía de buenas prácticas para evitar un registro y una supervisión insuficientes.

Ver directrices

Uso de componentes con vulnerabilidades conocidas

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

La mayoría de las aplicaciones hacen uso de grandes cantidades de componentes de terceros. Estos componentes proporcionan de todo, desde registro, plantillas, acceso a bases de datos y mucho más. Esto facilita mucho el desarrollo de software y ahorra mucho tiempo. Pero también están hechos por personas, lo que significa que algunos contendrán inevitablemente vulnerabilidades. Lee las directrices para saber más.

Ver directrices

Inyección SQL

import mysql.connector
db = mysql.connector.connect
#Mala práctica. ¡Evita esto! Esto es sólo para aprender.
(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()

La inyección SQL (SQLi) inyecta código en sentencias SQL para atacar y obtener información importante de una aplicación. Es una vulnerabilidad de seguridad web. Es la técnica más común de hacking que manipula la base de datos y extrae información crucial de ella.

Ver directrices

Falsificación de peticiones del lado del servidor

ts
let url = request.params.url;

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

return render.export();

Las vulnerabilidades de Falsificación de Peticiones del Lado del Servidor ocurren cuando un usuario es capaz de hacer que una aplicación haga peticiones HTTP a un dominio determinado por el atacante. Si una aplicación tiene acceso a redes privadas/internas, un atacante también podría hacer que la aplicación hiciera peticiones a servidores internos. Veremos esto más de cerca con algunos ejemplos para entender mejor cómo se ve en acción en esta guía.

Ver directrices

Desconfiguración de la seguridad

Muchos frameworks también tienen un conjunto de endpoints que se pueden habilitar y que permiten monitorizar la aplicación, ya sea en un entorno de producción o de pruebas/desarrollo. Estos pueden incluir:

Métricas (Prometheus)
Registros
Información del entorno
Asignaciones de ruta/Url

La desconfiguración de la seguridad es una especie de término general que abarca vulnerabilidades comunes que entran en juego debido a los ajustes de configuración de una aplicación, más que a un código defectuoso. Es un tema muy amplio y depende en gran medida de factores como la pila tecnológica. A menudo, solucionar estos problemas es algo que parece sencillo, como cambiar un archivo de configuración o incluso una sola línea de código, pero el impacto y las consecuencias de estas vulnerabilidades pueden ser graves. Lea nuestra guía para saber más sobre esta vulnerabilidad y cómo mitigarla.

Ver directrices

Almacenamiento de contraseñas

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

Si tu aplicación autentica usuarios, lo más probable es que también tenga que lidiar con contraseñas. Manejar las contraseñas de los usuarios es un asunto muy importante, y manejarlas adecuadamente lo es aún más. Es difícil imaginar un escenario peor que el de una aplicación atacada y las contraseñas de los usuarios filtradas por Internet a la vista de todos. ¿Cómo pueden almacenarse las contraseñas de forma segura y de acuerdo con las mejores prácticas? Veamos algunas formas.

Ver directrices

Error de configuración de seguridad - XXE detallado

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

La clase de vulnerabilidad "XML eXternal Entities" (XXE) es un fallo de seguridad que afecta a los analizadores XML. El estándar XML incluye formas de referenciar "entidades", como archivos y URLs. Por defecto, los analizadores suelen resolver completamente las entidades externas, lo que significa que los documentos XML pueden conducir a la divulgación de archivos y otra información sensible a posibles atacantes. Lea la directriz completa para obtener más información.

Ver directrices

Asignación de masas

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>  

La asignación masiva es una vulnerabilidad en la que los puntos finales de la API no restringen qué propiedades de su objeto asociado pueden ser modificadas por un usuario. Esta vulnerabilidad puede ocurrir cuando se hace uso de una librería/framework que permite la vinculación automática de parámetros HTTP a un modelo que luego pasa a ser utilizado sin ningún tipo de validación. El uso de la vinculación automática de una solicitud a un objeto puede ser extremadamente útil a veces, pero también puede conducir a problemas de seguridad si el modelo tiene propiedades que no están destinadas a ser accesibles para el usuario. Lea la directriz para más detalles.

Ver directrices

Inyección - Path Traversal

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

return file.read(path);

Path Traversal es otro tipo bastante común de vulnerabilidad de inyección. Suelen ocurrir cuando la construcción de un URI (ya sea para una URL, ruta de archivo, o de otro tipo) no garantiza adecuadamente que la ruta completamente resuelta no apunte fuera de la raíz de la ruta prevista. El impacto de una vulnerabilidad de cruce de ruta depende en gran medida del contexto en el que se produce el cruce y del refuerzo general que se haya realizado. Lea la directriz para obtener más información.

Ver directrices

Inyección - XSS

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

Cross-Site Scripting, también conocido como XSS, es otro tipo de vulnerabilidad de inyección que conduce a la evaluación de un script controlado por el atacante en el navegador de otro usuario. XSS también puede considerarse una vulnerabilidad de inyección HTML/JavaScript. Veamos los tipos de XSS que se pueden encontrar.

Ver directrices

Carga de archivos

public string UploadProfilePicture(FormFile uploadedFile)
{
    // Generate path to save the uploaded file at
    var path = $"./uploads/avatars/{request.User.Id}/{uploadedFile.FileName}";

    // Save the file
    var localFile = File.OpenWrite(path);
    localFile.Write(uploadedFile.ReadToEnd());
    localFile.Flush();
    localFile.Close();

    // Update the profile picture 
    UserProfile.UpdateUserProfilePicture(request.User, path)

    return path;
}

Es muy común que las aplicaciones, en algún momento u otro, necesiten permitir a los usuarios subir un archivo (ya sea para su uso o simplemente para su almacenamiento) en algún lugar dentro de la aplicación. Aunque parece bastante simple, la forma en que se implementa esta función puede ser bastante crítica debido a los riesgos potenciales asociados con la forma en que se manejan las cargas de archivos. Lea las directrices para obtener más información.

Ver directrices

Inyección 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

Una de las clases de vulnerabilidades más conocidas suelen ser las vulnerabilidades de inyección, especialmente, y sin sorprender a nadie, la indiscutible poster-child: La inyección SQL. Es difícil evitar oír hablar de la inyección SQL en el mundo de la tecnología, así que vamos a hablar de ella. Sigue leyendo para obtener una breve introducción a los fallos de inyección.

Ver directrices

Autenticación y autorización

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 directrices

Inyección de comandos

let ip = request.params.ipAddress;

system("ping " + ip);

Veamos la Inyección de Comandos por sí misma. Nos centraremos principalmente en algunos ejemplos diferentes para que sea más fácil ver cómo se ve en acción. Así que, como un rápido repaso, las vulnerabilidades de Inyección de Comandos ocurren cuando la entrada del usuario utiliza parte de un comando del sistema operativo. Lee la guía para más información.

Ver directrices

Codificación orientada al desarrollador.

Con seguridad.

Póngase en contacto con nosotros hoy mismo y haga de la seguridad del software una parte intrínseca de su proceso de desarrollo.

Reservar una demostración
Conectar
Facebook
X
LinkedIn
Empresa
Sobre nosotrosSociosCarrerasCentro de confianzaContacto con nosotrosEventosDirectricesDossier de prensaTienda
Producto
CoursesMissionsTournamentsEvaluacionesFormaciónSCW para GitHubSCW para JiraIntegracionesRecursos de aprendizajeNotas de publicaciónPlanes
Soluciones
GobiernoVenta al por menorFinanzas y bancaSegurosTecnologíaAutomóvilesSanidadEquipos de ingenieríaEquipos de seguridadC-Suite
Recursos
Centro de recursosBlogVídeosFolletoLibros blancosCasos prácticosInformesInfografíaLibros electrónicosSeminarios webGuías
Sydney
Boston
Portland
Londres
Brujas
Reikiavik
Copyright © 2015-2023 Secure Code Warrior Limited.
Política de privacidadPolítica de cookies | Accesibilidad | Aviso legal | Mapa del sitio