OWASP

Proyecto Abierto de Seguridad en Aplicaciones Web

Descripción
Es una comunidad abierta dedicada a permitir que las organizaciones desarrollen, adquieran y
mantengan aplicaciones y APIs en las que se pueda confiar.
Todas las herramientas de OWASP, documentos, videos, presentaciones y capítulos son gratuitos y
abiertos a cualquier interesado en mejorar la seguridad en aplicaciones.
Abogamos por resolver la seguridad en aplicaciones como un problema de personas, procesos y
tecnología, ya que los enfoques más efectivos para la seguridad en aplicaciones requieren mejoras
en todas estas áreas.
OWASP no está afiliada con ninguna compañía de tecnología, aunque apoyamos el uso instruido de
tecnologías de seguridad comercial.
OWASP produce muchos tipos de materiales en una manera abierta y colaborativa.
La Fundación OWASP es una entidad sin fines de lucro para asegurar el éxito a largo plazo del
proyecto. Casi todos los asociados con OWASP son voluntarios, incluyendo la junta directiva de
OWASP, comités globales, líderes de capítulos, los líderes y miembros de proyectos. Apoyamos la
investigación innovadora sobre seguridad a través de becas e infraestructura.
Tema Importante
El software inseguro está debilitando las finanzas, salud, defensa, energía, y otras
infraestructuras críticas.
A medida que el software se convierte en algo crítico, complejo e interconectado, la
dificultad de lograr seguridad en las aplicaciones aumenta exponencialmente.
El ritmo vertiginoso de los procesos de desarrollo de software actuales, incrementa aún más
el riesgo de no descubrir vulnerabilidades de forma rápida y precisa. Ya no podemos
permitirnos tolerar problemas de seguridad relativamente simples como los presentados en
este

OWASP Top 10.

OWASP Top 10
El software inseguro está debilitando las finanzas, salud, defensa, energía, y otras
infraestructuras críticas.
A medida que el software se convierte en algo crítico, complejo e interconectado, la
dificultad de lograr seguridad en las aplicaciones aumenta exponencialmente.
El ritmo vertiginoso de los procesos de desarrollo de software actuales, incrementa aún más
el riesgo de no descubrir vulnerabilidades de forma rápida y precisa. Ya no podemos
permitirnos tolerar problemas de seguridad relativamente simples como los presentados en
este

OWASP Top 10.

A03:2021 – Injection
Ocupa la tercera posición.
Las debilidades comunes:
Cross-site Scripting
SQL Injection
External Control of File Name o Path.
Cross-site Scripting
Los ataques Cross-Site Scripting (XSS) son un tipo de inyección
Se Inyectan scripts maliciosos en sitios web que, de otro modo, serían benignos y
confiables.
Atacante usa una aplicación web para enviar código malicioso, generalmente en forma de
un script del lado del navegador, a un usuario final diferente.

Ocurren en cualquier lugar donde una aplicación web use la entrada de

un usuario dentro de la salida que genera sin validarla o codificarla.
Debido a que el navegador cree que el script proviene de una fuente confiable:
Puede acceder a cualquier cookie, token de sesión u otra información confidencial
retenida por el navegador y utilizada con ese sitio.
Pueden incluso reescribir el contenido de la página HTML.
Una aplicación es vulnerable cuando:
La aplicación no valida, filtra ni desinfecta los datos proporcionados por el usuario.
Contiene consultas dinámicas o llamadas no parametrizadas
Los datos hostiles se utilizan dentro de los parámetros de búsqueda de mapeo relacional de
objetos (ORM) para extraer registros confidenciales adicionales.
Los datos hostiles se utilizan o concatenan directamente. El comando SQL o contiene la estructura
y los datos maliciosos en consultas dinámicas, comandos o procedimientos almacenados.
Algunas de las inyecciones más comunes son SQL, NoSQL, comando OS, asignación relacional
de objetos (ORM), LDAP e inyección de lenguaje de expresión (EL) entre otros. El
concepto es idéntico entre todos los intérpretes.
La revisión del código fuente es el mejor método para detectar si las aplicaciones son vulnerables
a las inyecciones. Se recomienda encarecidamente la prueba automatizada de todos los
parámetros, encabezados, URL, cookies, JSON, SOAP y entradas de datos XML.
Como prevenir…
Prevenir la inyección requiere mantener los datos separados de los comandos y consultas:
La opción preferida es usar una API segura, que evita usar el intérprete por completo, proporciona
una interface parametrizada o migra a herramientas de mapeo relacional de objetos (ORM).
Utilice una validación de entrada positiva del lado del servidor. Esta no es una defensa completa ya
que muchas aplicaciones requieren caracteres especiales, como áreas de texto o API para
aplicaciones móviles.
Para cualquier consulta dinámica residual, quite las palabras reservadas soportadas por el intérprete.
Nota: las estructuras SQL, como los nombres de las tablas, los nombres de las columnas, etc., no se
pueden escapar y, por lo tanto, los nombres de estructuras proporcionados por el usuario son
peligrosos. Este es un problema común en el software de redacción de informes.
Utilice LIMIT o ROWS y otros controles de SQL dentro de las consultas para evitar la
divulgación masiva de registros en caso de inyección de SQL.
External Control of File Name o Path
El producto permite que la entrada del usuario controle o influya en las rutas o nombres de
archivo que se utilizan en las operaciones del sistema de archivos.
Esto podría permitir que un atacante acceda o modifique los archivos del sistema u otros
archivos que son críticos para la aplicación.
Los errores de manipulación de ruta ocurren cuando se cumplen las siguientes dos
condiciones:
Un atacante puede especificar una ruta utilizada en una operación en el sistema de
archivos.
Al especificar el recurso, el atacante obtiene una capacidad que de otro modo no estaría
permitida.
Por ejemplo, el programa puede dar al atacante la capacidad de sobrescribir el archivo
especificado o ejecutarlo con una configuración controlada por el atacante.
A01:2021 – Broken Access Control
Ocupa la primera posición.
Las debilidades comunes:
Violación del principio mínimo o denegación por defecto
Omitir las comprobaciones de control de acceso mediante la modificación
de la URL.
Permitir ver o editar la cuenta de otra persona, al proporcionar su
identificador único
Acceso a la API sin controles de acceso para POST, PUT y DELETE.
La configuración incorrecta de CORS permite el acceso a la API desde
orígenes no autorizados/no confiables.
Como prevenir…
Excepto para los recursos públicos, denegar por defecto.
Implemente mecanismos de control de acceso una vez y reutilícelos en toda la aplicación, incluida la
minimización del uso compartido de recursos de origen cruzado (CORS).
Los controles de acceso al modelo deben imponer la propiedad de los registros en lugar de aceptar que el
usuario pueda crear, leer, actualizar o eliminar cualquier registro.
Los modelos de dominio deben hacer cumplir los requisitos de límite comercial de aplicaciones únicas.
Deshabilite la lista de directorios del servidor web y asegúrese de que los metadatos del archivo (por
ejemplo, .git) y los archivos de copia de seguridad no estén presentes en las raíces web.
Registre fallas de control de acceso, avise a los administradores cuando corresponda (por ejemplo, fallas
repetidas).
Tasa de límite API y acceso al controlador para minimizar el daño de las herramientas de ataque
automatizado.
Los identificadores de sesión con estado deben invalidarse en el servidor después de cerrar la sesión. Los
tokens JWT sin estado deberían ser de corta duración para minimizar la ventana de oportunidad para un
atacante. Para los JWT de mayor duración, se recomienda encarecidamente seguir los estándares de OAuth
para revocar el acceso.
Access Control Design Principles
Diseñar el control de acceso a fondo desde el principio: El diseño de control de acceso puede comenzar de
manera simple, pero a menudo puede convertirse en un control de seguridad complejo y con muchas funciones.
Forzar todas las solicitudes para pasar por verificaciones de control de acceso: Asegúrese de que todas las
solicitudes pasen por algún tipo de capa de verificación de control de acceso, filtros, etc.
Denegar por defecto: Denegar por defecto es el principio de que si una solicitud no está específicamente
permitida, se deniega. Hay muchas formas en que esta regla se manifestará en el código de la aplicación. Algunos
ejemplos de estos son:
El código de la aplicación puede generar un error al procesar las solicitudes de control de acceso.
Creación de cuenta siempre mínimo acceso.
Creación nueva función a una aplicación, se debe negar a todos los usuarios.
Principio de privilegio mínimo: Asegúrese de que a todos los usuarios, programas o procesos se les otorgue el
mínimo o el mínimo acceso necesario posible.
No codificar roles: Muchos aplicaciones utilizan de forma predeterminada el control de acceso basado en
funciones.
Registrar todos los eventos de control de acceso: Todas las fallas de control de acceso deben registrarse, ya que
pueden ser indicativas de un usuario malintencionado que investiga la aplicación en busca de vulnerabilidades.
 A02:2021 – Cryptographic Failures
Ocupa la segunda posición.
Se centra en las fallas relacionadas con la criptografía (o la falta de esta)
¿Se transmite algún dato en texto claro? Esto se refiere a protocolos como HTTP, SMTP, FTP que
también usan actualizaciones de TLS como STARTTLS. El tráfico de Internet externo es peligroso.
Verifique todo el tráfico interno, por ejemplo, entre balanceadores de carga, servidores web o sistemas
back-end.
¿Se utilizan protocolos o algoritmos criptográficos antiguos o débiles de forma predeterminada o en
código antiguo?
¿Están en uso las claves criptográficas predeterminadas, se generan o reutilizan claves criptográficas
débiles, o falta una gestión o rotación de claves adecuada? ¿Se registran las claves criptográficas en los
repositorios de código fuente?
¿No se aplica el cifrado, por ejemplo, faltan encabezados o directivas de seguridad de encabezados
HTTP (navegador)?
¿Se ignoran, reutilizan o no se generan los vectores de inicialización lo suficientemente seguros para el
modo criptográfico de operación? ¿Se está utilizando un modo de operación inseguro como ECB? ¿Se
usa el cifrado cuando el cifrado autenticado es más apropiado?
A02:2021 – Cryptographic Failures
Ocupa la segunda posición.
Se centra en las fallas relacionadas con la criptografía (o la falta de esta)
¿Se utiliza la aleatoriedad con fines criptográficos que no fueron diseñados para cumplir con los
requisitos criptográficos? Incluso si se elige la función correcta, ¿debe ser sembrada por el
desarrollador y, de no ser así, el desarrollador ha sobrescrito la funcionalidad de siembra fuerte
integrada con una semilla que carece de suficiente entropía/imprevisibilidad?
¿Se utilizan funciones hash en desuso, como MD5 o SHA1, o se utilizan funciones hash no
criptográficas cuando se necesitan funciones hash criptográficas?
¿Están en uso métodos de relleno criptográfico en desuso, como PKCS número 1 v1.5?
¿Son explotables los mensajes de error criptográficos o la información del canal lateral, por
ejemplo, en forma de ataques de oráculo de relleno?
¿Se utilizan contraseñas como claves criptográficas en ausencia de una función de derivación de
clave base de contraseña?
¿El certificado del servidor recibido y la cadena de confianza están debidamente validados?
Como prevenir…
Clasificar los datos procesados, almacenados o transmitidos por una aplicación. Identifique qué datos son
confidenciales de acuerdo con las leyes de privacidad, los requisitos reglamentarios o las necesidades
comerciales.
No almacene datos confidenciales innecesariamente. Los datos que no se retienen no se pueden robar.
Asegúrese de cifrar todos los datos confidenciales en reposo.
Asegúrese de que se implementen algoritmos, protocolos y claves estándar sólidos y actualizados; utilizar una
gestión de claves adecuada.
Cifre todos los datos en tránsito con protocolos seguros.
Deshabilite el almacenamiento en caché para las respuestas que contienen datos confidenciales.
Aplicar los controles de seguridad requeridos según la clasificación de datos.
Almacene contraseñas utilizando funciones de hashing sólidas con un factor de trabajo (factor de demora), como
Argon2, scrypt, bcrypt o PBKDF2.
Los vectores de inicialización deben elegirse de forma adecuada para el modo de operación. Generador de
números pseudoaleatorios criptográficamente seguro - HSM.
Asegúrese de que se utilice la aleatoriedad criptográfica cuando corresponda y de que no se haya sembrado de
forma predecible o con baja entropía.