Tabla de Contenidos

[SAP] TurboResumenExpresSap.txt

Tema 1: Introducción a las aplicaciones seguras

1.1 Definiciones

1.2 Aplicaciones y servicios con estado (stateful)

En las aplicaciones con estado, el servidor mantiene información sobre el cliente desde que se conecta hasta que se desconecta.

1.3 Aplicaciones y servicios web sin estado (stateless)

En las aplicaciones stateless el server no almacena información sobre el estado del cliente, las sesiones no existen. El server procesa las solicitudes sin tener en cuenta peticiones anteriores del cliente. Las peticiones realizadas deben incluir la información necesaria para que el server pueda identificar al usuario.

1.4 Aplicaciones Web tradicionales y SPA

Tema 2: Vulnerabilidades y mecanismos de prevención

2.1 Marcos de referencia

2.2 Vulnerabilidades en el tratamiento de los datos de entrada

Una vulnerabilidad es una debilidad en alguno de los componetnes de un sistema informático que puede ser explotada por un atacante para causar algún tipo de daño. La debilidad más común suele ser el no validar losd atos de entrada provenientes del usuario o del entorno.

2.2.1 Inyección de código

Las vulnerabildiades de inyección de código utilizan como datos de entrada determinadas palabras o tokens especiales usados en el lenguaje en el eque están programadas. Cuando estos datos de entrada no se validan para tratar las palabras especiales, una entrada de un usuario puede cambiar la semántica del mensaje original, causando daños.

2.2.1.1 Inyección SQL

Se produce cuando:

Un ataque de inyección SQL puede resultar en revelación de información o borrado de datos importantes. Un ejemplo de inyección SQL sería: 

String consulta = "SELECT * FROM users WHRE email='" + email + "' AND password='" + password + "'";
String consulta = "SELECT * FROM users where email='email@email.com' OR '1' = '1' AND password='any'"

Otras formas de realizar ataques de inyección SQL serían las siguientes:

Se pueden prevenir inyecciones SQL de las siguientes formas: 

String query = "SELECT email, password, full_name FROM users WHERE email = ?"; #La ? representa los parámetros y se pueden establecer con métodos como setString, setDate....
PreparedStatement stmt = connection.prepareStatement(query);
stmt.setString(1,email);

La inyección SQL tiene las siguientes referencias:

2.2.1.2 Inyección en ficheros de log

Los ficheros de log permiten consutrir un historial de todos los eventos que ocurren durante la ejecución de un programa. Muchas veces se pueden usar para reconsutrir el escenario si se a producido algún problema. La inyección en ficheros de logn (Log inyection o Log Forgery) se produce cuando en el Log aparecen mensajes generados a raíz de entradas de usuario que no han sido correctamente validadas o escapadas.

Este tipo de ataque puede tener la siguientes consecuencias:

Para prevenir la inyección en ficheros de log se puede hacer lo siguiente:

Referencias:

2.2.1.3 Inyección en cabeceras HTTP

Se produce cuando se usan entradas de usuario incorrectamente escapadas para añadir cabeceras HTTP de forma dinámica e inesperada.

Estos ataques se pueden prevenir de la siguiente forma:

Referencias:

2.2.1.4 Inyección en SMTP

Se introduce una inyección en un pensaje SMTP cuando un atacante inserta cabeceras adicionales dentro de un correo electrónico mediante entradas de usuario. Este tipo de ataque se pueden prevenir de la siguiente forma:

Referencias:

2.2.1.5 Inyección de comandos del sistema operativo

Permite la ejecución arbitraria de comandos en el sistema en el que se ejecuta la aplicación. Para prevenir este tipo de ataque:

Referencias:

2.2.1.6 Inyección en LDAP

De forma similar a la inyección SQL, se pueden realziar inyecciones mediante el uso de cartacteres especailes en las entradas de usuario. Para prevenir esto se recomeinda:

Referencias:

2.2.1.7 Inyección en XML y Xpath

Se produce cuando los datos de entrada contienen caracteres reservados de XML, de forma que se genera un documento no esperado. Se puede prevenir este tipo de inyección de la siguiente forma:

Referencias:

2.2.1.8 Conlusiones de la inyección de código

2.2.2 Inyección de Javascript

Cross-Site Scripting (XSS) es un tipo de ataque de inyección de código que inyecta código javascript en el navegador del usuario cuando está accediendo al sitio web afectado. Las consecuencias pueden ser:

2.2.2.1 Tipo 1: Reflected XSS

El servidor lee los datos de la petición y los inserta sin validar en la respuesta, estos datos pueden contener código ejecutable. El servidor incluye en la respuesta HTTP el código JavaScript que el atacante ha insertado en la petición. Se añade el contenido JS a la URL, ejecutando el código en el navegador del usuario. Un ejemplo sería: 

http://patata.com/<script>alert("Ejemplo de Reflected XSS")</script>

2.2.2.2 Tipo 2: Stored XSS

El atacante consigue insertar texto javascript en la BBDD y pueden generar contenido HTML. Estos ataques pueden ser muy peligrosos en webs colaborativas como foros o redes sociales.

2.2.2.3 Tipo 0: DOM-Based XSS

La inyección se realiza en el navegador.

2.2.2.4 XFS y ClickJackign

Cross-Frame Scripting (XFS) es un ataque que combina la inyección de JS con el uso de Iframes. A través del iframe el atacante carga la web legítima con el objetivo de robar info del usuario. El clickjacking es un ataque que consiste en superponer un inframe transparente sobre la página que esta viendo el usuario.

2.2.2.5 XSHM

Cross Site History Manipulation (XSHM) es un ataque que se basa en el hecho de que el historial del navegador contiene entradas a las webs visitadas por el usuario. Este historial se puede accewder mediante JS con el objeto history.

2.2.2.6 Prevención de la inyección de javascript

2.2.2.7 Prevención de XFS

2.2.3 Content Security Policy (CSP)

Es un mecanismo que permite restringir los contenidos que el navegador puede cargar en un sitio Web. Se centra en detener ataques de inyección de código, centrándose en XSS. Se puede especificar en una cabecera dentro de la respeusta HTTP que el servidor envía al navegador. Los CSP siguen la siguiente sintaxis: 

Content_security-Policy: <directiva>; <directiva>

Existen directivas para restringir:

2.2.3.1 script-src

Controla de manera exhaustiva el origen de todos los scripts. 

Content-Security-Policy: scriptsrc <origen>;
Content-Security-Policy: scriptsrc <origen> <origen>;

Valores de los source:

No se recomienda activar ninguno de los valores usanfe para minimizr los riesgos de ataques de inyuección JS.

2.2.3.2 frame-ancestors

Permite definir cuando es posible incluir un sitio web dentro de un iframe, similar a la cabcera X-FRAME-OPTIONS 

Content-Security-Policy: frame-ancestors 'none';
Content-Security-Policy: frame-ancestors 'self' http://patata.org;

El valor none es equivalente a DENY.

2.2.3.3 report-uri y report-to

Permiten especificar una URL a la que enviar las notificaciones cuando el navegador detecta contenido que no cumple con la política definida. 

Content-Security-Policy: defautl-src https:; report-uri /csp-violation-report-endpoint/

2.2.4 Inyección de entidades externas en XML (XXE)

Es un ataque que afecta al lenguaje XML que consiste en añadir referencias a elementos externos dentro de un documento XML con el objetivo de causar daño. Se produce un ataque de SSRF (Server Side Request Forgery) cuando un atacante consigue acceder a un servicio interno de una organización incluso cuando este servicio se encuentra protegido por un cortafuegos Para prevenir estos tipos de ataques se pueden usar:

2.2.5 Deserialización y carga dinámica

2.2.5.1 Deserialización

La serialización es un proceso que transforma un objeto de un lenguaje en un flujo de texto o binario. La deserialización es el proceso contrario, el cual transforma un flujo de datos en objetos. Se produce una deserialización insegura cuando no se valida si el flujo de datos de entrada va a crear objetos del tipo esperado. En java para serializar y deserializar un objeto a XML se pueden usar las siguientes clases:

Si no se hacen validaciones, la deserialización puede ser peligrosa ya que podría permitir la ejecución arbitraria de cualquier método de cualquier clase de java. Para mitigar este tipo de ataque se puede hacer lo siguiente:

2.2.5.2 Carga dinámica

Una vulnerabilidad similar a la deserialización es la de la carga dinámica segura (Unsafe reflection). El API de reflection de algunos leguajes permite crear objetos a partir de su nombre

2.2.6 Desbordamiento de Pila

app:estructurapila.png Se produce un desbordamiento de buffer (Buffer overflow o Buffer Overrun) cuando un programa permite la escritura de datos mas allá del buffer asignado. La a estructura de memoria de un programa en C es la siguiente:

La estructura de un frame del stack en la siguiente: app:estructuraframestack.png

Al comienzo de la llamaca a una función se ejecuta un fragmento de ensamblador denominado secuencia de entrada que: 

_Funcion:
  push ebp
  mov ebp, esp
  sub esp, 12

Si la función se invoca con argumentos, los parámetros se añaden al principio del frame con una llamada call equivalente a push + jump. 

push eip + 2
jmp _funcion2

Al terminar la llamada de una función se ejecutan las siguientes secuencias de salida: 

mov esp, ebp
pop ebp
ret

2.2.6.1 Prevención del desbordamiento de pila

2.2.6.2 Ensamblador x86

push <mem>
pop <mem>
mov <destino> <origen>
sub <mem1> <mem2>
jmp <etiqueta>

2.2.7 Validación de datos

La principal utilidad de realizar estas validaciones en el cliente son:

Generalmente el comprobar que los datos proporcionados por el usuario son validops sdebería ahcerse siempre en el servidor. En java hay API de validación estándar formado por las clases del paquete javax.validation. Este API permite establecer anotaciones sobre los atributros delos objetos en los que se reciben los datos de entrada.La especificación 2.0 del API de validación de Java incluye las siguientes validaciones de serie:

2.3 Vulnerabilidades en la autenticación

Permiten a un atacante obtener las credenciales de los usuarios de la aplicación. Explotan debilidades como las siguientes:

Recomendaciones:

2.3.1 Hashes

2.3.2 PBKDF2

Algoritmo hash muy utilizado, permite especificar un salta y un número de interaciones que se realizarán para calcular el hash final.Se suele combinar con HMAC-SHA que es una forma especial de usar SHA.

2.3.3 Bcrypt

Otra de las funciones hash más utilizadas. Diseñado para ralentizar los ataques de fuerza bruta. Incluye un factor de trabajo configurable para establecer el tiempo que tarda el algoritmo en calcular el hash. En la mayoría de sus implementaciones añade Salt aleatorio de forma automática en cada llamada.

2.3.4 Escenarios

Formas de almacenar las contraseñas desde las más inseguras hasta las más seguras:

2.3.5 Transmisión

2.4 Vulnerabilidades en el manejo de la sesión

Consisten en el robo de sesiones una vez que el usuario ya esté autenticado.

2.4.1 Secuestro de la sesión

2.4.2 Fijación de la sesión

Session fixation es una variante del secuestro de sesión en la que el atacante consigue que la víctima se autentique usando un identificador de sesión generado por el atacante.

  1. El atacante accede a la pagina de autenticación
  2. El servidor crea un ID de sesión y se lo asigna a esa sesión
  3. El atacante envía a la víctima un enlace que de alguna manera incluya una URL con el identificador de sesión del atacante
  4. La víctima utiliza el enlace para autenticarse, enviando el identificador de sesión que le envió el atacante
  5. la víctima proporciona sus credenciales y pasa a ser una sesión autenticada.
  6. El atacante conoce el identificador de la víctima y lo puede usar para realizar acciones en su nombre.

Existen otros métodos más sofisticados:

Para prevenir este tipo de ataques se recomienda generar una cookie de sesión nueva cada vez que el usuario se autentica, de esta forma el identificador de sesión que conoce el atacante deja de ser válido.

2.4.3 Reescritura de URl

Muchos servidores envían el identificador de sesión en la URL, esto propicia que el identificador de sesión sea altamente vulnerable a distintos tipos de sustracción. La cabecera HTTP refer contiene información sobre la web desde la que se origina la petición, por lo tanto, si el atacante consigue redirigir el navegador de la víctima hasta una web que el controla, pude capturar la URL de origen con la cabecera en cuestión. Si la cabecera es el identificador de sesión el atacante lo puede usar para realizar peticiones en nombre de la víctima.

2.4.4 Política de mismo origen

La Same-origin Policy define una serie de reglas para restringir como un documento o sus scripts pueden interacturar con otros recursos localizados en dominios diferentes. Esta política se implementa en el navegador web. Dos webs tienen el mismo dominio si el protocolo, nombre de dominio y puerto son los mismos.

2.4.5 CORS

El intercambio de recursos de origenes cruzados permite al navegador solicitar recursos de dominios diferentes. Para permitir al navegador solicitar recursos a troso domios, el servidor web del dominio destino envía ciertas cabeceras http adicionales para aceptar o denegar la solicitud.

2.4.5.1 CORS en peticiones simples

Son peticiones simples aquellas cuyo método HTTP es HEAD, GET o POST con solicitudes con cabeceras como Accept, Accept-Language, Content-Type… El navegador enviará la cabecera Origin en la petición. la respuesta del servidor envía varias cabeceras con el prefijo Access-Control:

2.4.5.2 CORS en peticiones complejas

Se consideran complejas aquellas que no son GET, HEAD o POST, como PUT o DELETE y aquellas que no usen cabeceras simples. Estas solicitudes hacen una solicitud inicial de verificación a través de método OPTIONS con las siguientes cabeceras:

La respuesta que envía el servidor puede incluir las siguientes cabeceras:

2.4.6 CSRF

Cross Site Request Forgery es una vulnerabilidad en la que el atacante usa el navegador de la víctima para ejecutar una petición maliciosa en su nombre sobre una web vulnerable. Al usarse el navegador de la víctima también se añade la cookie de esta, por lo que no es posible diferenciar si la víctima ejecuta la acción voluntariamente o no. Esta vulnerabilidad explota la confianza que tiene un sitio web en sus usuarios.

2.5 Exposición de Información Sensible

Es una vulnerabilidad transversal relacionada con las otras vulnerabilidades. Abarca un amplio espectro desde el robo de credenciales y ataques man in the middle hasta cualquier otro tipo de caputra de información sin cifrar que pase por la red. Para obtener información sensible del sistema o del usuario se pueden usar las siguientes vulnerabilidades:

2.5.1 Man in The Middle

El atacante es capaz de itnerferir en las comunicaciones entre un cliente y un servidor, capturando los mensajes entre ambos interlocutores e incluso inyectando mensajes modificados en el canal de modificación. Con este tipo de ataque es posible ejecutar session hijacking. También puede utilizar:

2.6 Vulnerabilidades en el control de acceso

Las directivas de control de acceso tienen como objetivo garantizar que los usuarios solo puedan usar las funcionalidades de las que tenga permiso. Las vulnerabilidades de este tipo suelen ser:

El controlde acceso debe seguir el principio de menor privilegio (POLP), que consiste en limitar los permisos de acceso a un usuario a los mínimos posibles para que pueda usar la aplicación. Cuando no existe control de acceso, el atacante puede acceder a algunas zonas de la aplicación a las que no debería.

2.6.1 Prevención

2.6.2 Directory Traversal

Es una vulnerabilidad que permite a un atacante acceder a ficheros a los que no debería tener acceso. Se explota a través de la concatenación de cadenas y del uso del string ”../“ para conseguir acceder fuera del directorio raíz de la web. Estos ataques pueden ser mitigados de la misma forma que los ataques de inyección de código.

2.7 configuración de seguridad incorrecta

Puede lelgar a ser una vulnerabildiad muy importante que peude afectar a cualquier elemento. Destacan los siguientes elementos susceptibles:

También se pueden incluir diferentes parámetros relacionados con el control de acceso:

2.8 Monitorización y Log insuficientes

TEMA 3. Ciclos de desarrollo de software seguro

para minimizar los riesgos de que se produzcan vulnerabildiades en el software se deben abordar los aspectos de seguridad en las primeras fases del ciclo de vida de desarrollo. El coste de encontrar vulnerabilidades en las primeras fases es muy inferiror al coste de detectarlas más tarde. El coste de un problema de seguridad puede llegar a multiplciarse por 25 desde la fase de diseño.

3.1 Secure Development Lifecycle (SDL)

Estandariza un conjunto de buenas prácticas para aplicar durante el desarrollo de una aplicación.

3.1.1 Fase de Formación

Se debe impartir a Desarrolladores, Equipos de pruebas y jefes de proyecto. Esta formación debe ser continuada y periódica para que todos los involucrados en el proyecto estén al día de los cambios en los procedimientos.

3.1.2 Fase de Análisis

Definición de los requisitos de seguridad

Definición de umbrales de calidad que se espera obtener Modelado de casos de uso o historias de usuario relacionadas con la seguridad desde el punto de vista de un atacante Evaluación de riesgos identificando los elementos funcionales más críticos.

3.2.3 Fase de diseño

3.2.4 Fase de implemetnación

3.2.5 Fase de Pruebas

3.2.6 Fase de pentesting

Son pruebas que se realizan sobre el software simulando ataques que podría realizar un hacker. Pueden ser de caja blanca (El auditor tiene toda la info sobre el sistema) o de Caja Negra (El auditor va a ciegas)

Tema 4: Mecanismos de autenticación, Autorización y control de acceso

app:tema4diagsec.png

4.1 Autenticación y Autorización

4.1.1 Autenticación en HTTP

HTTP proporciona cabeceras estándar como Authorization para una petición y WWW-Autehnticate para la respuesta que pueden ser usadas para autenticación y autorización.

4.1.2 JSON Web Token (JWT)

Define un formato compacto para obtener info JSON de forma segura entre dos partes.

4.1.3 OAuth

Problemas que suelen encontrarse:

OAuth surge para dar solución al problema y en la práctica también resuelve el problema 2. En la actualidad está en su versión 2.0 que no es compatible con la 1.0 ya que usan protocolos distintos.

4.1.3.1 Flujos

Para soportar distintos escenaros que difieren en el tipo de app cliente o si son o no del mismo proveedor Oauth contempla varios flujos, aunque nos centraremos en el Authorization Code, el más relevante.

4.1.3.2 PKCE

El flujo antes descrito está sujeto a dos tipos de vulnerabilidades:

Oauth dispone del parámetro state para hacer frente a la vulnerabilidad 1 y la técnica PKCE protege contra ambas vulnerabilidades.

4.1.4 OpenID Connect

Es un protocolo de autenticación y autorización consutrido por encima de OAuth, reutilizando los flujos, tokens de acceso y refresco, endpoints Authorization, troken, introspection… Lo que sería todo. OIDC añade las siguientes novedades:

OIDC tiene los siguientes claims y scopes:

OIDC se diferencia de OAuth en que, además de ser un protocolo de autorización, también es un protocolo de autenticación.

4.1.5 SAML

Security Assertion Markup Languaje es un protocolo de autenticación y autorización estandarizado por OASIS. OIDC es un rediseño conceptual de SAML en base a principios REST y JSON. La mayor parte de los IdPs proprocionan una implementación de SAML además de OAuth/OIDC.

4.1.6 Kerberos y SPNEGO

4.3 Control de acceso

4.3.1 Basado en Roles

4.3.2 Basado en Atributos

Modelo ABAC (Attribute Based Access Control) hace frente a las limitaciones del modelo RBAC.

XACML (eXtensible Access Control Markup Languaje) es un estándar de OASIS que define un leguanje XML para la definición de políticas, una arquitectura de control de acceso y el formato de las peticiones /respuestas del PEP al PDP.