1 of 54

Seguridad

Web 2 - 2019(TUDAI)

2 of 54

¿Qué es seguridad?

La seguridad de la información es el conjunto de medidas preventivas y reactivas de las organizaciones y de los sistemas tecnológicos que permiten resguardar y proteger la información buscando mantener la confidencialidad, la disponibilidad e integridad de los datos y de la misma.

3 of 54

Seguridad

La mayoría de los problemas de seguridad en los sitios web se encuentran a nivel aplicación y son el resultado de escritura defectuosa de código.

Programar aplicaciones web seguras requiere tener en cuenta los riesgos que puede correr la información contenida, solicitada y recibida.

4 of 54

Mecanismos de Seguridad

Asegurar el acceso a la información -> AUTENTICACIÓN

Protección de los datos críticos (contraseñas, tarjetas de crédito) -> ENCRIPTACIÓN

Comunicación segura -> CERTIFICADOS

5 of 54

Encriptación

6 of 54

Encriptación

Es el proceso de hacer ilegible información importante. Una vez encriptada sólo puede leerse al aplicar una clave.

En general en los sitios web, la información es protegida a través de dos protocolos de seguridad:

  • Encriptación de Datos
  • Uso de Claves de Seguridad

La encriptación permite la transmisión segura de información, al codificar los datos transmitidos usando una fórmula matemática sobre los datos. Por lo general en los sitios web se utiliza el protocolo “SSL”.

7 of 54

Encriptación vs Codificación

La codificación es un proceso de transformación, convirtiendo una estructura a otra, de acuerdo a una especificación conocida. No requieren parámetros para aplicarse.

Por ejemplo:

  • Image enconder base64. Ver : https://www.base64-image.de/
  • SHA1
  • Video encoders/decoders

8 of 54

Encriptación - Protocolos

MD5 (Message-Digest Algorithm 5): Es una función hash de 128 bits. No sirve para cifrar un mensaje. La información original no se puede recuperar. Es usado para firmas digitales.

MD5("") = d41d8cd98f00b204e9800998ecf8427e

SHA (Secure Hash Algorithm): Familia de funciones hash de cifrado. SHA-0 y SHA-1 producen una salida de 160 bits (20 bytes) de un mensaje que puede tener un tamaño máximo de 2**64 bits. Es parecido al MD5 pero la función de compresión es más compleja.

9 of 54

Encriptación - Protocolos

SHA-1 es más lento que MD5 porque el número de pasos son de 80 (64 en MD5) y porque tiene mayor longitud que MD5 (160bits contra 128bits). SHA-1, más robusto y seguro.

Ejemplo: SHA1("") = da39a3ee5e6b4b0d3255bfef95601890afd80709

SHA-2: Las principales diferencias con SHA-1 radica en en su diseño y que los rangos de salida han sido incrementados y podemos encontrar: SHA-224, SHA-256, SHA-384, y SHA-512. El más seguro, es el que mayor salida de bits tiene, el SHA-512.

SHA-3 (Agosto 2015): consiste en una familia de 4 funciones criptográficas, SHA3-224, SHA3-256, SHA3-384, y SHA3-512, y dos funciones de salida.

10 of 54

Encriptación - Ataques

Para una clave de 12 dígitos, escrita con un teclado con 97 caracteres, en un ataque por fuerza bruta habría que realizar:

97**12 = 693.842.360.995.438.000.295.041 comprobaciones.

  • Para MD5, la salida es de 128 bits, sería necesario realizar:

2**128=3,402823669 * 10**38 operaciones.

Con ataques basados en búsqueda de colisiones:

  • Para MD5, la salida es de 128 bits, hay que operar sobre la mitad de bits:

2**64=18.446.744.073.709.551.616 operaciones.

  • Para el algoritmo SHA 1, cuya salida es de 160 bits:

2**80=1.208.925.819.614.629.174.706.176 operaciones.

100.000 de procesadores de 1 Ghz tardarían más de 38.000 años !!!

11 of 54

Encriptación en PHP

En PHP contamos con diferentes funciones de encriptación, siendo una de las más utilizadas la función MD5().

<?php

$clave = "jose";

$clave_encriptada = md5($clave);

echo "La clave $clave encriptada con MD5 es la siguiente: $clave_encriptada";

?>

Encriptando “jose” con MD5 se obtiene unívocamente:

662eaa47199461d01a623884080934ab

El resultado de un texto plano encriptado en MD5 siempre tendrá 32 caracteres de longitud.

12 of 54

Autenticación

13 of 54

Autentificación / Autenticación

Es el proceso de verificar la identidad digital del remitente de una comunicación como una petición para conectarse.

El remitente autenticado puede ser una persona que usa un dispositivo, un dispositivo por sí mismo o un programa del dispositivo.

14 of 54

Autorización

Proceso por el cual la red de datos autoriza al usuario identificado a acceder a determinados recursos de la misma.

Un rol podría estar compuesto por niveles de autorización dentro del sistema.

15 of 54

Mecanismos de autenticación de un usuario

  • Definido por el usuario: Un password (Unix) o passphrase (PGP).

16 of 54

Mecanismos de autenticación de un usuario

  • Por dispositivos/tarjetas: tarjeta de identidad, tarjeta inteligente (smartcard), dispositivo usb tipo epass token, tarjeta de coordenadas, smartphone o dongle criptográfico.

17 of 54

Mecanismos de autenticación de un usuario

  • Basados en una característica física del usuario: verificación de voz, de escritura, de huellas, de patrones oculares, etc.

18 of 54

Autenticación - Autorización

Primero se debe conocer que usuario es y luego si puede acceder al recurso solicitado.

(Role based Access control)

19 of 54

Implementar un mecanismo de autenticación?

  • Recordemos : HTTP es “stateLess”
  • Tenemos que implementar nuestro mecanismo:
    • Por manejo de sesiones
    • Por API

20 of 54

Por manejo de sesiones

  • En el servidor se lleva cuenta de datos del usuario
    • EN PHP, se usa la variable�$_SESSION["name"] = $username;
  • Puedo permitir acciones, mientra tenga una “Sesión activa”
  • if (isset($_SESSION['loggedin']) && $_SESSION['loggedin'] == true)
  • { ….. DO EVERYTHING …..}

21 of 54

Por manejo de sesiones (cont.)

  • Antes de abrir una sesión, el usuario deberá autenticarse (user + pass)
    • Pueden existir usuarios anónimos, que no lo requieren, pero debería ver qué permisos tiene
  • Debo destruir la sesión al hacer logout
    • En caso que el usuario nunca hizo “logout”, deberíamos hacer que la sesión se cierre después de un tiempo

22 of 54

Por API

  • Se realiza a través de “Tokens”
  • Por cada conexión el usuario, pide un “token” y lo utiliza en cada petición
    • No hay una sesión en el servidor

23 of 54

Por API (cont.)

  • El servidor si tiene que implementar un “manejador” de tokens
    • Puede ser local en memoria -> similar a una sesión
    • En la BBDD (puede ser distribuido)
  • La API debe modificarse para soportar el acceso por token
  • El cliente tiene que también manejar el token y

24 of 54

Comunicación de los datos

25 of 54

Cifrado

Los mensajes viajan en paquetes que pueden ser interceptados en la red y sin estar cifrados se pueden leer fácilmente.

De esta manera se vuelve vulnerable todo el intercambio de información al no tener un cifrado o código para que el atacante no entienda qué se está transmitiendo.

26 of 54

El Cifrado WEB

Cifrado (no encriptado): Es el proceso que transforma la información y se realiza con base a un elemento único conocido como clave, así sólo el poseedor puede leerla.

Clave pública y clave privada (RSA): Son un par de “claves” digitales asociadas a una persona o entidad y generadas mediante métodos criptográficos. La pública es usada para cifrar la información, mientras que la clave privada se usa para descifrar.

27 of 54

El Cifrado WEB

Firma digital: Es un elemento que identifica y distingue. La firma digital se genera con base a la clave privada de quien firma y por lo tanto es “única”.

Autoridad Certificadora (AC): Es una entidad confiable que se encarga de garantizar que el poseedor de un certificado digital sea quien dice ser, brindando confianza a ambas partes de una comunicación segura SSL/TLS.

28 of 54

El Cifrado WEB

Certificado Digital SSL/TLS: Documento digital que garantiza vinculación entre una persona o entidad con su clave pública. Contiene: nombre, dirección, email, organización y clave pública, e información propia: periodo de validez, número de serie, nombre de la AC que emitió, firma digital de la AC cifrada con su clave privada y más…

HTTPS: Es una combinación del protocolo HTTP con el protocolo SSL/TLS para establecer comunicaciones cifradas en sitios web.

29 of 54

SSL - TLS

SSL (Secure Sockets Layer): Protocolo que hace uso de certificados digitales para comunicaciones seguras. Recientemente sustituido por TLS (Transport Layer Security) el cual está basado en SSL. Es utilizado en bancos, tiendas on- line y cualquier tipo de servicio que requiera el envío de datos personales o contraseñas.

No todos los sitios web lo usan. SSL Protege los datos que viajan desde el cliente al servidor, no así los datos persistentes almacenados en una base de datos.

30 of 54

El Cifrado WEB

31 of 54

El Cifrado WEB

Verificación de validez del certificado: Una vez que el navegador tiene el certificado, realiza algunas verificaciones:

  • Integridad del certificado: Verifica que se encuentre íntegro, esto lo hace descifrando la firma digital incluida en él mediante la clave pública de la AC.

  • Vigencia del certificado: Revisa el periodo de validez.

  • Verifica emisor del certificado: Hace uso de una lista de Certificados Raíz almacenados en tu computadora que contienen las claves públicas de las ACs conocidas

32 of 54

SDKs de autenticación

33 of 54

Autorización OAuth

OAuth es un protocolo que define la forma de obtener un código de acceso (token) para ser utilizado en una aplicación.

Las aplicaciones “delegan” esta tarea a un servidor de autorización, que, a su vez, puede ser utilizado por otras aplicaciones.

34 of 54

OAuth en aplicaciones de terceros

OAuth permite a un usuario del sitio A compartir su información en el sitio A (proveedor de servicio) con el sitio B (llamado consumidor) sin compartir toda su identidad.

35 of 54

Plataformas de autenticación

https://firebase-php.readthedocs.io/en/latest/overview.html#

36 of 54

Top 10 de Amenazas - OWASP

37 of 54

Top 10 de Amenazas - OWASP

38 of 54

A1 - Inyección SQL

Las fallas de inyección ocurren cuando datos no confiables son enviados a un intérprete como parte de un comando o consulta.

Instrucción SQL vulnerable:

String query = "SELECT * FROM account WHERE user = '" + userName + "';"

Ingreso: Pepe

39 of 54

A1 - Inyección

Al modificar el parámetro ‘userName’ y enviar, por ejemplo:

Pepe'; DROP TABLE user; SELECT * FROM account WHERE name LIKE '%"

SELECT * FROM account WHERE user =’Pepe';

DROP TABLE user;

SELECT * FROM account WHERE name LIKE '%"

40 of 54

A1 - Inyección

Medidas a tomar

Escapar los caracteres especiales utilizados en las consultas SQL

En PHP podemos usar la función mysql_real_scape_string(), que la modifica evitando todos los caracteres especiales

Delimitar los valores de las consultas:

Es aconsejable delimitarlo siempre entre comillas simples.

SELECT nombre FROM usuarios WHERE id_user = $id

Será más fácilmente inyectable que:

SELECT nombre FROM usuarios WHERE id_user = ‘$id’

Donde $id es un número entero.

41 of 54

A1 - Inyección

#Con el usuario y la contraseña que mandamos se haría esta consulta:SELECT * FROM usuarios WHERE usuario = ‘$usuario’ and password = ‘$pass’;

#En este ejemplo vemos el resultado de consulta normalSELECT * FROM usuarios WHERE usuario = ‘pepe’ and password = ‘12345’;

#Pero, ¿qué ocurriría si un atacante en el campo “password” agregara “’ OR ‘1’ = ‘1”? Es decir:

SELECT * FROM usuarios WHERE usuario=‘pepe’ and password=‘12345’ OR ‘1’ = ‘1’;

#PHP

SELECT * FROM usuarios WHERE usuario='".mysql_real_escape_string($usuario)."' AND password='".mysql_real_escape_string($pass)."'

42 of 54

A1 - Inyección

Verificar siempre los datos que introduce el usuario

  • Si en una consulta esperamos un entero, no confiemos en que será así.
  • En PHP ctype_digit() para saber si es un número o ctype_alpha() para saber si se trata de una cadena de texto.

Asignar mínimos privilegios al usuario que conectará con la base de datos

El usuario que utilicemos para conectarnos a la base de datos desde nuestro código debe tener los privilegios justos para realizar las acciones que necesitemos

Programar bien

43 of 54

A1 - Inyección

SQLiHelper 2.7 SQL Injection: Una vez indicada la url que queremos analizar, la aplicación realizará peticiones inyectando código SQL con el fin de comprobar si es realmente vulnerable.

Pangolin: Se trata de una herramienta de pago que está destinada a descubrir vulnerabilidades tanto del tipo inyección SQL como inyección SQL ciego.

SQLMap: Se trata de una herramienta de pruebas de código abierto que automatiza el proceso de detectar y explorar los errores de inyección SQL

44 of 54

A2 - Pérdida de autenticación y gestión de sesiones

Funciones implementadas incorrectamente, permiten a los atacantes acceder a contraseñas, claves, token de sesiones...

Escenarios más frecuentes:

  1. Aplicación que soporta reescritura de URL poniendo los ID de sesión en la propia dirección.
  2. No se establecen correctamente los tiempos de expiración de la sesión en la aplicación.
  3. Un atacante consigue acceder a la base de datos de contraseñas del sistema. Las contraseñas de los usuarios no se encuentran cifradas.

45 of 54

A2 - Pérdida de autenticación y gestión de Sesiones

46 of 54

A4 - Referencia directa insegura a objetos

Ocurre cuando un desarrollador expone una referencia a un objeto de implementación interno, tal como un archivo, directorio, o base de datos.

47 of 54

A5 - Configuración de seguridad incorrecta

Debe haber una configuración segura para la aplicación, servidor de aplicación, servidor web, base de datos y plataforma.

  1. La consola de administrador del servidor de aplicaciones se instaló automáticamente y no se ha eliminado. Las cuentas por defecto no se han modificado.
  2. El listado de directorios está habilitado en su servidor. El atacante descubre que puede listar directorios para encontrar cualquier archivo
  3. La configuración del servidor de aplicaciones permite que se retornen la pila de llamada a los usuarios, exponiéndose potencialmente a fallos subyacentes.
  4. El servidor de aplicaciones viene con aplicaciones de ejemplo que no se eliminaron pueden poseer fallos de seguridad bien conocidos.
  5. Dejar las claves por defecto que están configuradas.

48 of 54

A6 - Exposición de datos sensibles

No se protegen datos como números de tarjetas de crédito. Estos requieren cifrado.

  1. Una aplicación cifra los números de tarjetas de crédito en una base de datos utilizando cifrado automático. Esto significa que también se descifran estos datos automáticamente cuando se recuperan. El sistema debería cifrar dichos número usando una clave pública, y permitir solamente a las aplicaciones de back-end descifrarlo con la clave privada.

  • Un sitio no utiliza SSL para todas sus páginas que requieren autenticación. El atacante obtiene la cookie de sesión del usuario y secuestra la sesión, accediendo los datos privados del usuario.

49 of 54

A7 - Ausencia de control de acceso a funciones

Las aplicaciones necesitan verificar el control de acceso en el servidor cuando se accede a cada función.

El atacante simplemente fuerza la navegación hacia las URLs objetivo.

http://example.com/app/getappInfo

http://example.com/app/admin_getappInfo

Si un usuario no autenticado puede acceder a ambas páginas, eso es una vulnerabilidad. Si un usuario autenticado, no administrador, puede acceder a “admin_getappInfo”, también es una vulnerabilidad.

50 of 54

A8 - Falsificación de peticiones de sitios cruzados (CSRF)

Obliga al navegador de una víctima autenticada a enviar una petición HTTP falsificada, incluyendo la sesión del usuario y cualquier otra información de autenticación a una aplicación web vulnerable.

51 of 54

A9 - Utilización de componentes con vulnerabilidades conocidas

Librerías, frameworks y otros módulos de software casi siempre funcionan con todos los privilegios.

Si se ataca un componente vulnerable podría facilitar la intrusión en el servidor o una pérdida seria de datos.

52 of 54

A10 - Redirecciones y reenvíos no validados

Las aplicaciones web frecuentemente redirigen y reenvían a los usuarios hacia otras páginas o sitios web, sin una validación apropiada, los atacantes pueden redirigir a las víctimas hacia sitios de phishing o malware

1. La aplicación tiene una página llamada “redirect.jsp” que recibe un único parámetro llamado “url”. El atacante compone una URL que redirige a una aplicación que realiza phishing e instala código malicioso.

2. La aplicación utiliza reenvíos para redirigir peticiones entre distintas partes de la aplicación.

53 of 54

Conclusiones

Cuidado con el uso indebido de la seguridad principalmente cuando trabajan con datos sensibles o cuando la organización se expone mediante la red a ataques maliciosos.

Trade-off seguridad performance

54 of 54

Referencias