SEGURIDAD EN SERVIDORES WEB PEZZENTE, ARMANDO SAJAMA, EMANUEL

WEB Red informática mundial es un sistema de distribución de información basado en hipertexto o híper medios enlazados y accesibles a través de Internet. Con un navegador, un usuario visualiza sitios Web compuestos de páginas Web que pueden contener texto, imágenes, vídeos u otros contenidos multimedia, y navega a través de ellas usando hiperenlaces.

Servidor web Un Servidor es una computadora que forma parte de la red y provee servicios a otras computadoras denominadas clientes. Un Servidor Web es un programa diseñado para alojar y transferir paginas web. Estos servidores se mantienen a la espera de peticiones de clientes.

Tipos de servidores Servidores Web Servidores de Correo Servidores de Archivos (FTP) Servidores de Chat Servidores de Bases de Datos Servidores Proxy

HTTPS (protocolo seguro de transferencia de hipertexto) El sistema HTTPS utiliza un cifrado basado en SSL/TLS (protocolos criptográficos) para crear un canal cifrado (cuyo nivel de cifrado depende del servidor remoto y del navegador utilizado por el cliente) más apropiado para el tráfico de información sensible que el protocolo HTTP. De este modo se consigue que la información sensible no pueda ser usada por un atacante que haya conseguido interceptar la transferencia de datos de la conexión, ya que lo único que obtendrá será un flujo de datos cifrados que le resultará imposible de descifrar. El puerto estándar para este protocolo es el 443.

Conceptos básicos Ataques Scripts Consiste en aprovechar alguna debilidad o vulnerabilidad en el software, en el hardware, e incluso en las personas que forman parte de un ambiente informático, a fin de obtener un beneficio, causando un efecto negativo en la seguridad del sistema . Scripts Son un conjunto de instrucciones generalmente almacenadas en un archivo de texto que deben ser interpretados línea a línea en tiempo real para su ejecución, estos se distinguen de los programas ya que deben ser convertidos a un archivo binario ejecutable. Los scripts pueden estar embebidos en otro lenguaje para aumentar sus funcionalidades, como es el caso de los scripts PHP o Java scripts en código HTML.

Conceptos básicos Cookie: es una pequeña información enviada por un sitio web y almacenada en el navegador del usuario, de manera que el sitio web puede consultar la actividad previa del usuario. Sus principales funciones son: Llevar el control de usuarios: cuando un usuario introduce su nombre de usuario y contraseña, se almacena una cookie para que no tenga que estar introduciéndolas para cada página del servidor. Sin embargo, una cookie no identifica a una persona, sino a una combinación de servidor-navegador-usuario. Conseguir información sobre los hábitos de navegación del usuario, e intentos de spyware (programas espía), por parte de agencias de publicidad y otros. Esto puede causar problemas de privacidad y es una de las razones por la que las cookies tienen sus detractores.

Tipos de ataques Ataques Pasivos Ataques Activos El pirata informático no modifica ningún tipo de información sino que escucha o ve la información que se encuentra en el servidor. La mayor ventaja de este ataque es que casi no deja huella, ya que al no provocar ninguna alteración de información es difícil de detectar. Ataques Activos Se dedican a modificar de alguna manera la información o a los paquetes enviados Ataques a Nivel de Sistema Consiste en atacar directamente el sistema operativo del servidor intentando obtener privilegios de administrador mediante un terminal remota.

Tipos de ataques Ataques a Nivel Aplicación Spoofing Se basa en intentar modificar los datos que nos permita la aplicación atacada sin ejecutar código en el sistema operativo Spoofing Consiste en suplantar la identidad de otra maquina de la red para tener acceso a los recursos de un tercer sistema de manera maliciosa, basándose en algún tipo de confianza ya sea el nombre o la dirección IP. Una de las técnicas más típicas del spoofing es el phising.

Ataques más comunes a servidores Inyección SQL XSS Pérdida de Autenticación y Gestion de Sesiones Referencia Directa Insegura a Objetos CSRF

Ataques más comunes a servidores Defectuosa Configuración de Seguridad Almacenamiento Criptográfico Inseguro Buffer Overflow Falla de Restricción de Acceso a URL Pretección Insuficiente en la Capa de Transporte Redirecciones y reenvíos no validos

Inyección SQL SQL es un lenguaje textual utilizado para interactuar con bases de datos relacionales. En los servidores Web se utiliza este lenguaje para acceder a bases de datos y ofrecer páginas dinámicas o nuevas funcionalidades a los sistemas.

Inyección SQL Es una vulnerabilidad que afecta a los sitios web que dependen de bases de datos relacionadas a aplicaciones a nivel de base de datos. Envía instrucciones adicionales a partir de parámetros de entrada ingresados por el usuario como una consulta de SQL.

Inyección SQL - Ejemplo

Inyección SQL - Ejemplo Ingresar como administrador

Inyección SQL - Peligros Le permite al atacante: Saltar restricciones de acceso Elevar privilegios de Usuario Obtener base de datos completa (SELECT) Modificar información (INSERT) Destruir parte o la totalidad de la base de datos (DELETE) Ejecutar comandos del sistema dentro del servidor Apagado remoto del servidor (Denegación de Servicio DoS)

Inyección SQL - Prevención Variables de alcance: Es la más poderosa protección contra el SQL Injection. Imposibilita la concatenación de instrucciones SQL donde puedan aplicarse variables en las instrucciones anexadas. Validación de la entrada: Validación fuerte en el lado del servidor para entrada de usuario. Validación de datos para filtrar la entrada del usuario de caracteres SQL. Verificar tanto el tamaño como el tipo de los datos y sintaxis de las entradas de usuario.

Inyección SQL - Prevención Verifique el formato de los datos de entrada y, en particular, si hay caracteres especiales No deje que se vean mensajes de error explícitos que muestren la consulta o parte de la consulta de SQL Elimine las cuentas de usuario que no se usen y especialmente las predeterminadas No acepte cuentas sin contraseñas; Mantenga al mínimo los privilegios de las cuentas que se usan Elimine los procedimientos almacenados

Cross Site Scripting (XSS) Consiste en inyectar en páginas Web código JavaScript (o lenguaje script similar), evitando medidas de control. Es posible encontrar una vulnerabilidad XSS en aplicaciones que tenga entre sus funciones presentar la información en un navegador Web. Puede haber aplicaciones locales vulnerables a XSS.

Cross Site Scripting (XSS)

XSS – Tipos Directa (también llamada Persistente): Es comúnmente filtrado. Consiste en embeber código HTML peligroso en sitios que lo permitan. Incluye etiquetas como <script> o <iframe>. Funciona localizando puntos débiles en la programación de los filtros de HTML si es que existen, para publicar contenido Indirecta (también llamada Reflejada): Modificar valores que la aplicación Web utiliza para pasar variables entre dos páginas, sin usar sesiones. Sucede cuando hay un mensaje o una ruta en la URL del navegador, en una cookie, programas en Flash, un enlace malicioso e incluso vídeos o cualquier otra cabecera HTTP.

XSS – Tipos Variante del tipo Directa - Ejemplo del tipo LOCAL

XSS – Tipos Ejemplo del tipo Indirecto

XXS – Robo de Cookies Mediante esta técnica se puede robar sesiones de una manera bastante sencilla. Bastaría con realizar un script que llamase a una página alojada en nuestro servidor pasándole la cookie. Este Script se colaría en el servidor de la victima aprovechando un punto vulnerable a XSS. Cuando un usuario se ha validado en el servidor y ejecute el script se envía al servidor el contenido de la cookie. Una vez que la página obtiene la cookie (almacenándola por ejemplo en un fichero) mediante programas como Odysseus, se puede hacer una llamada al servidor pasándole la cookie original. Esta cookie es válida para robar la sesión solo mientras el usuario no cierre la sesión.

Diseño de aplicaciones XSS – Prevención Diseño de aplicaciones Validar todas las entradas de formularios: Se debe verificar que el tipo de datos y la longitud de cada campo se corresponda con lo esperado. Se deberá filtrar caracteres especiales que puedan resultar peligrosos. Se deben programar las aplicaciones web, filtrando determinados comandos. En general en los ataques XSS son usadas etiquetas como SCRIPT, OBJECT, APPLET, EMBED y FORM. Envío de mensajes de alerta intimidatorios, cuando se detecte que un usuario de la aplicación intente un posible ataque.

Navegadores del lado cliente XSS – Prevención Navegadores del lado cliente Otra contramedida, que ayuda a mitigar los ataques XSS, evitando que los usuarios sean víctimas de ellos, es el uso de las versiones más recientes de navegadores web. A partir de Internet Explorer 8, cuando se intenta acceder a una página web que ha sido víctima de un ataque XSS, aparece un mensaje que avisa de que la página web ha sido modificada, para proteger al usuario de un posible ataque. Esto es debido a que el filtro Anti XSS de Internet Explorer ha detectado la manipulación de la página mediante la inyección de código en un parámetro.

Pérdida de Autenticación y Gestion de Sesiones Permiten a un atacante suplantar la información de un determinado usuario, pudiendo llegar a obtener una cuenta de administración que le permita sabotear los controles de autorización y registro de la aplicación. Esta situación podría ocasionar un acceso no autorizado a cualquier tipo de información que se encuentre almacenada en el servidor o los servicios que han sido comprometidos. Existe una multitud de situaciones en las que nos podemos encontrar ante una aplicación vulnerable a este tipo de ataque, pero la mayor parte de las veces se encuentran en la gestión de las contraseñas, la expiración de sesiones o el proceso de cierre de sesión. Además, debe prestarse especial atención a las procesos que permiten la recuperación de los valores del usuario de forma automática como pueden ser los servicios de pregunta secreta, de actualización de cuenta o de “Recordar contraseña”.

Vulnerabilidades Las credenciales de los usuarios no están protegidas cuando se almacenan utilizando un cifrado. Se pueden adivinar o sobrescribir las credenciales a través de funciones débiles de gestión de la sesión (ej., creación de usuarios, cambio de contraseñas, recuperación de contraseñas, ID de sesión débiles). Los ID de sesión son expuestos en la URL (ej., re--‐escritura de URL). Los ID de sesión no expiran, o las sesiones de usuario o los tokens de autenticación. En particular los tokens de inicio de sesión único (SSO), no son invalidados durante el cierre de sesión. Los ID de sesiones no son rotados luego de una autenticación exitosa. Las contraseñas, ID de sesión y otras credenciales son trasmitidas a través de canales no cifrados.

Ejemplos

Ejemplos

Prevención Añadir la comunicación cifrada en el proceso de acceso a la aplicación. Eliminar, en la medida de lo posible, la utilización de mecanismos de autenticación del tipo “Recordar Contraseña” puesto que, generalmente, esta contraseña se almacena para poder ser utilizada y la sustracción de ésta valor podría ocasionar la suplantación de usuarios. Ofrecer un enlace en todas las páginas de la aplicación para que el usuario pueda cerrar la sesión. Gestionar de forma adecuada la caducidad de las sesiones ante un período de inactividad. Gestionar de forma adecuada el tratamiento de la información cuando se introduzca un identificador de sesión caducado o no válido.

Referencia Directa Insegura a Objetos Una Referencia directa insegura a objetos ocurre cuando se le permite a un atacante realizar referencia a objetos para los que no tiene autorización. Se consideran objetos a los elementos internos de la aplicación, es decir, ficheros, directorios y registros de bases de datos que utiliza nuestra aplicación para almacenar información, y que son referenciados a través de parámetros en URL’s o en formularios. Por esto último se dice que se realiza un referencia directa de ellos, porque según la información que contengan estos parámetros, se accederá a uno u otro dato.

Ejemplos

Ejemplos Otro ejemplo, podría ser la descarga de un fichero mal controlada. URL ejemplo: http://www.ej.org/descarga.php?dir=nomina&file=44444444A.pdf A partir de está URL con una pequeña modificación, se podría descargar la nómina de cualquiera. Es más, si no se lleva un buen control de servicios en el servidor, se podría descargar cualquier fichero, un ejemplo sería: URL ejemplo: http://www.ej.org/descarga.php?dir=../../../etc&file=passwd.pdf Como se puede ver, no se está haciendo ningún tipo de inyección propiamente dicho, simplemente, se modifica el parámetro a buscar, con lo cual filtrar parámetros no serviría como si funcionaba con inyección de comandos.

Prevención Para evitar este tipo de vulnerabilidades, se tiene que intentar realizar referencias a objetos de forma indirecta (sacando los datos de sesión) o acompañar las referencias directas con indirectas. Por ejemplo, en vez de utilizar la clave del recurso de base de datos, se podría utilizar una lista de 6 recursos que utilizase los números del 1 al 6 para indicar cuál es el valor elegido por el usuario. La aplicación tendría que realizar la correlación entre la referencia indirecta con la clave de la base de datos correspondiente en el servidor Verificar que todas las referencias a objetos tengan las protecciones apropiadas. Por ejemplo, verificar si el usuario está autorizado a acceder al recurso que solicita.

Cross Site Request Forgery (CSRF) Un ataque CSRF obliga al navegador de una víctima autenticada a enviar una petición HTTP falsificada. Dado que los navegadores envían credenciales como cookies con información de inicio de sesión de forma automática, los atacantes pueden crear páginas web maliciosas que generan peticiones HTTP falsificadas que son indistinguibles de las legítimas. Estas peticiones, incluyendo la sesión del usuario y cualquier otra información de autenticación, se envían a una aplicación web vulnerable. Esto permite al atacante forzar al navegador de la víctima para generar pedidos que la aplicación vulnerable piensa son peticiones legítimas provenientes de la victima.

Cross Site Request Forgery (CSRF) Los atacantes pueden cambiar cualquier dato que la víctima esté autorizada a cambiar, o a acceder a cualquier funcionalidad donde esté autorizada, incluyendo registro, cambios de estado o cierre de sesión. El atacante crea peticiones HTTP falsificadas y engaña a la victima mediante el envío de etiquetas de imágenes, XSS u otras técnicas. Si el usuario está autenticado, el ataque tiene éxito.

CSRF – Etapas

CSRF – Prevención La detección de fallos de tipo CSRF es bastante fácil a través de pruebas de penetración o de análisis de código. La prevención de CSRF requiere la inclusión de un token no predecible en cada solicitud HTTP. Estos tokens deben ser, como mínimo, únicos por cada sesión de usuario.

CSRF – Prevención Re-Autenticación o Prueba de Usuario Real Token único en campo oculto Hace que el valor de dicho campo se envíe en el cuerpo de la solicitud HTTP, evitando su inclusión en la URL que está más expuesta a posibles ataques. Token único en URL Presenta el inconveniente de que la URL sea expuesta a un ataque y se pueda comprometer al token secreto Re-Autenticación o Prueba de Usuario Real El usuario debe demostrar su intención de enviar la solicitud, ya sea a través de la re-autenticación o con cualquier otra prueba que demuestre que es un usuario real (por ejemplo un CAPTCHA)

Defectuosa Configuración de Seguridad Estas vulnerabilidades frecuentemente dan a los atacantes acceso no autorizado a algunas funcionalidades o datos del sistema (por ejemplo cuentas por defecto, páginas sin uso, fallas sin parchear, archivos y directorios sin protección, etc.) Las configuraciones de seguridad incorrectas pueden ocurrir a cualquier nivel de la aplicación, incluyendo la plataforma, servidor web, servidor de aplicación, base de datos, framework, y código personalizado.

Defectuosa Configuración de Seguridad

Defectuosa Configuración de Seguridad – Peligros Compromiso del Sistema Instalación de código malicioso Falla de XSS Acceso no autorizado con privilegios Altos costes de recuperación

Defectuosa Configuración de Seguridad – Prevención Verificar la configuración de sistemas Uso de guías de securización (tareas automatizadas) Mantener actualizadas todas las plataformas Aplicar parches en todos los componentes Analizar los efectos (entorno de prueba) Verificar la configuración de aplicación Desarrollar reportes en sus procesos Si no se puede verificar, no es seguro Fuerte arquitectura de aplicación que proporcione una separación segura y efectiva entre componentes. Verificar la implementación Un simple escaneo puede encontrar problemas de configuración genéricos y parches faltantes

Almacenamiento Criptográfico Inseguro Muchas aplicaciones web no protegen adecuadamente datos sensibles tales como números de tarjetas de crédito o credenciales de autenticación. Los atacantes pueden robar o modificar tales datos para llevar a cabo fraudes, robos de identidad u otros delitos. Los datos sensibles requieren de métodos de protección adicionales tales como el cifrado de datos, así como también de precauciones especiales en un intercambio de datos con el navegador. Los atacantes no quiebran la criptografía de forma directa, sino que la amenaza consiste en algo más como robar claves, realizar ataques “man in the middle”, robar datos del servidor mientras se encuentran en tránsito, o directamente del navegador del usuario.

Almacenamiento Criptográfico Inseguro

Almacenamiento Criptográfico Inseguro – Prevención Verificar la arquitectura Identificar todos los datos sensitivos. Identificar los lugares donde estos datos son almacenados. Encriptación para contrarrestar las amenazas. Proteger la información Encriptación en ficheros, base de datos, etc. Utilizar los mecanismos correctamente Usar algoritmos públicos reconocidos. No utilizar algoritmos considerados débiles. Nunca transmitir claves privadas por canales inseguros. No almacenar información innecesaria. Verificar la implementación Llaves, certificados, y contraseñas debidamente protegidas. Métodos para distribuir las llaves seguros y efectivos. Analizar el código de encriptación.

Buffer Overflow Es una falla que se da por una incorrecta validación de los datos de entrada, permitiendo así copiar en una porción de memoria reservada (buffer) más datos de los que puede almacenar. Si dicha cantidad es superior a la capacidad pre asignada, los bytes excedentes se almacenan en zonas de memoria adyacentes, sobrescribiendo su contenido original, que probablemente pertenecían a datos o a código almacenados en memoria.

Buffer Overflow Si para una variable local se le reservan 10 bytes, y luego se copian más de 10 bytes, puede suceder que pisemos la dirección de retorno. Modificando esa dirección de retorno de manera inteligente podemos ir a cualquier punto determinado del programa o incluso ejecutar un programa puesto por nosotros en memoria (código malicioso).

Buffer Overflow – Peligros Los bytes que desbordan el buffer podrían grabarse donde antes había instrucciones. Esto implicaría la posibilidad de controlar el flujo del programa, llevándole a realizar operaciones imprevistas por el programador original, o a ejecutar código malicioso. El resultado es la capacidad de saltarse las limitaciones de seguridad habituales y conseguir cierto nivel de control sobre el sistema, o provocar la caída del mismo.

Buffer Overflow – Esquema

Buffer Overflow – Esquema

Buffer Overflow – Prevención Usar lenguajes seguros Usar librerías de funciones seguras Auditoría del código para evitar desbordamientos Prevenir que se ejecute código en el buffer Usar compiladores que adviertan el uso de funciones no seguras Instalar librerías de seguridad

Falla de Restricción de Acceso a URL Este tipo de ataques es una falla de administración de la autorización y la autenticación, más que de programación. Se sabe que en una página web existen dos ámbitos principalmente, el público y el privado, pero en muchas ocasiones, dentro del ámbito privado, existen diferentes niveles de acceso según el usuario que esta navegando en ese momento. Existen zonas a las que solo tendría que tener acceso un administrador del portal, zonas a las que solo tendría que tener acceso determinado grupo de trabajadores pero no otro, etc… Lamentablemente, en muchas ocasiones, estos controles de acceso están mal gestionados, y aunque un usuario básico no tenga ningún enlace a una zona restringida o lo tenga deshabilitado, si escribe directamente la dirección en la barra del navegador podrá acceder sin problemas.

Ejemplo

Prevención Verificar que el acceso a cada página con o sin sesiones autenticadas es el correcto. Controles de autorización deben funcionar adecuadamente. La implementación del mecanismo debería negar todo acceso por defecto, requiriendo el establecimiento explícito de permisos a usuarios y roles específicos por cada página. Si la pagina forma parte de un proceso de varios pasos, verifique que las condiciones de la misma se encuentren en el estado apropiado para permitir el acceso.

Pretección Insuficiente en la Capa de Transporte La vulnerabilidad consiste en la falta de protección de los datos que circulan por esta capa de transporte que son susceptibles de ser interceptados. Estos datos pueden ir en texto plano o cifrados, por ejemplo con SSL. En caso de ir cifrados no habría ningún problema, ya que, en caso de que alguien los intercepte, no podría leerlos, pero el problema viene cuando estos datos viajan en texto plano. En este momento, un atacante que esté capturando nuestro tráfico podrá tener acceso a múltiple datos sensibles, datos bancarios, tokens de sesión, rutas del sistemas, datos de usuarios, etc…

Ejemplo

Prevención Que toda página sensible requiera acceso SSL, en caso de intentar una petición sin SSL, forzarla. Activar el atributo “secure” de las cookies para que el navegador no las mande en texto plano. Si se está usando SSL, preocuparse de que el cifrado aplicado sea lo suficientemente fuerte. Conexiones cifradas entre front-end y back-end, aunque no sea SSL.

Redirecciones y reenvíos no validos Las páginas web frecuentemente redirigen y reenvían a los usuarios hacia otras páginas o sitios web, y utilizan datos no confiables para determinar la pagina de destino. Sin una validación apropiada, los atacantes pueden redirigir a las victimas hacia sitios de phishing o malware, o utilizar reenvíos para acceder a páginas no autorizadas.

Ejemplo

Ejemplo No es difícil encontrar una aplicación que en determinadas ocasiones, por necesidad de la propia aplicación se realice una redirección legítima a través de un valor obtenido por un parámetro. Un ejemplo sería algo como: http://www.example.org/redirigir.php?url=phishing.org Esta página recogería el parámetro y haría una redirección a URL recibida. Pues que nuestra aplicación estaría redirigiendo a una URL ilegítima con las posibles consecuencias de sufrir un ataque de phishing.

Prevención Adoptar metodologías de revisión de Código, Scanner, Pen Texting, etc. Se deben utilizar los datos de los clientes para la validación correcta del redireccionamiento de hacia donde se enviará al usuario. Hacer una revisión de código para encontrar y comprobar la validación de todas las redirecciones que permitan introducir URL’s completas. Toda redirección realizada  a partir de un parámetro tendría que ser validada previamente comprobando que dicha redirección se va a realizar a un destino válido y confiable.

¡¡Gracias!! ¿Preguntas?

Preguntas de evaluación ¿Qué son las cookies y cuáles son sus funciones? ¿Cuáles son los tipos de ataques a servidores web? ¿En qué consiste Inyección SQL? ¿Cuáles son las prevenciones frente al ataque perdida de autenticación y gestión de sesión?