SEGURIDAD EN

SERVIDORES WEB

PEZZENTE, ARMANDOSAJAMA, 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

•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 ataquesAtaques Pasivos

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

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.

XSS – Prevención

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.

Diseño de aplicaciones

XSS – Prevención

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.

Navegadores del lado cliente

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

URL ejemplo: http://www.ej.org/descarga.php?dir=../../../etc&file=passwd.pdf

URL ejemplo: http://www.ej.org/descarga.php?dir=nomina&file=44444444A.pdf

Otro ejemplo, podría ser la descarga de un fichero mal controlada.

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:

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• 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 campo oculto

• Presenta el inconveniente de que la URL sea expuesta a un ataque y se pueda comprometer al token secreto

Token único en URL

• 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)

Re-Autenticación o Prueba de Usuario Real

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

• 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

sistemas

• 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 configuración de

aplicación

• Un simple escaneo puede encontrar problemas de configuración genéricos y parches faltantes

Verificar la implementación

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• Identificar todos los datos sensitivos.• Identificar los lugares donde estos datos son

almacenados.• Encriptación para contrarrestar las amenazas.

Verificar la arquitectura

• Encriptación en ficheros, base de datos, etc.Proteger la información

• Usar algoritmos públicos reconocidos.• No utilizar algoritmos considerados débiles.• Nunca transmitir claves privadas por canales

inseguros.• No almacenar información innecesaria.

Utilizar los mecanismos

correctamente

• Llaves, certificados, y contraseñas debidamente protegidas.

• Métodos para distribuir las llaves seguros y efectivos.

• Analizar el código de encriptación.

Verificar la implementació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 cualquierpunto determinado del programa o incluso ejecutar un programa puesto por nosotros en memoria (códigomalicioso).

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?