seguridad en servidores web pezzente, armando sajama, emanuel
TRANSCRIPT
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?