SEGURIDAD EN APLICACIONES WEB Autor: Carlos Alberto

SEGURIDAD EN APLICACIONES WEB
Autor: Carlos Alberto Amaya Tarazona
Ingeniero de Sistemas
Magister en Software Libre y Administración de Redes y sistemas Operativos
1
CONTENIDO
Pág
INTRODUCCIÓN:
UNIDAD I: INTRODUCCIÓN A LA SEGURIDAD EN APLICACIONES WEB
CAPITULO 1: CONCEPTOS BÁSICOS DE SEGURIDAD EN
APLICACIONES WEB
5
10
10
Lección 1: INTRODUCCIÓN AL PROTOCOLO HTTP
10
1.1 Características y Funcionamiento
1.2 Análisis de una cabecera HTTP
1.3 Métodos HTTP
1.4 Codificación de la Información
10
14
15
17
Lección 2: VULNERABILIDADES EN APLICACIONES WEB
18
2.1 Como trabajan las aplicaciones web
2.2 Arquitecturas más complejas
2.3 Proyecto OWASP y las Vulnerabilidades en Aplicaciones Webs
2.4 Sniffeo y codificación de cabeceras
2.5 Inyectando código
2.6 CR/LF Injections
2.7 XSS y SQL Injections
2.8 PHP Injections
2.9 Banner Grabbing
2.10 HTTP Fingerprinting
18
19
21
23
24
24
25
26
27
28
Lección 3: HERRAMIENTAS PARA LA DETECCIÓN DE VULNERABILIDADES 31
3.1 Fiabilidad de los Analizadores Automáticos de Vulnerabilidades
31
3.2 Ventajas y Beneficios
32
3.3 Inconvenientes y Desventajas
33
3.4 Criterios de valoración para herramientas de seguridad web
34
3.4.1 Herramientas Comerciales
35
3.4.2 Herramientas de Código abierto
35
3.4.3 Herramientas de auditoría aplicadas a SQL Injection
35
3.4.4 Herramientas de auditoría aplicadas a XSS (Ataques de Cross-Site Scripting)
Lección 4: MITOS EN LA SEGURIDAD WEB
39
4.1 Auditoría y control de vulnerabilidades
4.2 Puntos débiles
4.3 Tipos de Escaners
41
41
42
Lección 5: SISTEMA DE LOGS
42
5.1 Formato del fichero de LOG
5.2 Análisis del fichero de LOG
43
43
2
5.3 Programas de análisis de LOGS
44
CAPITULO 2: PROTOCOLOS DE SEGURIDAD PARA APLICACIONES WEB 44
Lección 6: TIPOS DE ANÁLISIS
44
6.1 Metodologías de análisis de seguridad web
45
Lección 7: ESCALACION DE PRIVILEGIOS EN APLICACIONES WEB
45
Lección 8: AUTENTICACIÓN Y AUTORIZACIÓN
49
8.1 La Autenticación
8.2 La Autorización
49
51
Lección 9: EJECUCIÓN DE INSTRUCCIONES DE ACCESO
51
9.1 Codificación y las validaciones de Entrada / Salida
9.2 Gestión de sesiones y usuarios
9.3 Gestión de errores y excepciones
52
52
53
Lección 10: CONFIGURACIÓN SEGURA DE SERVIDORES
54
10.1 Organización del servidor Web
10.2 Organización de las aplicaciones Web
54
55
CAPITULO3: DESARROLLO SEGURO DE APLICACIONES
56
Lección 11: CONCEPTOS GENERALES PARA EL DESARROLLO SEGURO
DE APLICACIONES
56
11.1 Normas básicas de seguridad
58
Lección 12: CONTROLES DE AUTORIZACION DE OBJETOS
60
12.1 Listas de control de acceso (ACL)
12.1.1 Configuración de las ACL
12.1.2 Funciones de la ACL
62
63
63
Lección 13: CONSIDERACIONES DE SEGURIDAD EN WEB SERVICES
63
13.1 Exposición de datos
13.2 Páginas privadas y los sistemas de autenticación
13.3 Ataques de fuerza bruta
13.4 Espionaje de contraseñas (Password sniffing)
13.5 Registros persistentes
64
64
64
65
66
Lección 14: VALIDACIÓN DE ENTRADAS
66
3
Lección 15: SQL INJECTION
15.1 Variantes de sintaxis
15.2 Otras clases de Inyección
68
68
69
LISTADO DE FIGURAS
Pág
Figura 1: Niveles superiores de OSI. Origen de vulnerabilidades en sitios
web
Figura 2: Tecnologías y protocolos de red modelo OSI
Figura 3: Operaciones de solicitud – respuesta con HTTP
Figura 4: Análisis de cabeceras HTTP
Figura 5: Niveles de comunicación en aplicaciones web
Figura 6: Arquitectura de cuatro capas en aplicaciones web
Figura 7: OWSP Top 10 – 2013
Figura 8: Banner detección FTP
Figura 9: Banner grabbing por método HEAD
Figura 10: Uso de un “Escucha de Red” para hallar huellas identificativas
de un host en la red Ethernet
Figura 11: Uso de un “Escucha de Red” para hallar huellas identificativas
de un host remoto
Figura 12: Funciones de auditoría en escáneres de aplicaciones web.
Herramientas comerciales
Figura 13: de auditoría en escáneres de aplicaciones web.
Herramientas de código
Figura 14: Funciones de auditoría en escáneres de aplicaciones
web para SQL Injection
Figura 15: Funciones de auditoría en escáneres de aplicaciones
web para XSS
Figura 16: Categoría de Vulnerabilidades
Figura 17: Formato de fichero de Logs
Figura 18: Metodología de desarrollo seguro
Figura 19: Filtrado de paquetes con ACL
Figura 20: Formulario de validación de datos
4
9
11
13
15
19
21
23
29
29
30
31
36
37
38
40
41
44
59
64
72
INTRODUCCIÓN
Tanto el auge de internet , las Telecomunicaciones, el mundo digital y todo lo que
engloba el manejo de datos, han tenido un crecimiento significativo , exponencial y
paralelos a las temáticas que tienen que ver con la privacidad formación tanto
personal como profesional. En la web encontramos funcionando a tiendas en línea,
redes sociales, negocios que mueven grandes cantidades de dinero, redes de los
servicios que habilitan el comercio a nivel internacional que contienen información
muy delicada de la vida privada de sus miembros.
Para dar inicio a este universo de la privacidad y seguridad de la información que
en la web viaja, el presente contenido académico hace relevancia a la necesidad de
implementar procedimientos seguros cuando se desarrollan aplicaciones web para
compartir y publicar información pueden haber muchos puntos de vista pero uno de
los más más críticos de la seguridad del Internet, lo tienen las piezas que intervienen
de forma directa con las masas de usuarios, los servidores web.
Para poder abordar el siguiente contenido académico, es necesario tener como
base muchos de los conceptos de seguridad abordados en redes de
telecomunicaciones, sistemas operativos e informática forense. Es por ello que el
tema de seguridad se debe asimilar como un engranaje en el que intervienen
muchas áreas y técnicas cuando se trata de proteger la integridad de la información
y la privacidad de los datos de los usuarios.-
El contenido que a continuación se presenta aborda los conceptos y mecanismos
fundamentales para la detección de vulnerabilidades en aplicaciones web, en las
que primero se incluyen temáticas básicas introductorias pero específicas al diseño
de aplicaciones web seguras, para luego tratar con los protocolos de seguridad más
usados en aplicaciones web.
Las áreas críticas del diseño de aplicaciones web demostrarán que van desde la
misma infraestructura en telecomunicaciones, el entorno de implementación, hasta
el código c y los lenguajes de programación usados para la puesta en marcha de
las aplicaciones web. Todo es parte de un ciclo de vida de desarrollo web pero
teniendo en cuanta aspectos de seguridad que protegen la forma y el fondo de las
aplicaciones.- No se trata de diseñar y de implementar aplicaciones que solo den
una buena imagen y gusto al cliente, sino también aspectos de seguridad que
minimicen el riesgo de pérdida de información o de manipulación de la misma.
5
En cuanto a la utilidad práctica de estos contenidos, alcanza a llevar a que el
estudiante sea competente en la identificación de diseños inseguros en aplicaciones
web y que lo lleve a proponer mejoras o planes de contingencia que reduzcan el
riesgo. El módulo, no pretende conceptualizar ni ejercitar al estudiante en el proceso
de implementación de servidores web o soluciones tipo LAMP1, ó WAMP2, ni
ahondarnos en el desarrollo web, que deben ser competencias previas como
presaberes a estos contenidos. Tampoco es posible llegar a la práctica o
demostración de cada herramienta que detecte vulnerabilidades o demostrar cada
riesgo. Estos son aspectos Técnicos que se aplican de forma operativa y el curso
entiéndase tiene un carácter académico investigativo que lleva al estudiante a
formular diseños propios, soluciones y análisis de todas las herramientas y que lo
lleven a detectar vulnerabilidades y controlarlas. Durante el desarrollo del aula, se
ejercitarán prácticas que en lo posible toquen cada tema expuesto en los contenidos
de este módulo.
Finalmente el contenido de este módulo, se encuentra referenciado y apoyado al
proyecto OWASP (The Open Web Application Security Project),3 como un grupo
de expertos en temas de desarrollo y seguridad con las intenciones de plantear
proyectos que a su vez trabajaran en temas de seguridad de aplicaciones, buenas
prácticas para desarrollo seguro, pruebas de seguridad para software entre otros.
Muchas referencias, actividades y experiencias en la temática de aplicaciones web,
están apoyadas en este proyecto.
1
Disponible en internet desde <http://www.lamphowto.com/>
Disponible en internet desde <http://www.wampserver.com/en/>
3
Disponible en internet desde <https://www.owasp.org/index.php/Main_Page>
2
6
PRIMERA UNIDAD
INTRODUCCIÓN A LA SEGURIDAD EN APLICACIONES WEB
CAPITULO I:
1. CONCEPTOS BÁSICOS DE SEGURIDAD EN APLICACIONES WEB
El enfoque dado a los contenidos, pretende confrontar “Mitos” que se tienen cuando
se tratan vulnerabilidades de aplicaciones web. Uno de ellos es el de no contemplar
entornos y escenarios externos, topologías, otras capas del modelo OSI, protocolos
y servicios. La seguridad tiene que verse como un todo, en donde cualquier variable
puede afectar lo menos pensado. Es por ello que no solo se trata de identificar
riesgos en aplicaciones web sino también en los equipos (computadores,
servidores) que las soportan, las redes por donde viajan los datos y los servicios
que los sistemas operativos y las aplicaciones ofrecen.
Para dar inicio a este curso que trata los temas de la privacidad y seguridad de la
información que en la web viaja, el presente contenido académico hace relevancia
a la necesidad de implementar procedimientos seguros cuando se desarrollan
aplicaciones web para compartir y publicar información pueden haber muchos
puntos de vista pero uno de los más críticos de la seguridad del Internet, lo tienen
las piezas que intervienen de forma directa con las masas de usuarios, los
servidores web
No se deja a un lado la seguridad perimetral ni de la infraestructura de
telecomunicaciones, que desde las capas inferiores del modelo OSI deben
contemplar los diseñadores, programadores y administradores de sistemas, hasta
las capas superiores, pero si se enfoca este material a que el lector pueda
determinar los aspectos funcionales en diseño, arquitectura, conceptualización e
implementación de aplicaciones web que medianamente puedan ser seguras o que
estén enmarcadas en su implementación dentro de un protocolo y estándar de
funcionamiento medianamente seguro.
Respecto a los servidores web, es común escuchar sobre fallas en los sistemas de
protección de los servidores más frecuentemente utilizados:
7
Apache: Este es el más común y más utilizado en todo el mundo. Además, es
gratuito y de código abierto, así que se podría decir que corre sobre cualquier
plataforma 4
Microsoft IIS: Su proveedor es Microsoft, y como servidor de aplicaciones web ha
tenido randes avances en seguridad y en servicios. 5
Tomcat: Servidor web también llamado Jakarta Tomcat. Funciona como un
contenedor de servelets desarrollado bajo el proyecto Jakarta en la Apache
Software Foundation. Tomcat. implementa las especificaciones de los servelets y
de JavaServer Pages (JSP) de Sun Microsystems.6
Sun Java System Web Server: Este producto pertenece a la casa Sun, y suele
empalarse sobre entorno de este sistema. Sin embargo, como Apache, es
multiplataforma, y recientemente Sun ha decidido distribuirlo con licencias de código
abierto (BSD concretamente).7
Ngnix: Este es un servidor Web muy ligero y corre sobre sistemas Unix y Windows.
Se ha convertido en el 4º servidor HTTP más popular de la red y también se
distribuye bajo licencia BSD.8
Lighttp: Este servidor Web es otro de los más ligeros que hay en el mercado. Está
especialmente pensado para hacer cargas pesadas sin perder balance, utilizando
poca RAM y poca de CPU. Algunas páginas populares que lo usan son Youtube,
Wikipedia y otras que soportan gran tráfico diariamente. También es gratuito y se
distribuye bajo licencia BSD.9
O en los lenguajes de programación en los que son escritas las aplicaciones que
son ejecutadas por estos servidores. Es de reconocer, que la mayoría de los
problemas de vulnerabilidad detectados en servicios web no son provocados por
fallas intrínsecas de ninguna de estas partes, ya que una gran cantidad de los
problemas se generan por malos usos por parte de los programadores.
El material aquí abordado referencia la mayoría de los problemas de seguridad en
los sitios web que tienen su origen en los niveles superiores del modelo OSI a nivel
de aplicación (Ver figura 1) y que son el resultado de escritura defectuosa de
código, que por lo general viene motivada por aspectos de forma en los que el
diseñador le importa cómo se vea un sitio web o una aplicación y que tan llamativo
y cautivador para el cliente puedan ser, pero no se detallan aspectos de forma en
cuanto a seguridad; debemos entender que programar aplicaciones web seguras
4
Disponible en internet dese <http://httpd.apache.org/>
Disponible en internet desde <http://www.iis.net/>
6
Disponible en internet desde <http://tomcat.apache.org/>
7
Disponible en internet desde <http://docs.oracle.com/cd/E19146-01/index.html>
8
Disponible en internet desde <http://nginx.org/en/>
9
Disponible en internet desde <http://www.lighttpd.net/>
5
8
no es una tarea fácil, ya que requiere por parte del programador, no únicamente
mostrar atención en cumplir con el objetivo funcional básico de la aplicación, sino
una concepción general de los riesgos que puede correr la información contenida,
solicitada y recibida por el sistema.
No quiere decir esto que en los demás niveles no se presenten amenazas y
vulnerabilidades que afecten a los sitios web. E la Lección 25, trataremos aspectos
de seguridad en otros niveles y protocolos de la capa OSI que afectan aplicaciones
web.
Figura 1: Niveles superiores de OSI, orígenes de vulnerabilidades en sitios web
Fuente: El autor
En la figura1, se puede identificar los niveles superiores del modelo OSI donde son
típicas las vulnerabilidades en aplicaciones web.
En la actualidad, aunque existen muchos documentos, publicaciones, estudios
basados en prueba y error, comunidades de desarrollo sobre todo en código abierto
(comunidades libres), que permiten formar un criterio sobre el tema, no existen
acuerdos básicos sobre lo que se debe o no se debe hacer, y lo que en algunas
publicaciones se recomienda, en otras es atacado. Sin embargo, en lo sustancial sí
existen algunas recomendaciones que son generales y serán las que describo en
este documento junto con los ataques más comunes a aplicaciones web y las
técnicas de defensa a las inicialmente el profesional puede aplicar en primera
instancia. Es tarea del profesional que aborde estas temáticas, que defina su
9
estrategia de diseño e implementación segura de sus aplicaciones web basado
en experiencias como las que presenta este módulo y comparto.
En el contenido de este escrito, se tratan temas esenciales de seguridad que se
suelen encontrar en las aplicaciones PHP, además se remiten ejemplos y
estrategias para evitar cometer los mismos errores, si bien, la mayoría de los
problemas (sino es que todos) revisados serán para código PHP, los mismos
consejos suelen aplicar para otros lenguajes de tecnologías similares que por lo
mismo enfrentan problemas parecidos y cuya solución es la misma, sólo con las
variantes propias del lenguaje.
LECCION 1: INTRODUCCION AL PROTOCOLO HTTP:
El modelo TCP/IP cuenta con diversos protocolos en su capa de aplicación: HTTP,
SMTP y FTP son tres de los más importantes. En principio, cualquiera de ellos
puede ser utilizado para la transferencia de mensajes SOAP pero HTML es el
protocolo estándar para la web y el más usado en los servicios web XML.
En la figura 2 se observa los protocolos que actúan en las respectivas capas del
modelo OSI. Todos los protocolos presentan deficiencias en su diseño y por tanto
ofrecen de alguna forma vulnerabilidades que afectan las características de
seguridad de una aplicación web (integridad, disponibilidad, confidencialidad).
Figura 2: Tecnologías y protocolos de red modelo OSI
Fuente: El autor
10
El Protocolo de Transferencia de HiperTexto (Hypertext Transfer Protocol) es un
sencillo protocolo cliente-servidor que articula los intercambios de información entre
los clientes web y los servidores HTTP.
Es un protocolo del nivel de aplicación usado para la transferencia de información
entre sistemas, de forma clara y rápida. Este protocolo ha sido usado por el WorldWide Web desde 1990. La especificación completa del protocolo HTTP/1.0 está
recogida en el RFC 1945.10 Fue propuesto por Tim Berners-Lee, atendiendo a las
necesidades de un sistema global de distribución de información como el World
Wide Web.
El protocolo HTTP se basa en un paradigma de peticiones y respuestas. Un cliente
envía una petición en forma de método, una URI, y una versión de protocolo seguida
de los modificadores de la petición de forma parecida a un mensaje MIME,
información sobre el cliente y al final un posible contenido. El servidor contesta con
una línea de estado que incluye la versión del protocolo y un código que indica éxito
o error, seguido de la información del servidor en forma de mensaje MIME y un
posible contenido
1.1 CARACTERÍSTICAS Y FUNCIONAMIENTO
Desde el punto de vista de las comunicaciones, HTTP se establece sobre la capa
de conexión TCP/IP, y funciona de la misma forma que el resto de los servicios
comunes de entornos UNIX: un proceso servidor escucha en un puerto de
comunicaciones TCP (por defecto, el 80), y espera las solicitudes de conexión de
los clientes web. Una vez que se establece la conexión, el protocolo TCP se encarga
de mantener la comunicación y garantizar un intercambio de datos libre de errores.
HTTP se basa en sencillas operaciones de solicitud/respuesta. Un cliente establece
una conexión con un servidor y envía un mensaje con los datos de la solicitud. El
servidor responde con un mensaje similar, que contiene el estado de la operación y
su posible resultado. Todas las operaciones pueden adjuntar un objeto o recurso
sobre el que actúan; cada objeto web es identificado por su URL.
La figura 3 muestra estas sencillas operaciones de diálogo que genera HTTP
cuando se lanza una solicitud de servicio a una aplicación web.
10
Disponible en internet desde <http://www.freesoft.org/CIE/RFC/1945/index.htm>
11
Figura 3: Operaciones de solicitud - respuesta con HTTP
Fuente: El autor
Se detalla a continuación las principales características del protocolo HTTP:

Toda la comunicación entre los clientes y servidores se realiza a partir de
caracteres US-ASCII de 7 bits.

Permite la transferencia de objetos multimedia, codificando los archivos
binarios en cadenas de caracteres. El contenido de cada objeto
intercambiado está identificado por su clasificación MIME.

Existen ocho verbos que permiten que un cliente pueda dialogar con el
servidor. Los tres más utilizados son: GET, para recoger un objeto, POST,
para enviar información al servidor y HEAD, para solicitar las características
de un objeto (por ejemplo, la fecha de modificación de un documento HTML).
12

Cada operación HTTP implica una conexión con el servidor, que es liberada
al término de la misma. Es decir, en una operación se puede recoger un único
objeto. Con la versión HTTP 1.1 se ha mejorado este procedimiento,
permitiendo que una misma conexión se mantenga activa durante un cierto
periodo de tiempo de forma que sea utilizada en sucesivas transacciones.
Este mecanismo, denominado HTTP Keep Alive, es empleado por la mayoría
de los clientes y servidores modernos.

No mantiene estado. Cada petición de un cliente a un servidor no es influida
por las transacciones anteriores. El servidor trata cada petición como una
operación totalmente independiente del resto.

Cada objeto al que se aplican los verbos del protocolo está identificado a
través de un localizador uniforme de recurso (URL) único.
Cada vez que un cliente realiza una petición a un servidor, se ejecutan los siguientes
pasos:
1. Un usuario accede a una URL, seleccionando un enlace de un documento
HTML o introduciéndola directamente en el navegador.
2. El cliente web descodifica la URL, separando sus diferentes partes. Así
identifica el protocolo de acceso, la dirección DNS o IP del servidor, el puerto
(de carácter opcional; el valor por defecto es 80) y el objeto requerido del
servidor.
3. Se abre una conexión TCP/IP con el servidor, llamando al puerto TCP
correspondiente.
4. Se realiza la petición. Para ello, se envía el comando necesario (GET, POST,
HEAD,…), la dirección del objeto requerido (el contenido de la URL que sigue
a la dirección del servidor), la versión del protocolo HTTP empleada y un
conjunto variable de información, que incluye datos sobre las capacidades
del navegador, datos opcionales para el servidor, etc.
5. El servidor devuelve la respuesta al cliente. Consiste en un código de estado
y el tipo de dato MIME de la información de retorno, seguido de la propia
información.
13
6. Se cierra la conexión TCP. Si no se utiliza el modo HTTP Keep Alive, este
proceso se repite para cada acceso al servidor HTTP.
El diálogo con los servidores HTTP se establece a través de mensajes formados
por líneas de texto, cada una de las cuales contiene los diferentes comandos y
opciones del protocolo. Solo existen dos tipos de mensajes, uno para realizar
peticiones y otro para devolver la correspondiente respuesta.
1.2 ANÁLISIS DE UNA CABECERA HTTP:
Realizando una petición HEAD al sitio web www.unad.edu.co como se muestra en
la figura 4, identificaremos las cabeceras HTTP. El ejercicio se realiza desde una
sesión de consola en un sistema operativo BackTrack 5 con permisos de root y
accediendo a la web mediante una conexión ADSL sin restricciones o puertas
traseras “firewalls” configurados y sin restricción de puertos.
Figura 4: Análisis de cabeceras HTTP
Fuente: El autor
Al realizar la petición al sitio web, el servidor nos manda el código de respuesta [2]
200. Los códigos de rango 2xx indican que la operación se ha realizado con éxito,
Cache-Control: Genera las directivas que deben ser usadas por cualquier
mecanismo a lo largo de la petición/respuesta.
Connection: Indica que la conexión se cierra, no se mantiene como en keep-alive
Date: Fecha y hora actual.
Server: Indica el tipo de S.O que corre en el servidor (Vease /.0x07)
14
Content-Length: Campo que indica el tamaño del cuerpo del documento o, en
decimal, enviado al destinatario que hubiera enviado la petición.
ContenrtType: Tipo de contenido y codificación del archivo al que realizamos la
petición
Expires: Muestra la fecha en la que va caducar la cache de nuestra petición.
Set-Cookie: Es la coockie que nos envía la pagina a la que hemos realizado la
petición, en ella aparece su ID. Su fecha de expiración, sobre que directorio actúa y
el dumio desde donde se ha obtenido.
1.3 MÉTODOS HTTP:
Los métodos HTTP más comunes y los más usados son los que a continuación se
mencionan. Es importante identificarlos ya que son los más manipulados en la
aplicación en ataques y técnicas de PenTesting y de snifeo de cabeceras HTTP.
GET: Sirve para recoger cualquier tipo de información del servidor. Se utiliza
siempre que se pulsa sobre un enlace o se teclea directamente a una URL. Como
resultado, el servidor HTTP envía el documento ubicado en la dirección especificada
por dicha URL.
HEAD: Es un comando similar a GET pero que pide solamente la cabecera del
objeto. Lo utilizan principalmente los gestores de cachés de páginas o los servidores
proxy para conocer cuándo es necesario actualizar la copia que se mantiene de un
fichero.
POST: Este comando envía datos de información al servidor, normalmente
procedentes de un formulario web, para que el servidor los administre o los añada
a una base de datos.
PUT: Almacena un objeto en la URL especificada. Si la dirección de destino ya
contenía un objeto, se considera que se está enviando una versión actualizada del
mismo.
DELETE: Elimina el objeto especificado. Este comando es muy poco utilizado.
TRACE: Realiza un eco de la solicitud recibida para que el cliente pueda conocer
qué servidores intermedios están añadiendo información o modificando la petición.
OPTIONS: Devuelve los métodos HTTP que soporta el cliente. Se suele utilizar para
comprobar la funcionalidad de un servidor web.
CONNECT: Se utiliza en los servidores proxy que puedan establecer un túnel
dinámicamente (por ejemplo, un túnel SSL).
Ante cada transacción con un servidor HTTP, éste devuelve un código numérico en
la primera línea del mensaje de respuesta que informa sobre el resultado de la
operación. Estos códigos aparecen en algunos casos en la pantalla del cliente,
cuando se produce un error. Los códigos de estado están clasificados en cinco
categorías:


1xx: Mensajes informativos.
2xx: Mensajes asociados con operaciones realizadas correctamente.
15



3xx: Mensajes de redirección, que informan de operaciones complementarias
que se deben realizar para finalizar la operación.
4xx: Errores del cliente; el requerimiento contiene algún error, o no puede ser
realizado.
5xx: Errores del servidor, que no ha podido llevar a cabo una solicitud. En la
siguiente tabla podemos ver una lista con los códigos que se utilizan con
mayor frecuencia:
La tabla 1 muestra los códigos de estado más comunes en una conversación
establecida con el protocolo HTTP. Estos códigos son los que generalmente se
modifican en interceptaciones o ataques a servicios HTTP y serán parte del análisis
en los ejercicios propuestos del curso.
CODIGO
200
201
ACCION
OK
Created
202
Accepted
204
No Content
301
Moved
Pemanently
302
Found
304
Not Modified
400
401
Bad Request
Unauthorized
403
Forbidden
404
500
Not Found
Internal Server
Error
Not
Implemented
Bad Gateway
501
502
503
Service
Unavailable
DESCRIPCION
Operación realizada satisfactoriamente
La operación ha sido realizada correctamente, y como resultado se ha creado
un nuevo objeto, cuya URL de acceso se proporciona en el cuerpo de la
respuesta. Este nuevo objeto ya está disponible.
La operación ha sido realizada correctamente, y como resultado se ha creado
un nuevo objeto, cuya URL de acceso se proporciona en el cuerpo de la
respuesta. El nuevo objeto no está disponible por el momento. En el cuerpo
de la respuesta se debe informar sobre la disponibilidad de la información.
La operación ha sido aceptada, pero no ha producido ningún resultado de
interés. El cliente no deberá modificar el documento que está mostrando en
este momento.
El objeto al que se accede ha sido movido a otro lugar de forma permanente.
El servidor proporciona, además, la nueva URL en el campo Location de la
respuesta.
El objeto al que se accede ha sido movido a otro lugar de forma temporal. El
servidor proporciona, además, la nueva URL en el campo Location de la
respuesta. El cliente no debe modificar ninguna de las referencias a la URL
errónea.
Se devuelve cuando se hace un GET condicional y el documento no ha sido
modificado
La petición tiene un error de sintaxis y no es entendida por el servidor.
La petición requiere una autorización especial, que normalmente consiste en
un nombre y clave que el servidor verificará. El campo WWW-Autenticate
informa de los protocolos de autentificación aceptados para este recurso.
Está prohibido el acceso a este recurso. No es posible utilizar una clave para
modificar la protección.
La URL solicitada no existe, no está disponible o no se encuentra.
El servidor ha tenido un error interno, y no puede continuar con el
procesamiento.
El servidor no tiene capacidad, por su diseño interno, para llevar a cabo el
requerimiento del cliente.
El servidor, que está actuando como proxy o pasarela, ha encontrado un error
al acceder al recurso que había solicitado el cliente.
El servidor está actualmente deshabilitado y no es capaz de atender el
requerimiento.
Tabla 1: Códigos de estado en HTTP
Fuente: <http://www.rfc-editor.org/rfc/rfc1866.txt>
16
1.4 CODIFICACIÓN DE LA INFORMACIÓN:
Una de las características de HTTP reside en que la comunicación entre cliente y
servidor se realiza a partir de caracteres US-ASCII de 7 bits. El problema aparece
cuando deseamos realizar la transmisión de un archivo binario, cuyo contenido no
puede ser representado por este grupo tan reducido de caracteres.
Para solventar esta limitación se utiliza el estándar de Internet MIME (Extensiones
de correo de Internet multipropósito). Son una serie de convenciones o
especificaciones dirigidas a que se puedan intercambiar a través de Internet todo
tipo de archivos (texto, audio, vídeo, etc.) de forma transparente para el usuario.
Una parte importante de MIME está dedicada a mejorar las posibilidades de
transferencia de texto en distintos idiomas y alfabetos. La especificación de este
estándar se encuentra recogidas en las RFC 2045, 2046, 2047, 2048 y 2049.11
Los recursos u objetos que actúan como entrada o salida de un comando HTTP
están clasificados por su descripción MIME, que se especifica en el campo de
cabecera “Content-Type”. De esta forma, el protocolo puede intercambiar cualquier
tipo de dato sin preocuparse de su contenido. La identificación MIME permitirá que
el receptor trate adecuadamente los datos. Existen nueve tipos definidos por la
IANA:12 application, audio, example, image, message, model, multipart, text y video.
Dentro de cada tipo existen multitud de subtipos: (text/html, image/gif, image/jpeg,
audio/x-mpeg, video/quicktime…).
Existen tres métodos básicos de codificación:



11
12
7 bit: Utilizado por defecto, supone que los archivos son de texto.
Quoted-printable: Se usa para codificar texto con caracteres que excedan
de los 7 bits utilizados en US-ASCII. Con esto podremos representar
caracteres de otros alfabetos como los idiomas procedentes del latín. Se
codifica en 3 caracteres de 7 bits. Por ejemplo, la letra “ñ” se corresponderá
con los caracteres “=F1”.
Base64: Se utiliza para codificar contenido no legible por humanos, como
por ejemplo archivos multimedia. Cada 3 octetos se codifican en 4 caracteres
que pertenecen a un subconjunto de 64 caracteres imprimibles del US-ASCII.
Disponible en internet desde <http://www.ietf.org/rfc/rfc2045.txt>
Disponible en internet desde <http://www.iana.org/>
17
LECCION 2: VULNERABILIDADES EN APLICACIONES WEB:
2.1 COMO TRABAJAN LAS APLICACIONES WEB
Iniciemos con una breve descripción de cómo trabajan e interactúan las aplicaciones
y servicios web con diferentes componentes y escenarios tecnológicos.
El uso de aplicaciones web es tan común como tan masificado hoy en día por todo
tipo de usuarios, empresas e instituciones. Su uso va desde la simple acción de
leer un correo electrónico hasta realizar una compra en línea o una transacción
bancaria sin importar el cubrimiento de estas aplicaciones, el tamaño, diseño,
código en que estén realizadas, plataformas y arquitecturas en las que estén
montadas.
Algo en común de estas aplicaciones es que la mayoría son interactivas, agradables
para el usuario, con datos en línea que se comparten y que ponen a disposición del
usuario. Muchas de ellas soportadas por grandes bases de datos y que usan como
canal de distribución Internet.
La forma como una aplicación web trabaja, a simple vista es sencilla y práctica. Tal
vez por ello y sin ser una afirmación, es que son vulnerables. Po lo general consisten
en una base de datos que por decirlo así, está ubicada detrás del sitio web alojado
en un servidor y que está escrita en un lenguaje de programación que es capaz de
extraer información específica de esa base de datos por solicitudes y peticiones de
los usuarios remotos o locales mediante interacciones dinámicas con esos usuarios
o clientes.
Cuando se usan bases de datos para la gestión de los mismos en aplicaciones web,
es común que estas aplicaciones estén compuestas por tres niveles:
Un nivel de presentación (un navegador web o motor de búsqueda).
Un nivel lógico (un lenguaje de programación, como C #, ASP, NET, PHP, JSP,
etc.).
Y un nivel de almacenamiento (base de datos como Microsoft SQL Server,
MySQL, Oracle, etc.)
18
Figura 5: Niveles de comunicación en aplicaciones web.
Fuente: El autor
En la (figura 5) se identifica la secuencia de peticiones y operación de los tres niveles
en donde si el navegador Web (el nivel de presentación, por ejemplo, Internet
Explorer, Safari, Firefox, etc) envía peticiones a la capa media (la capa de lógica),
que define los servicios, las solicitudes, consultas y actualizaciones de la base de
datos (el nivel de almacenamiento).
2.2 UNA ARQUITECTURA MÁS COMPLEJA:
En los últimos años, el modelo de tres niveles fue reevaluado y un nuevo concepto
basado en la escalabilidad y mantenimiento fue creado. Surge una solución de
cuatro niveles que implica el uso de una pieza de middleware, típicamente llamado
un servidor de aplicaciones, entre el servidor Web y el servidor de aplicaciones de
base de datos.
Esta nueva capa de abstracción, consta de un servidor que aloja una interfaz de
programación de aplicaciones (API) para exponer la lógica de negocio y procesos
de negocio para uso de los servidores Web. Además, el servidor de aplicaciones
19
pueden hablar con varias fuentes de datos, incluyendo bases de datos, mainframes
u otros sistemas de legado.
Figura 6: Arquitectura de cuatro capas en aplicaciones web.
Fuente: El autor
En la Figura 6, el navegador Web (presentación) envía peticiones a la capa
intermedia (lógica), que a su vez llama a la API expuesta del servidor de
aplicaciones que residen en la capa de aplicación y es el que realiza las consultas
y actualizaciones de la base de datos (almacenamiento).
El usuario ejecuta en el navegador de Internet una consulta y se conecta a
http://www.victima. com. El servidor web que reside en la capa de lógica carga una
secuencia de comandos del sistema de archivos y se lo pasa a través de su motor
de scripting en el que se analiza y se ejecuta El script llama a una API expuesta
desde el servidor de aplicación que reside en la capa de aplicación. El servidor de
aplicación abre una conexión con el nivel de almacenamiento usando un conector
de base de datos y ejecuta una instrucción SQL en la base de datos.
Se devuelven los datos al conector de la base de datos y al servidor de aplicaciones
que implementa las reglas de la lógica de aplicación o negocio antes de devolver
los datos al servidor Web que aplica un retoque de (lógica final) antes de la
presentación de los datos en formato HTML en el navegador Web del usuario. La
presentación de la web se hace mediante HTML que le muestra al usuario una
representación gráfica de la código Esto sucede de manera instantánea y es
transparente para el usuario.
Pero por que se dividen las tareas en capas o niveles?: El concepto básico de una
arquitectura estratificada implica dividir una aplicación en trozos lógicos, o niveles,
cada uno de los cuales se le asignan roles. Las capas se pueden localizar
20
(implementar) en diferentes máquinas o en la misma máquina de forma virtualizada
o separados el uno del otro.
Ventajas: Cuando se dividen las responsabilidades de una aplicación en múltiples
capas hace que sea más fácil de escalar la aplicación, permite una mejor
distribución de las tareas de desarrollo entre los desarrolladores, y hace una
aplicación más fácil de leer dándole incluso enfoque de rehúso y de adaptabilidad a
otras aplicaciones existentes o nuevas.
Le da características de robustez a las aplicaciones permitiendo eliminar puntos de
fallos críticos y únicos que se puedan presentar si la aplicación sufre una caída total
o irreparable.
Por ejemplo, la decisión de cambiar de proveedor de bases de datos debe requerir
nada más que algunos cambios en las porciones aplicables de la capa de aplicación,
la presentación y los niveles lógicos.
2.3 EL PROYECTO OWASP Y LAS VULNERABILIDADES EN APLICACIONES
WEB
Antes de dar inicio y entrar en la temática fuerte de la seguridad en aplicaciones
web, se trae a la lectura como referencia el proyecto OWASP: El proyecto abierto
de seguridad en aplicaciones Web (OWASP por sus siglas en inglés) es una
comunidad abierta dedicada a habilitar a las organizaciones para desarrollar,
comprar y mantener aplicaciones confiables.
Se citan textualmente apartes del mismo proyecto que dejan claro que la temática
es amplia y de trabajo continuo. Este módulo académico que se presenta acá, no
pretende abarcar la totalidad de las vulnerabilidades, estrategias, escenarios,
herramientas y metodología usados tanto para detectar, diseñar, proveer,
monitorear y corregir fallos de seguridad en aplicaciones web. Es un referente para
que el profesional tome como partida y apoyo para el análisis de las temáticas que
acá se presentan.
Existen otros proyectos que tratan este tema y de los cuales también se han
referenciado lecciones en este módulo, pero con OWASP se pretende que el
estudiante lo identifique y derive sus conclusiones, aportes y posiciones con
referencia a la temática.
Que mejor que apoyarse en esa experiencia de una comunidad de desarrolladores,
empresas, corporaciones, casas fabricantes de software, profesionales de la TICs,
para citar este inicio que nos ubica en el contexto de la seguridad en la web y que
se aborda de manera académica, objetiva, investigativa y como un ejercicio
profesional en el área de la seguridad, así: No sin antes referenciar el “OWASP top
21
10 de 2013” que lo encuentran acá:
continuar.
13
y que es de necesaria lectura antes de
Figura 7: OWASP – Top 10 - 2013
Fuente: http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202013%20%20RC1.pdf Con licencia Creative Commons
La guía completa del Top 10, es parte del anexo de este módulo:
No se detenga en el Top 10. Existen cientos de problemas que pueden afectar la seguridad
general de una aplicación web tal como se ha discutido en la Guia de Desarrollo OWASP.14 Este
documento es de lectura esencial para cualquiera desarrollando aplicaciones web hoy en día. Una
efectiva orientación en como encontrar vulnerabilidades en aplicaciones web es suministrada en la
13
Disponible en internet con acceso y formato pdf
<https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project>
14
Disponible en internet desde <https://www.owasp.org/index.php/Guide>
22
Guia de Testeo OWASP15 y la Guia de Revision de Codigo OWASP,16 las cuales han sido
significativamente actualizadas desde la última edición del Top 10.
Cambio constante. Este Top 10 continuara cambiando. Incluso sin cambiar una línea de código
en su aplicación, la misma puede ser vulnerable a algo que nadie haya pensado anteriormente. Por
favor revise los consejos detallados al final del Top 10 “Próximos pasos para Desarrolladores,
Verificadores y Organizaciones” para mayor información.
Piense positivamente. Cuando se encuentre preparado para dejar de buscar vulnerabilidades
y focalizarse en establecer controles seguros de aplicaciones, OWASP ha producido el Application
Security Verification Standard (ASVS)17 como una guía para organizaciones y revisores de
aplicaciones que detalla los controles de seguridad a verificar en una aplicación.
Utilice herramientas inteligentemente. Las vulnerabilidades de seguridad pueden ser
bastante complejas y encontrarse ocultas en montañas de código. En virtualmente todos los casos,
el enfoque mas eficiente y económico para encontrar y eliminar estas vulnerabilidades es asignar
expertos armados de buenas herramientas para realizar esta tarea.
SDLC Seguro. Aplicaciones Web seguras son solo posibles cuando se utiliza un SDLC Seguro.
Para orientación sobre como implementar un SDLC Seguro, leer el Open Software Assurance
Maturity Model (SAMM),18 el cual es una actualización significativa al OWASP CLASP Project.19
2.4 SNIFFEO Y CODIFICACIÓN DE CABECERAS:
La temática que hasta aquí se ha tratado, ha descrito de forma general el protocolo
HTTP y las negociaciones entre cliente-servidor que se establecen a través de
cabeceras, “los HTTP Headers.”
Para poder trabajar con las cabeceras necesitaremos de una serie de utilidades
cuya finalidad es la de interceptar las cabeceras que manda nuestro navegador,
para permitir su análisis o su modificación. Estas utilidades se denominan sniffers,
y funcionan interceptando el tráfico que pasa por el puerto 80 (HTTP).
Estas herramientas pueden venir en forma de Addons o Plugins para diferentes
navegadores, que entre los cuales destacan para FireFox, Tamper Data y Live
HTTP Headers, o también pueden ser programas independientes propietarios o de
15
Disponible en internet desde <https://www.owasp.org/index.php/Category:OWASP_Testing_Project>
Disponible en internet desde
<https://www.owasp.org/index.php/Category:OWASP_Code_Review_Project>
17
Disponible en internet desde <https://www.owasp.org/index.php/ASVS>
18
Disponible en internet desde
<https://www.owasp.org/index.php/Category:Software_Assurance_Maturity_Model>
19
Disponible en internet desde <https://www.owasp.org/index.php/Category:OWASP_CLASP_Project>
16
23
código abierto. Estas herramientas son fundamentales para el trabajo con las
cabeceras http.
Existen otras formas de trabajar con las cabeceras sin tener que sniffearlas para
modificarlas, como por ejemplo aprovechar algún programa que haga
negociaciones TCP, como por ejemplo pueden ser Telnet, Putty, o los populares
Netcat y CryptCat.
2.5 INYECTANDO CÓDIGO
Cuando se hace un proceso de sniffing a las cabeceras HTTP, se puede hacer con
dos objetivos: Observar los datos que se envían y de ahí buscar un posible CSRF
(Cross Site Request Forguery) o bien para modificar la cabecera y añadirle
código malicioso, el cual provoque en una aplicación vulnerable una respuesta
que no era la que debía.
Se inyecta código a las cabeceras y si se manejan datos procedentes de la cabecera
sin realizarles un correcto filtrado, es ahí cuando una aplicación web se vuele más
vulnerable y más cuando sin restricciones o controles de acceso, se le permite al
“front-End” (usuarios hackers) la modificación de la cabecera para que la aplicación
web maneje códigos maliciosos, y ejecute éstos, de esta forma podemos convertir
a las cabeceras como medio para inyectar sentencias SQL maliciosas, JavaScript,
etc. para realizar diversos ataques a una web.
En las siguientes lecciones, se detallarán los procedimientos para detectar
inyecciones de código como el “SQL Injection”
2.6 CR/LF INJECTIONS:
Esta vulnerabilidad hace referencia a un término común: (HTTP Splitting). Hace
referencia al manejo de cabeceras con caracteres especiales que trabajan en
conjunto llamados CR (Carriage Retun) y LF (Line Feed) que básicamente traducen
un “Salto de línea” en el momento de una conversación o salto de cabecera. En
programación las señales de salto de línea se plasman con los caracteres de escape
\r\n.
Una aplicación es vulnerable a CR/LF injection cuando no filtra de forma correcta
las variables, permitiendo escanear (indagar) en ellas valores prohibidos como lo
son éstos. Esta vulnerabilidad implica el que un usuario malintencionado pueda
24
manipular a su antojo las cabeceras de un servidor y más si es bien conocido que
la finalización de una cabecera se señala con un doble salto de línea
Es aquí cuando un atacante identificando ese salto de línea final, provocará la
“partición” de la cabecera, permitiendo colocar junto al doble salto de línea el código
que él considere oportuno, normalmente será una segunda cabecera.
A la técnica de “truncar” o “cortar” una cabecera para controlar una respuesta del
servidor se la denomina “HTTP Splitting”. Una técnica derivada del HTTP Splitting
puede ser lo que se denomina “File Download Injection” y consiste en infectar con
el código que nosotros deseemos una descarga.
2.7 XSS Y SQL INJECTIONS
Las fallas de inyección, ya sea de SQL, LDAP o comandos del sistema operativo,
son comunes en aplicaciones Web. La inyección ocurre cuando los datos
proporcionados por el usuario son enviados e interpretados como parte de una
orden o consulta. Los atacantes interrumpen el intérprete para que ejecute
comandos no intencionados proporcionando datos especialmente modificados.
Esta técnica es usada para explotar aplicaciones web que no validan la información
suministrada por el cliente, para generar consultas SQL maliciosas. El proceso de
inyección requiere de verificar cada parámetro que se envía y se recibe, lo que suele
no ser sencillo y muchas veces se puede creer que no es vulnerable una aplicación
que lo es. Se debe chequear cada parámetro de cada script de cada aplicación.
Para el siguiente ejemplo en la que se inyecta el comando (se solicita una
información):
SELECT id FROM usuarios WHERE user=‘$f_user’
AND password=‘$f_pass’;
Si no se identifica un usuario (campo en blanco en la validación) o si se typean los
parámetros predeterminados de los usuarios: admin, administrator, guest, invitado
entre otros, al modificar la injección de SQL por:
$f_user= “‘ or 1=1 --”
en las que se usa:
; para ejecutar múltiples queries
-- para comentar el final del query
construcciones del tipo ´ or ´´=´
construcciones del tipo numero or 1=1
Se podría explotar esta vulnerabilidad de validación de usuario e ingresar al sistema
25
Ataques de Cross−Site Scripting: Las fallas de XSS ocurren cuando una
aplicación toma información originada por un usuario y la envía a un navegador Web
sin primero validar o codificar el contenido. XSS permite a los atacantes ejecutar
secuencias de comandos en el navegador Web de la víctima que pueden secuestrar
sesiones de usuario, modificar sitios Web, insertar contenido hostil, etc.
Este tipo de ataques han sido explotados para crear poderosos ataques de
phishing y de abusos en el navegador donde los atacantes típicamente se valen
de código HTML y de scripts ejecutados en el cliente.
“Desde la liberación del lenguaje JavaScript, se previeron los riesgos de permitir a
un servidor Web enviar código ejecutable al navegador. Un problema se presenta
cuando los usuarios tienen abiertos varias ventanas de navegador, en algunos
casos un script de una página podría acceder datos en otra página u objeto,
observando el peligro de que un sitio malicioso intentara acceder datos sensibles
de esta forma. “20
Política same−origin: Esencialmente esta política permite la interacción entre
objetos y páginas, mientras estos objetos provengan del mismo dominio y en el
mismo protocolo. Evitando así que un sitio malicioso tenga acceso a datos sensibles
en otra ventana del navegador vía JavaScript. A partir de entonces se han
introducido otros mecanismos y políticas de control en los navegadores y en los
lenguajes en el lado del cliente, para proteger a los usuarios de sitios maliciosos.
Las vulnerabilidades XSS pueden ser vistas como técnicas de evasión de las
políticas de protección.
La mayoría de casos la variable vulnerable (en el caso de los XSS) suele ser alguna
que se utiliza para mostrar alguna información tipo IP, User-Agent y demás. Por eso
la mayoría de webs que ofrecen servicios adicionales como el de mostrar el nombre
de usuario logueado, mostrar la IP, mostrar zonas horarias, mostrar datos de fecha
de inicio de sesión entre otros, datos que suelen ser vulnerables cuando se
modifican las cabeceras.
2.8 PHP INJECTIONS
Existen algunos ataques que aprovechan la posibilidad de la aplicación de subir
archivos al servidor. Estos ataques funcionan de la siguiente manera:
Generalmente PHP almacena los archivos subidos en una carpeta temporal, sin
embargo es común en las aplicaciones cambiar la localización del archivo subido a
una carpeta permanente y leerlo en la memoria. Al hacer este tipo de
20
Tomado de: UNAM CERT; “Aspectos Básicos de la Seguridad en Aplicaciones Web”
26
procedimientos debemos revisar el parámetro que hará referencia al nombre del
archivo, ya que puede ser truqueado a modo de apuntar a archivos de configuración
del sistema (como /etc/passwd en sistemas Unix).
Las aplicaciones invocan comandos externos a través de un intérprete de
comandos. Según la forma de invocarlos, es posible que un usuario malicioso logre
ejecutar un comando externo distinto al esperado. Ej.: uso del caracter “;” en Unix
o “&” en Windows.
2.9 BANNER GRABBING
Se le suceder que el sitio web despliegue banners que emiten información del sitio.
De estos banners no hay que fiarse si no se tienen definidos los scripts filtrados para
los usuarios que accedan al sitio. Se define básicamente banner a la información
(aplicación, versión, plataforma sobre la que corre) que trasmite un servicio cuando
se trabaja sobre en el.
Un ejemplo de detección de esta información (se revela el servicio que está
disponible, el tipo de servidor montado y el puerto 21 al que responde) es el acceso
a servicios ftp. La figura 8 muestra un rastreo al servicio de alojamiento de archivos
(descargas) muy típico del sitio www.hp.com.
Figura 8: Banner detección por ftp
Fuente: El autor
En la figura 9 se aplica un banner grabbing hacia la web www.unad.edu.co:
Información del tipo de servidor, versión sistema operativo sobre el cual se ejecuta,
versión de PHP entre otros.
27
Figura 9: Banner grabbing por método HEAD
Fuente: El autor
El ataque consistiría en obtener los encabezados por HEAD desde un navegador y
editaros para reenviar peticiones y modificar comportamientos del sitio.
2.10 HTTP FINGERPRINTING
Se trata entonces de obtener información de un sistema concreto y de alguna
vulnerabilidad específica. Esto se hace obteniendo su huella identificativa respecto
de la pila TCP/IP de los equipos atacados. Esta técnica es la que se conoce como
Fingerprinting y la información que puede brindar esta técnica dentro de las muchas
opciones que tiene de descubrir datos de la víctima es la de permitir descubrir de
forma muy fiable el sistema operativo que se ejecuta en la maquina analizada. La
aplicación de esta técnica consiste en la ejecución de 4 tests (orden de campos al
hacer un HEAD, respuesta ante un DELETE, respuesta ante una versión del
protocolo HTTP incorrecta, y por último, la respuesta que da el servidor ante un
protocolo erróneo).
Con los resultados de los mencionados cuatro tests, podremos diferenciar
perfectamente entre servidores Apache y los IIS, ya que de cada uno se extrae un
resultado diferente ante cada uno de los tests. Además de las versiones de sistema
operativo, puertos abiertos y capas de seguridad implementadas al protocolo HTTP.
La información que puede brindar esta técnica dentro de las muchas opciones que
tiene de descubrir datos de la víctima son:
28



Permitir descubrir de forma muy fiable el sistema operativo que se ejecuta en
la maquina analizada.
Identificar el tipo de servidor y la versión en la que se soporta el servicio
El tipo de servicio que se ejecuta y la versión.
Una de las muchas técnicas que existen para levantar este tipo de información con
respecto al levantamiento de una huella identificativa, es el uso de “Escuchas de
Red” o escaners de puertos como la herramienta nmap, con miras a establecer un
posible ataque. En la Figura 10 se muestra un escaneo a un host de una red local
en busca de su huella identificativa. Se ha identificado información con el número
de puertos cerrados que tiene la víctima, en este caso con la dirección IP 10.1.1.16,
los puertos en servicio abiertos, la identificación del sistema Operativo y la dirección
física de la interfaz de red. Se ha ejecutado en una consola haciendo uso de nmap
como herramienta de exploración.
Figura 10: Uso de un “Escucha de Red” para hallar huellas identificativas de un host en la red
Ethernet
Fuente: El autor
En la Figura 11 se ha realizado la inspección de la huella identificativa de un sistema
remoto en la web. Es el caso de www.unab.edu.co haciendo uso de un Sniffer como
Ettercap. Se identifica el Sistema Operativo del Servidor, en este caso FreeBSD 4.3
29
que da el servicio, el puerto que está activo con el servicio http en el puerto TCP 80
y el administrador Web que da el servicio: Oracle Aplication Server.
Figura 11: Uso de un “Escucha de Red” para hallar huellas identificativas de un host remoto
Fuente: El autor
Una de las herramientas para realizar estas detecciones y ataques es usar “hping2,
se puede: evaluar el desempeño de la red utilizando diferentes protocolos, tamaños
de paquetes, TOS (type of service, o sea, tipo de servicio), y fragmentación; realizar
descubrimiento de camino utilizando el campo MTU (onda traceroute); transferir
archivos (incluso ante reglas de firewall muy fascistas); realizar funciones al estilo
`traceroute' pero bajo diferentes protocolos; detección remota de OS (`remote OS
fingerprinting'); auditar una implementación de TCP/IP (`TCP/IP stack') en particular;
etc. hping2 es una buena herramienta para aprender acerca de TCP/IP.”21
21
<RODES, Michael. Pruebas de seguridad con hping. “El Baile”. Magazine N 38>
30
LECCION 3: HERRAMIENTAS PARA LA DETECCION DE
VULNERABILIDDES
3.1
FIABILIDAD
DE
LOS
VULNERABILIDADES WEB
ANALIZADORES
AUTOMÁTICOS
DE
Se llega al punto de definir qué tan fiables los analizadores automáticos de
vulnerabilidades Web. En primera instancia al gran número de herramientas
existentes, los diferentes escenarios en que se aplican y en sí mismo la casi por
decirlo así infinitas vulnerabilidades que se presentan y la no certeza de detección
y protección total.
Los profesionales informáticos, empresas, administradores de TICS, diseñadores,
desarrolladores e incluso usuarios, concentran sus actividades en aspectos de
seguridad en emplear, cada vez más, herramientas para facilitar la ardua tarea de
verificar el nivel de seguridad real de una aplicación web. Nombres como Appscan,
Webinspect, Acunetix y otros tantos son cada vez más conocidos y utilizados por
los profesionales en cualquier proyecto de auditoría o de pentest. Las ventajas son
innumerables pero también los riesgos, y es necesario conocerlos y valorarlos a la
hora de decidir el presupuesto de que se dispone para analizar si una página Web
puede ser comprometida, desde el punto de vista de la seguridad, o si, por el
contrario, cumplirá con su cometido a la perfección.
Por Escáner Web se entiende cualquier programa con la capacidad de analizar la
seguridad de una aplicación o página Web, es decir, debe incluir los siguientes
complementos:
a) Un navegador Web para poder interpretar el código HTML, javascript y demás de
la propia página.
b) Un "spider" o "crawler" para poder detectar toda la estructura de navegación de
la Web (archivos, directorios, ficheros de imágenes, etc.)
c) Un escáner propiamente dicho para hallar fallos de configuración y
vulnerabilidades a nivel Web.
d) Un interface de usuario amigable y fácil de utilizar, que permita configurar de
forma sencilla la aplicación y todos los parámetros de análisis.
e) Un generador de reportes que incluya las vulnerabilidades y errores encontrados,
su posible impacto para la aplicación Web y la forma de corregir los mismos de
forma genérica.
31
Existen multitud de herramientas así, comerciales de pago y con licencia GNU, para
Windows y para Linux, más sencillas y más completas, de desarrolladores
conocidos como RedHat, Oracle, Cisco.
3.2 VENTAJAS Y BENEFICIOS
1. Reducción de costes: el precio y el esfuerzo en horas de revisar una
aplicación Web se reducen considerablemente utilizando herramientas
comerciales del tipo de las anteriormente nombradas, Acunetix, Appscan,
Webinspect, etc. A pesar de que el precio por licencia de uso es importante,
basta realizar unos pocos análisis y revisiones para amortizar la herramienta.
Además, existen incluso aplicaciones que no son comerciales sino Open
Source que también son importantes, es el caso de Wapiti22, Skipfish, Nikto,
etc.
2. Disponibilidad y automatización: al poder programar y automatizar
cualquier análisis de seguridad, se puede repetir tantas veces como sea
necesario para verificar que se han corregido los errores y vulnerabilidades
ya detectados. También se puede definir una frecuencia determinada para
que se revise una página Web concreta una vez al mes, por ejemplo, y
comprobar así si ha habido cambios en la misma y detectar incluso
anomalías que pudieran indicar un ataque a la página en forma de intrusión
o Denegación de Servicio (DoS). Si en un escaneo programado la página no
está operativa puede ser debido a un ataque de DoS o un problema de
disponibilidad no controlado.
3. Constante revisión y mantenimiento de la aplicación: La mayoría de
herramientas lo hacen todo, revisan, analizan detectan las vulnerabilidades
y errores de configuración, sugieren soluciones, generan los informes y
reportes. Es trabajo del profesional analizar que herramienta aplicar y si le
ofrece estos servicios.
22
Disponible en internet dese <http://hacktimes.com/vulnerabilidades_en_aplicaciones_web_-_wapiti>
32
3.3 INCONVENIENTES Y DESVENTAJAS
1. Gran cantidad de falsos positivos y falsos negativos: dos peticiones
iguales en momentos diferentes a la aplicación Web por parte del escáner,
pueden generar respuestas distintas que la herramienta puede interpretar de
forma errónea y reportar como una vulnerabilidad inexistente. Anuncios,
dependencias con otras páginas y aplicaciones, usuarios conectados
interactuando con la Web analizada, etc. En multitud de ocasiones la revisión
de seguridad se limita a pasar la herramienta automática y no se verifica la
existencia de las vulnerabilidades reportadas, pudiendo ser falsos positivos
o indicios de otras vulnerabilidades sí presentes pero no detectadas por la
herramienta. También, otras veces, la página Web analizada presenta
diverso código y contenido inútil para revisar la seguridad de la misma que
una persona puede identificar de forma rápida y sencilla, pero que no lo es
tanto para un ordenador y la correspondiente aplicación automática. Un
ordenador no es capaz de entender la lógica de la aplicación Web, y el
escaneo de seguridad se basa en comprobar la respuesta de la página Web
ante los controles y tests que tiene predefinidos la herramienta de análisis
como vulnerabilidades ya conocidas.
2. Imposibilidad de encontrar 0days y errores de diseño: al basarse el
análisis en comprobar la respuesta de la página Web ante los controles y
tests que la herramienta tiene predefinidos como vulnerabilidades ya
conocidas, es muy difícil detectar la presencia de errores no conocidos
(0days) y que no están incluidos en la base de datos del escáner Web con el
que se realiza la revisión de seguridad. Además, es complicado que un
ordenador pueda entender la lógica de la aplicación, cosa que para un
técnico con conocimientos no supone ningún reto.
3. Problemas con vulnerabilidades de aplicación conocidas como Cross
Site Scripting (XSS) y SQL Injection (SQLi): estas vulnerabilidades en
todas sus modalidades (Blind SQLi, Stored XSS, reflected, etc.) presentan
multitud de patrones de ataque, y si además se encuentran por en medio
mecanismos de seguridad como WAF, IPS, firewalls y otros, las herramientas
automáticas no son capaces de modificar sus peticiones para evadir
dichos filtros que plantean estos dispositivos de seguridad. En diversas
ocasiones, se ha reportado una vulnerabilidad de SQLi estándar como Blind
SQL y la solución para corregirla es ligeramente distinta. Otro problema es
33
que numerosas herramientas automáticas no detectan como ataque de SQLi
una vulnerabilidad en "ORDER BY", además es diferente la forma de tratar
esta vulnerabilidad en función del motor de base de datos existente, ya sea
MS SQL, MySQL, PostgreSQL, etc.
4. Riesgos directos para la aplicación Web: ya no solo por el límite de
peticiones que una herramienta automática puede lanzar en paralelo contra
la aplicación Web que puede saturar a la misma y dejarla inaccesible para
sus usuarios legítimos, sino también por el tipo de patrones y pruebas que
tiene definidas para encontrar vulnerabilidades. Una de esas pruebas
consiste en utilizar la conocida sentencia para detectar vulnerabilidades de
SQLi, "or 1=1--". En una petición de "SELECT" no hay problema pero si eso
mismo acompaña a una petición de "DELETE" quedaría una cosa parecida
a "DELETE FROM users where id=1 or 1=1 --" con lo que esto supondría
para la aplicación Web. Un técnico no usaría nunca este método de ataque
pero aún existen muchas herramientas que se sirven de ella como patrón de
ataque
Resumiendo, para entornos productivos, lo más recomendable para disponer de un
nivel aceptable de seguridad en las aplicaciones Web es combinar escaneos con
herramientas automáticas y detectar aquellas vulnerabilidades de bajo nivel ya
conocidas, y disponer también de técnicos de seguridad con amplios conocimientos
que puedan realizar pruebas manuales específicas para cada aplicación. No es lo
mismo revisar un CMS conocido tipo Wordpress, Joomla, etc. que una página Web
sin contenido dinámico ni base de datos detrás. Un técnico puede ajustar las
pruebas y los análisis a realizar en función de las necesidades de cada caso, se
trata de soluciones no industrializadas
3.4 CRITERIOS DE VALORACIÓN PARA HERRAMIENTAS DE SEGURIDAD
WEB
Continuación se presenta un análisis de las principales herramientas usadas para
detección y gestión de riesgos en seguridad de aplicaciones web. Tanto
herramientas de código privado como de código libre. Dentro de los parámetros que
se han tenido en cuenta para esta evaluación, se han tenido en cuenta que las
vulnerabilidades y las herramientas se han aplicado en sistemas con seguridad
perimetral, interna y de entorno básicas, con conexiones de internet libres sin
restricciones, como las que tienen la mayoría de usuarios.
El criterio de valoración fue la primera serie de características de auditoría de cada
herramienta soporta. Una herramienta automatizada no puede detectar una
exposición que no puede reconocer (al menos no directamente, y no sin un análisis
34
manual), y por lo tanto, el número de características de auditoría afectará la cantidad
de exposiciones que la herramienta será capaz para detectar (suponiendo que la
función de auditoría se aplican adecuadamente, que los puntos vulnerables de
entrada será detectado y que la herramienta se encargará de escanear los vectores
de entrada vulnerables).
Las herramientas evaluadas fueron a nivel de aplicación, en cuanto a la detección
de los riesgos que se podrían presentar para atacar a la aplicación web, y el ataque
a los clientes legítimos.
3.4.1 Herramientas Comerciales: El número de funciones de auditoría en
escáneres de aplicaciones Web - Herramientas Comerciales.
Figura 12: Funciones de auditoría en escáneres de aplicaciones web. Herramientas comerciales
Fuente: <Proyecto OWASP>
3.4.2 Herramientas de código Abierto: El número de funciones de auditoría en
escáneres de aplicaciones Web - Herramientas de código abierto.
35
Figura 13: Funciones de auditoría en escáneres de aplicaciones web. Herramientas de código
abierto
Fuente: <Proyecto OWASP>
3.4.3 Herramientas de auditoría aplicadas a SQL INJECTION
El análisis aplica a las herramientas que pueden detectar de SQL Injection, una de
las exposiciones más famosas en ataques comúnmente aplicado en los escáneres
de aplicaciones web. El análisis siguiente es producto de la evaluación de que tan
buenas son las herramientas en la detección de riesgos de inyección SQL, partiendo
de un punto sin ningún tipo de restricciones que pueden impedir que la herramienta
funcione correctamente.
36
La evaluación se realizó en una aplicación que utiliza MySQL 5.5.x como su
repositorio de datos, y por lo tanto, reflejará la exactitud de la detección de la
herramienta cuando se escanean los repositorios de datos similares.
La barra azul representa el caso vulnerable prueba de precisión de detección,
mientras que la barra roja representa falsas categorías positivas detectadas por la
herramienta.
Herramientas de código privado
Herramientas de código abierto
Figura 14: Funciones de auditoría en escáneres de aplicaciones web para SQL Injection
Fuente: <Proyecto OWASP>
37
3.4.4 Herramientas de auditoría aplicadas a XSS (Ataques de Cross−Site
Scripting)
Para el segundo ataque más común implementado en los escáneres de
aplicaciones web se aplicó le mismo procedimiento que en los atajes de SQL
Injection.
Herramientas de código privado
Herramientas de código abierto
Figura 15: Funciones de auditoría en escáneres de aplicaciones web para XSS
Fuente: <Proyecto OWASP>
38
Continuando con la evaluación de herramientas y aplicando ciertos criterios de
efectividad y de aplicabilidad, se adjunta como ANEXOS de este módulo, los
análisis de ciertas variables que son de importancia analizarlas.
Todas estas herramientas son tan solo un puñado entre la cantidad de estrategias,
métodos y utilidades que se pueden seguir para realizar la explotación de las
vulnerabilidades en una aplicación web. El objetivo es obtener información de la
aplicación, tratar de realizar una evaluación de la vulnerabilidad con el fin de obtener
información sobre los exploits que se pueden utilizar. Una vez hecho esto, explotar
las vulnerabilidades y si es necesario, cargar un backdoor o un script que determine
la vulnerabilidad encontrada.
Referencio el WAVSEP (The Web Application Vulnerability Scanner
Evaluation Project) como una aplicación web vulnerable diseñado para ayudar
a evaluar las características, la calidad y la precisión de los escáneres de
vulnerabilidades de las aplicaciones web.23
LECCIÓN 4: MITOS EN LA SEGURIDAD WEB
Siempre se cree que las vulnerabilidades más comunes como SQL Injection, DDoS
y XSS, son las que afectan a las aplicaciones web. También que los errores son por
deficiencias en la programación e implementación de estas aplicaciones. Se
referencian ciertos mitos que desmienten estas apreciaciones y que muestran que
tan lejos estamos de la realidad del entorno en que las aplicaciones web se aplican
y las vulnerabilidades que las rodean:


23
El cliente hace las peticiones básicas del sitio y accede a los links que solo
le referencia la página o sitio (se asume que el cliente no “escarba” dentro
del sitio).
HTML admite el uso de tags (etiquetas) que manipulan la entradas a la
aplicación, por ejemplo si la aplicación utiliza campos ocultos para enviar
información sensible estos pueden ser fácilmente manipulados desde el
cliente.
Disponible en internet desde <http://code.google.com/p/wavsep/>
39



La validación solo se puede realizarse únicamente del lado del cliente con
JavaScript (esto es falso) si no se efectúa ninguna validación del lado del
servidor, cualquier atacante que evite esta validación (para nada difícil de
lograr) tendrá acceso total a toda la aplicación.
Cuando se tiene un sistema y entorno seguro no hay riesgo de
vulnerabilidades. El uso de firewalls es suficiente - como explicamos
anteriormente, si el firewall tiene que habilitar los puertos 80 y/o 443 para que
la aplicación sea accesible al exterior, no podrá hacer nada para detectar
entradas maliciosas del cliente, y por supuesto no es protección contra
ataques internos.
El uso de SSL es una solución suficiente - SSL simplemente cubre el
request/response HTTP dificultando la intercepción del tráfico entre cliente y
servidor, pero no agrega seguridad al servidor ni evita el envío de código
malicioso desde el cliente.
Otro Mito es el que los desarrolladores y técnicos encargados de la seguridad
enmarcan dentro de solo las “supuestas” cinco vulnerabilidades más comunes,
dejando a un lado las estrategias de prevenir, analizar, detectar y sobre todo diseñar
aplicaciones expuestas a otro tipo de vulnerabilidades.
Figura 16: Categoría de Vulnerabilidades
Fuente: El Autor
40
4.1 AUDITORÍA Y CONTROL DE VULNERABILIDADES:
Muchas empresas sólo realizan el escaneo de vulnerabilidades para los periodos
de las famosas auditoria seguridad informáticas – y quizás rara vez, generalmente
como una vez al año. Este es un gran error; no sólo se deben realizar las
actualizaciones a las redes de forma frecuente, sino que hay que saber que nuevas
vulnerabilidades se descubren semanalmente por no decir de forma diaria. Para
organizaciones muy grandes, es importante realizar el escaneo de vulnerabilidades
como parte del análisis de seguridad regular con una mayor cantidad de escaneos,
mucho más frecuente (un ejemplo podría ser realizar el escaneo de
vulnerabilidades, de forma exhaustiva, cada 4 meses, o sea unas 3 veces al año).
4.2 PUNTOS DÉBILES:
Los hackers siempre quieren encontrar el acceso más fácil a las redes de las
organizaciones valiéndose de una variedad de técnicas diferentes. Pero una
característica que todos los atacantes “hackers” tienen en común es su deseo de
buscar los puntos débiles de una red, cuál de ellos puedan usar para lanzar ataques
con el mínimo esfuerzo.
Un ladrón normal busca una puerta abierta en una casa, un ladrón de autos busca
el vehículo en donde el conductor se haya dejado la llave olvidada, un hacker puede
examinar múltiples redes para encontrar la que le proporcione un acceso rápido y
simple. Esta situación plantea un desafío para los administradores de redes que,
para combatir a los hackers, deben comenzar a pensar como ellos.
Con referencia a lo anterior, un aspecto que siempre se debe cuidar es evitar que
en nuestro sistema se Exploren puertos:
Exploración de puertos: El escaneo o exploración de puertos permite determinar
las características de una red o sistemas remotos, con el objetivo de identificar los
equipos disponibles y alcanzables desde Internet, así como los servicios que ofrece
cada uno. Se puede llegar a conocer los sistemas existentes, los servicios ofrecidos
por ellos, cómo están organizados los equipos, que sistemas operativos ejecutan y
cuál es el propósito de cada uno. Una herramienta de código abierto que sirve para
efectuar rastreo de puertos es nmap.
Con la herramienta hping2 en el modo SCAN (-8 --scan): Permite realizar análisis
de puertos, se pueden especificar distintas opciones para los puertos, rangos,
excluir determinados puertos, los puertos incluidos en /etc/services, etc.
41
4.3 TIPOS DE ESCANERS:
Parte de los mitos que rodean la seguridad en aplicaciones web, está el que aplican
los técnicos, administradores de red, desarrolladores y profesionales, que les llevan
a pensar que solo se deben implementar escáneres que detecten riesgos en las
capas superiores del modelo OSI, La seguridad de la información es un conjunto
engranado que enmarca todos los aspectos en comunicación, transferencia, trato
de información. Es por ello que se deben aplicar escáner de este tipo para que
medianamente se puedan minimizar riesgos y maximizar la seguridad:
Escáner de Red: escáner de uso general usado para encontrar vulnerabilidades
potenciales en la red de la empresa. (También se podría incluir a los escaners de
redes VoIP)
Escáner de Puerto: software diseñado para buscar en una red los puertos abiertos
que podrían ser usados por los atacantes como puntos de entrada.
Escáner para la Seguridad de aplicaciones web: Permite a los negocios realizar
evaluaciones de riesgo para identificar las vulnerabilidades en aplicaciones web y
así evitar ataques. Este tipo de escaners deben ser utilizados también por el
departamento de desarrollo (programación) de una aplicación web, ayudando así a
encontrar todos los bugs que puedan generarse durante la creación de la aplicación,
antes de poner la aplicación a un entorno de producción.
Escáner de Base de datos: permite encontrar puntos débiles en bases de datos,
protegiendo así el activo más importante de una empresa.
LECCIÓN 5: SISTEMA DE LOGS
La auditoría y el registro de los eventos que suceden al ejecutar nuestras
aplicaciones nos permite monitorizarlas y detectar posibles intentos de ataques o
intrusiones.
Un log es un registro oficial de eventos durante un rango de tiempo en particular.
Para los profesionales en seguridad informática se utiliza para registrar datos o
información sobre quién, qué, cuándo, dónde y por qué un evento ocurre en un
dispositivo en particular o aplicación.
42
La mayoría de los logs son almacenados o desplegados en el formato estándar, el
cual es un conjunto de caracteres para dispositivos comunes y aplicaciones. De esta
forma cada log generado por un dispositivo en particular puede ser leído y
desplegado en otro diferente.
También se le considera como aquel mensaje que genera el programador de un
sistema operativo, alguna aplicación o algún proceso, en virtud del cual se muestra
un evento del sistema. 24
Los sistemas de los deben garantizar la monitorización de los eventos que se
producen en la aplicación y asegurar la información de los ficheros de registro.
5.1 FORMATO DEL FICHERO DE LOG:
Por norma general, los servidores web guardan los registros en un formato llamado
Common Log Format. Los servidores que no usan dicho formato por defecto suelen
incluir una opción para usarlo. El formato Common Log Format es el siguiente:
Figura 17: Formato de fichero de Logs
Fuente: <MATEU, Carles; Desarrollo de aplicaciones web; UOC>
Existen variantes extendidas que se aplican a estos formatos. Variantes que
dependen del sistema usado y que generalmente en herramientas de tipo IDS con
24
Disponible en internet dese
<http://www.juntadeandalucia.es/servicios/madeja/contenido/subsistemas/desarrollo/auditoria-yregistro>
43
código abierto, el administrador de la red puede modificar y parametrizar para
obtener la información deseada.
5.2 ANÁLISIS DEL FICHERO DE LOG:
Mucha información que suministran estos ficheros de registro, no son claros y
requieren que se asocien a otros para poderlos interpretar. Lo más común es
encontrar los siguientes datos:









Número de peticiones recibidas (hits).
Volumen total en bytes de datos y ficheros servidos.
Número de peticiones por tipo de fichero (por ejemplo, HTML).
Direcciones de clientes diferentes atendidas y peticiones para cada una de
ellas.
Número de peticiones por dominio (a partir de dirección IP).
Número de peticiones por directorio o fichero.
Número de peticiones por código de retorno HTTP.
Direcciones de procedencia (referrer).
Navegadores y versiones de éstos usados.
A pesar de que las informaciones que podemos obtener del análisis de los ficheros
de log son numerosas, hay unas cuantas que no podemos obtener. De ellas,
algunas resultarían de especial interés:





Identidad de los usuarios, excepto en aquellos casos en los que el usuario
se identifique por petición del servidor.
Número de usuarios. A pesar de tener el número de direcciones IP distintas,
no podemos saber de forma absoluta el número de usuarios, y más si
tenemos en cuenta la existencia de servidores proxy-cache.
Datos cualitativos: motivaciones de los usuarios, reacciones al contenido,
uso de los datos obtenidos, etc.
Ficheros no vistos
Qué visitó el usuario al salir de nuestro servidor. Este dato quedará recogido
en los log del servidor donde el usuario fue después del nuestro.
El análisis de estos ficheros, es específico para cada aplicación de captura que se
tenga.
44
5.3 PROGRAMAS DE ANÁLISIS DE LOGS
Al igual que las herramientas de detección de vulnerabilidades, y escuchas de red;
son innumerables las que hay disponibles tanto en código propietario como de
código abierto. Los programas de análisis de ficheros de log de código libre y que
se pueden usar para obtener información sobre los registros de visitas de nuestro
sitio web permiten mayor manipulación de la información y tratamiento de la misma.
La mayoría de ellos generan los correspondientes informes en forma de páginas
web que podemos publicar incluso en nuestro sitio web.
Es de mencionar los más comunes que poseen interfaces gráficas y con
características completas en cuanto a registros capturados: Webalizer, Awstats,
Analog,
CAPITULO 2: PROTOCOLOS DE SEGURIDAD PARA APLICACIONES WEB
El análisis de estos protocolos nos ubica especialmente en los procesos que
incluyen transacciones e información que se intercambie en sitios web y que por
supuesto es manejada por aplicaciones web. A continuación se detalla los
principales protocolos de seguridad que se manejan actualmente:
1. Secure Socket Layer (SSL)
Secure Sockets Layer (SSL) es el estándar mundial de la seguridad en la Web. La
tecnología SSL se enfrenta a potenciales problemas derivados de la visualización
no autorizada de información confidencial, la manipulación de datos, la apropiación
de datos, el phishing y los demás tipos de amenazas en los sitios Web. Para ello,
se cifra la información confidencial a fin de que sólo los destinatarios autorizados
puedan leerla. Además de evitar la manipulación de la información confidencial, SSL
contribuye a que los usuarios tengan la seguridad de acceder a un sitio Web válido.
Los principales sistemas operativos, aplicaciones Web y hardware del servidor son
compatibles con SSL, lo que significa que esta poderosa tecnología de cifrado de
SSL ayuda a implementar en cada empresa una manta de seguridad que limita la
responsabilidad para todo el sistema con el fin de afianzar la seguridad de los
clientes, incrementar el porcentaje de transacciones finalizadas y optimizar los
resultados finales. Gracias a los avances recientes obtenidos en la tecnología SSL,
existe una amplia variedad de tipos de SSL.
45
2. Transport Layer Security (TLS)
Para intentar corregir las deficiencias observadas en SSL v3 se buscó un nuevo
protocolo que permitiera transacciones seguras por Internet, sobre todo teniendo en
cuenta que SSL es propiedad de la empresa Nestcape. El resultado de esta
búsqueda fue el protocolo TLS, que permite una compatibilidad total con SSL siendo
un protocolo público, estandarizado por el IETF.
TLS busca integrar en un esquema tipo SSL al sistema operativo, a nivel de la capa
TCP/IP, para que el efecto "túnel" que se implementó con SSL sea realmente
transparente a las aplicaciones que se están ejecutando.
3. Protocolo S-HTTP
El protocolo Secure HTTP fue desarrollado por Enterprise Integration Technologies,
EIT, y al igual que SSL permite tanto el cifrado de documentos como la autenticación
mediante firma y certificados digitales, pero se diferencia de SSL en que se
implementa a nivel de aplicación. Se puede identificar rápidamente a una página
web servida con este protocolo porque la extensión de la misma pasa a ser .shtml
en vez de .html como las páginas normales.
4. Protocolo SET
SET se basa en el uso de certificados digitales para asegurar la perfecta
identificación de todas aquellas partes que intervienen en una transacción on-line
basada en el uso de tarjetas de pago, y en el uso de sistemas criptográficos de clave
pública para proteger el envío de los datos sensibles en su viaje entre los diferentes
servidores que participan en el proceso. Con ello se persigue mantener el carácter
estrictamente confidencial de los datos, garantizar la integridad de los mismos y
autenticar la legitimidad de las entidades o personas que participan en la
transacción, creando así un protocolo estándar abierto para la industria que sirva de
base a la expansión del comercio electrónico por Internet.
46
LECCIÓN 6: TIPOS DE ANÁLISIS:
6.1 METODOLOGÍAS DE ANÁLISIS DE SEGURIDAD WEB:
Las aplicaciones web pueden ser analizadas utilizando distintos enfoques, entre
ellos, es posible distinguir los siguientes:
Análisis estático de código: El analista de seguridad posee acceso al código
fuente de la aplicación, y posiblemente a manuales del usuario pero NO POSEE
acceso a la aplicación en sí misma. Tiene como desventajas: Suele suceder, sobre
todo con sistemas grandes, que la cantidad de información es tanta que puede
resultar muy complejo manejarla. No es posible analizar todas las líneas del
programa en búsqueda de vulnerabilidades, lo cual hace que sea complejo definir
exactamente que secciones analizar.
Cuando no es posible acceder a la aplicación, es común que el analista se "pierda"
entre tanto código.
White box: En este enfoque, el analista de seguridad posee acceso al código fuente
de la aplicación, manuales del usuario, credenciales válidas del sistema,
configuración del servidor Web, y acceso a la aplicación en sí misma. Tiene como
ventajas: Más información disponible, más vulnerabilidades que se pueden
descubrir. Es posible descubrir TODAS las vulnerabilidades (si se tiene el tiempo
suficiente) y no es necesario suponer nada, todo está en el código.
Black box: En este enfoque, el analista de seguridad posee únicamente acceso a
la aplicación. Tiene como ventajas la simplicidad, menor tiempo de testing y provee
un enfoque real, ya que se posee el mismo nivel de conocimiento sobre la aplicación
que un potencial intruso.
Como desventajas están: Vulnerabilidades trivialmente detectables con white box
testing, no pueden ser detectadas con este enfoque.
(if user == ‘tester002’ and password == ‘backdoor__’)
No se aprovecha el código fuente de la aplicación a favor de la seguridad de la
misma.
Dependiendo del tipo de enfoque, se aplican herramientas de análisis como las
vistas en la Lección 2 de este módulo.
47
LECCIÓN 7: ESCALACION DE PRIVILEGIOS EN APLICACIONES WEB:
Su definición es la obtención de los privilegios del administrador. Por ello, debe
existir una política o normativa específica que establezca el uso de mecanismos
para impedir intentos de escalado de privilegios en nuestras aplicaciones web. Se
considera que un sistema aplica políticas para evitar el escalado de privilegios
cuando: No es posible acceder a información del sistema que pueda ser utilizada
para la escalada de privilegios, no es posible ejecutar acciones haciéndose pasar
por otro usuario, etc.
Las pruebas de escalada en aplicaciones web involucran por lo menos dos tipos de
autenticación y validación. Un escenario típico para analizar la jerarquía de
privilegios es si dada una aplicación web que debe tener al menos dos tipos de
credenciales: para un usuario con privilegios elevados y bajos de privilegio. Al iniciar
sesión como usuario con privilegios elevados (por ejemplo, admin), obviamente
tenemos acceso a mucha más información (más elementos de menú, más
funcionalidad, etc.)
El punto de análisis crítico es determinar si esos temas (accesos a servicios) se
puede acceder directamente por el usuario con pocos privilegios. El desarrollador
debe estar seguro que la navegación por toda la aplicación de un usuario con
privilegios bajos es confiable y que abarco cada entrada y salida de la aplicación.
El manejo de estos privilegios suele ser administrado mediante credenciales de
acceso haciendo uso de bases de datos. La exposición de estas credenciales son
“huecos” vulnerables para la aplicación.
Los datos de usuario y password son sensibles, por lo que deben tener garantizada
una atención especial. Su presencia en el código fuente es un riesgo inevitable. Un
caso típico de diseño de software es que sean administradas por un lenguaje de
programación de uso general de código del lado del servidor originalmente diseñado
para el desarrollo web como es PHP. Por conveniencia, estos datos son
almacenados en un archivo como db.inc y suelen tener esta forma:
<?php
$db_user = 'myuser'; $db_pass = 'mypass'; $db_host = '127.0.0.1';
$db = mysql_connect($db_host, $db_user, $db_pass);
?>
48
Al analizar el archivo por default http.confg de Apache, encontramos que el tipo
default es text/plain. Esto significa un riesgo si el archivo db.inc se localiza en la raíz
del directorio. Todo recurso localizado en la raíz tiene una dirección URL y como
Apache no tiene un tipo de contenido asociado a los archivos .inc la respuesta del
servidor será devolver el contenido en texto plano del archivo, en donde se podrían
observar las credenciales del servidor.
La mejor solución a este problema es almacenar los archivos a incluir en otro lugar
fuera del directorio raíz. No es necesario tenerlos en algún lugar en particular en el
sistema de archivos para ser capaces de incluirlos o requerirlos, solo es necesario
garantizar que el servidor tenga privilegios de lectura.
De hecho únicamente se debe localizar en la raíz los recursos que se deseen sean
accesibles, o configurar un directorio público con las respectivas directivas de
seguridad.
LECCIÓN 8: AUTENTICACIÓN Y AUTORIZACIÓN:
Normalmente, casi todas las aplicaciones o sistemas necesitan de los procesos de
autentificación y autorización.
8.1 LA AUTENTIFICACIÓN:
Es el proceso por el cual un usuario o servicio tiene que autentificarse para poder
acceder a ciertos servicios que ofrece nuestro sistema. Existen distintas categorías
de autentificación:
¿Qué sabes?: Información que el usuario conoce, ejemplos: contraseñas,
respuestas a preguntas de indicio a contraseñas.
¿Qué tienes?: Elementos físicos que el usuario posee, como por ejemplo una
determinada tarjeta.
¿Quién eres?: Técnicas biométricas como lectura de retina o huellas dactilares.
El control de acceso es el proceso de decidir si el usuario tiene permiso para ejecutar
algo o no.
HTTP por defecto tiene características de autentificación: autenticación del
protocolo que se utiliza para intercambiar mensajes. Para la mayoría de los servicios
49
Web XML, esto significa aprovechar las características de autenticación disponibles
en HTTP.
Los tipos de autenticación típica son:
Básica: utilizada para identificación no segura o poco segura de clientes, ya que el
nombre de usuario y la contraseña se envían como texto codificado en base 64, que
puede ser fácilmente descodificado. En el caso de IIS, autorizará el acceso a los
servicios Web XML si las credenciales coinciden con las de una cuenta de usuario
válida.
Básica sobre SSL: igual que la autenticación básica, excepto que el canal de
comunicación está cifrado y protege de ese modo el nombre de usuario y la
contraseña. Una buena opción para entornos en Internet; sin embargo, el uso de
SSL influye negativamente en el rendimiento.
Implícita: utiliza algoritmos hash para transmitir las credenciales del cliente de
forma segura. Sin embargo, es posible que no sea compatible con todas las
herramientas de desarrollo para generar clientes de servicios Web XML. IIS
autorizará el acceso a los servicios Web XML si las credenciales coinciden con las
de una cuenta de usuario válida.
Autenticación de Windows integrada: resulta útil sobre todo en entornos en
Intranet. Utiliza NTLM o Kerberos. El cliente debe pertenecer al mismo dominio que
el servidor o a un dominio en el que el dominio del servidor confía. IIS autorizará el
acceso a los servicios Web XML si las credenciales coinciden con las de una cuenta
de usuario válida.
Certificados de cliente a través de SSL: requiere que cada cliente obtenga un
certificado. Los certificados se asignan a las cuentas de usuario, que son utilizadas
por IIS para autorizar el acceso a los servicios Web XML. Se trata de una solución
viable para entornos en Internet, aunque el uso de certificados digitales no está muy
extendido actualmente. Es posible que no sea compatible con todas las
herramientas de desarrollo para generar clientes de servicios Web XML. Sólo está
disponible en conexiones SSL, de modo que el rendimiento puede verse afectado
50
8.2 LA AUTORIZACIÓN:25
Se refiere a la gestión del acceso a los recursos protegidos y al proceso de
determinar si un usuario está autorizado a acceder a un recurso particular. Por
ejemplo, muchas aplicaciones web cuentan con recursos que sólo están disponibles
para los usuarios autenticados, recursos que sólo están disponibles para los
administradores, y los recursos que están disponibles para todos. Así, al establecer
privilegios de acceso a los usuarios podemos asegurar la confidencialidad y
disponibilidad de la información; pero, además, podemos:




Que sólo las personas autorizadas podrán acceder a ciertos recursos
(sistemas, equipos, programas, aplicaciones, bases de datos, redes, etc.) por
sus funciones laborales.
Nos permiten identificar y auditar los accesos realizados, estableciendo
controles de seguridad internos.
Documentar los procedimientos de acceso a las diferentes aplicaciones que
tratan datos personales.
En definitiva, controlar los accesos desde diferentes vertientes: red, sistemas
y aplicaciones.
Se presentan dos categorías de Autorización:
Autorización declarativa: En este tipo de autorización los privilegios son
gestionados un administrador independientemente de manera externa al código de
la aplicación
Autorización programática: En este tipo de autorización las decisiones de
autorización se realizan desde el código fuente de la aplicación.
LECCIÓN 9: EJECUCIÓN DE INSTRUCCIONES DE ACCESO:
9.1 CODIFICACIÓN Y LAS VALIDACIONES DE ENTRADA / SALIDA:
Indican que la debilidad de seguridad más común en aplicaciones web es la falta de
validación apropiada de las entradas del cliente o del entorno. Teniendo en cuenta
una serie de indicaciones y consejos a la hora de codificar nuestras aplicaciones
podremos evitar problemas como la inyección de código SQL, de comandos, LDAP,
XPath, XML o por XSS.
25
Disponible en internet dese <http://www.yiiframework.com/doc/guide/1.1/es/topics.auth>
51
Esta debilidad lleva a casi todas las principales vulnerabilidades en las aplicaciones,
tales como intérprete de inyección, ataques locale/Unicode, ataques al sistema de
archivos y desbordamientos de memoria.
Nunca se debe confiar en los datos introducidos por el cliente, ya que podría
manipularlos. Hay que garantizar que la aplicación sea robusta contra todas las
formas de ingreso de datos, ya sea obtenida del usuario, de la infraestructura, de
entidades externas o de sistemas de base de datos.
Existen vulnerabilidades asociadas a la validación de los datos,
Vulnerabilidad de la integridad de los datos: El atacante manipula los datos
introduciendo intencionadamente datos erróneos que manipulan la función de
negocio.
Violación del formato de los datos: Un atacante consigue introducir datos sin la
sintaxis correcta, fuera de los límites de longitud, que contenga caracteres no
permitidos, con signo incorrecto o fuera de los límites del rango. Esto provoca un
mal funcionamiento de la aplicación.
Incumplimiento de las reglas de negocio: Se introducen datos que no cumplen
con las reglas de negocio. Lo que provoca un comportamiento no esperado de la
aplicación.
9.2 GESTIÓN DE SESIONES Y USUARIOS:
El manejo de la sesión es uno de los aspectos críticos de la seguridad WEB.
Veremos cómo es posible mejorar la seguridad en el control de acceso y la
autenticación a través del manejo de las sesiones y de la información de los usuarios
de nuestras aplicaciones.
Se detectan las siguientes vulnerabilidades significativas.
Fijación de sesión que intenta explotar la vulnerabilidad de un sistema que permite
a una persona fijar el identificador de sesión de otra persona. La mayoría de ataques
de fijación del período de sesiones están basados en la web, y la mayoría depende
de los identificadores de sesión que han sido aceptados de URL o datos POST
Identificador de la sesión vulnerable, si no se reserva un tamaño adecuado el
atacante, mediante técnicas de fuerza bruta atacante puede conocer el identificador
de una sesión autenticada y por lo tanto hacerse con el control de la sesión.
52
Manejo de la información de sesión errónea, ya sea por estar en un espacio
compartido o mal encriptada, el atacante puede obtener datos de la sesión de otro
usuario.
Ataques de proxys o cachés, las aplicaciones web deben especificar mecanismos
para impedir estos ataques de tal manera que no sea posible suplantar sesiones de
otros usuarios.
9.3 GESTIÓN DE ERRORES Y EXCEPCIONES:
Uno de los focos que originan vulnerabilidades en nuestras aplicaciones se basa en
la falta de control sobre los errores que se producen en su ejecución y el tratamiento
correcto de las excepciones. Veremos cómo disminuir los riesgos de ser atacados
a partir de la generación de un error o excepción en la aplicación.
El manejo de errores y excepciones son dos aspectos para realizar un seguimiento
de fallos dentro de una aplicación. En términos generales, hay tres situaciones que
hacen que las excepciones sean lanzadas:
Excepciones que se producen en el código del cliente: El código cliente intenta
hacer algo que no está permitido por la API, de esta forma viola el contrato. El cliente
puede tomar algún camino alternativo, si hay información útil proporcionada en la
excepción. Por ejemplo: una excepción es lanzada cuando se está analizando un
documento XML que no está bien formado. La excepción contiene información útil
acerca de la localización en el documento XML donde se produce el problema. El
cliente puede utilizar esta información para recuperarse del problema.
Excepciones por fallos en los recursos mantenidos: Las excepciones se
producen si existe un fallo derivado de un recurso. Por ejemplo, el agotamiento de
memoria o el fallo de conexión cuando se cae una red. La respuesta del cliente a
los recursos que fallan depende del contexto. El cliente puede reintentar la
operación después de algún tiempo o simplemente registrar el fallo del recurso y
detener la aplicación.
Excepciones por errores derivados del código programado: En esta categoría,
las excepciones se producen en la ejecución del código. El código cliente
usualmente no puede hacer nada con estos errores.
53
LECCIÓN 10: CONFIGURACIÓN SEGURA DE SERVIDORES:
La mayoría de los servidores web modernos nos permiten controlar desde el
programa servidor aquellos aspectos relacionados con la seguridad y la
autenticación de los usuarios.
El modo más simple de control es el proporcionado por el uso de ficheros .htaccess.
Éste es un sistema de seguridad que proviene de uno de los primeros servidores
web (del NCSA httpd), que consiste en poner un fichero de nombre .htaccess en
cualquier directorio del contenido web que se vaya a servir, indicando en este fichero
qué usuarios, máquinas, etc., tienen acceso a los ficheros y subdirectorios del
directorio donde está el fichero. Como el servidor de NCSA fue el servidor más
usado durante mucho tiempo, la mayoría de servidores modernos permiten utilizar
el fichero .htaccess respetando la sintaxis del servidor de NCSA.
Otros servidores permiten especificar reglas de servicio de directorios y ficheros en
la configuración del servidor web, indicando allí qué usuarios, máquinas, etc.,
pueden acceder al recurso indicado.
Por lo que respecta a la autenticación (validación del nombre de usuario y
contraseña proporcionados por el cliente), las prestaciones ofrecidas por los
diversos servidores web son de lo más variado. La mayoría permiten, como mínimo,
proporcionar al servidor web un fichero con nombres de usuario y contraseñas
contra el que se pueda validar lo enviado por el cliente. De todos modos, es
frecuente que los servidores proporcionen pasarelas que permitan delegar las
tareas de autenticación y validación a otro software (por ejemplo RADIUS, LDAP,
etc.). Si usamos un sistema operativo como Linux, que dispone de una
infraestructura de autenticación como PAM (pluggable authentication modules),
podemos usar esta funcionalidad como modo de autenticación del servidor web,
permitiéndonos así usar los múltiples métodos disponibles en PAM para autenticar
contra diversos sistemas de seguridad.26
10.1 ORGANIZACIÓN DEL SERVIDOR WEB:
Una forma de implementar aspecto de seguridad en servidores web es la de
administrar procesos y atender peticiones de una manera eficiente y económica, es
necesario definir algunos términos.
26
<MATEU, Carles; Desarrollo de aplicaciones web, p 24, 25 >
54
Proceso: la unidad más “pesada” de la planificación de tareas que ofrece el sistema
operativo. No comparte espacios de direcciones ni recursos relacionados con
ficheros, excepto de manera explícita (heredando referencias a ficheros o
segmentos de memoria compartida), y el cambio de tarea lo fuerza el núcleo del
sistema operativo (preemptivo).
Flujo o thread: la unidad más “ligera” de planificación de tareas que ofrece el
sistema operativo. Como mínimo, hay un flujo por proceso. Si distintos flujos
coexisten en un proceso, todos comparten la misma memoria y recursos de
archivos. El cambio de tarea en los flujos lo fuerza el núcleo del sistema operativo
(preemptivo).
Fibra: flujos gestionados por el usuario de manera cooperativa (no preemptivo), con
cambios de contexto en operaciones de entrada/salida u otros puntos explícitos: al
llamar a ciertas funciones. La acostumbran a implementar librerías fuera del núcleo,
y la ofrecen distintos sistemas operativos.
En general, los modelos con muchos procesos son costosos de memoria (cada
proceso ocupa su parte) y de carga (creación de procesos). En servidores de alto
rendimiento, los modelos con flujos parecen mejores, aunque tienen el problema de
la portabilidad difícil y la posible necesidad de mecanismos que anticipan el coste
de creación de procesos o flujos y, por lo tanto, son muy rápidos atendiendo
peticiones.
En máquinas uniprocesador, los modelos con un solo flujo funcionan bien. En
máquinas multiprocesador, es necesario usar múltiples flujos o procesos para
aprovechar el paralelismo del hardware.
10.2 ORGANIZACIÓN DE LAS APLICACIONES WEB:
Los servidores web se encargan de atender y servir peticiones HTTP de recursos,
que en su forma más simple acostumbran a ser documentos guardados en el
sistema de ficheros. Sin embargo, la otra función importante de un servidor web es
la de actuar de mediador entre un cliente y un programa que procesa datos. Recibe
una petición con algún argumento, la procesa y devuelve un resultado que el
servidor web entrega al cliente. La interacción entre el servidor web y los procesos
que tiene asociados es otro aspecto que hay que considerar.
Existen distintas maneras de organizar una aplicación web. A continuación, por
orden cronológico de complejidad y rendimiento creciente, se presentan distintos
modelos de organización.
55
CGI: es el modelo más antiguo y simple. Para cada petición HTTP se invoca un
programa que recibe datos por las variables del entorno y/o de entrada estándar, y
devuelve un resultado por la salida estándar. Consumir un proceso por cada petición
genera problemas importantes de rendimiento, que el modelo FastCGI intenta
mejorar.
Servlets: es un modelo diseñado para Java, más eficiente y estructurado, que
permite elegir distintos modelos de gestión de flujos o threads, duración de procesos
del servidor, etc. Partiendo de este modelo, se han construido servidores de
aplicaciones con múltiples funciones adicionales que facilitan el desarrollo de
aplicaciones web complejas.
CAPITULO 3 DESARROLLO SEGURO DE APLICACIONES:
LECCIÓN 11: CONCEPTOS GENERALES PARA EL DESARROLLO SEGURO
DE APLICACIONES:
La importancia de una metodología de desarrollo seguro en aplicaciones Web inicia
cuando el principal problema reside en la falta de controles durante el ciclo de vida
del desarrollo de un aplicativo, ya que impera más el hecho que funcione que el
hecho de ser seguro, lo cual es un problema para aplicaciones WEB.
¿Qué amenazas tiene una persona que navegue por Internet? Suplantación de
identidad, robo de credenciales, alteración de los contenidos de la web, ejecución
de acciones sin su conocimiento. Cada uno de ellos está derivado tanto de una
mala metodología de desarrollo como de una falta de concienciación de los
usuarios, los cuales acceden a cualquier enlace sin identificar su procedencia.
Las amenazas, debido a una mala programación, pueden permitir al atacante desde
la obtención de las credenciales de un usuario, hasta la modificación del contenido
de la página web vulnerable pasando por la realización de acciones sin
conocimiento del usuario como compras o transacciones bancarias. Para cada una
de estas acciones hay soluciones más o menos sencillas pero hace falta más
concienciación por parte del equipo de desarrollo para identificarlas en las diferentes
fases del desarrollo.
Por ello, hay que hacer hincapié en identificar en las fases de diseño además de los
casos de uso, los casos de abuso. Un caso de abuso, es la identificación de las
diferentes amenazas que pueden asociarse a un caso de uso. Por ejemplo, en una
56
ventana de login (página donde se introduce el usuario y la contraseña) ¿Cuáles
son las amenazas principales? autenticarse sin conocer la contraseña, obtención
de credenciales, enumeración de usuarios,… Una vez identificados los diferentes
casos de abuso, el siguiente paso sería implantar y diseñar los controles para evitar
estas amenazas. La mayoría de las amenazas se mitigan a través de una validación
robusta de los datos de entrada.
Cada vez es más importante el posicionamiento en internet para la venta de
diferentes productos o servicios. Si una determinada empresa A tiene una
vulnerabilidad en su web y está, a su vez, es explotada ¿Cuál es el impacto para la
organización? Pérdida de confianza de sus clientes con la consiguiente pérdida
económica y de imagen, impacto económico en base a las normativas vigentes de
protección de datos si se publican datos de carácter personal.
Además hay que añadir el gasto que supone la corrección de las vulnerabilidades,
este gasto es superior al gasto económico que hubiera supuesto la realización de
pruebas de identificación de vulnerabilidades en el proceso de desarrollo software.
.No existen páginas webs 100% seguras a pesar de que se les haya implementado
un ciclo de desarrollo seguro de aplicaciones.
Figura 18: Metodología de desarrollo seguro
Fuente: <http://www.consultec.es/>
57
Entendemos por aplicaciones web a todo aquél software que interacciona con el
usuario utilizando el protocolo HTTP. Por su parte, los servicios web son un conjunto
de funciones empaquetadas dentro de una entidad única y publicadas dentro de la
red para que puedan ser utilizadas por las aplicaciones web.
11.1 NORMAS BÁSICAS DE SEGURIDAD:
El proyecto OWASP (Open Web Application Security Project) tiene como objetivo
ofrecer una metodología, de libre acceso y utilización, que pueda ser utilizada como
material de referencia por parte de los arquitectos de software, desarrolladores,
fabricantes y profesionales de la seguridad involucrados en el diseño, desarrollo,
despliegue y verificación de la seguridad de las aplicaciones y servicios web.
La guía empieza estableciendo el principio básico de seguridad que cualquier
aplicación o servicio web debe cumplir:





Validación de la entrada y salida de información La entrada y salida de
información es el principal mecanismo que dispone un atacante para enviar
o recibir código malicioso contra el sistema. Por tanto, siempre debe
verificarse que cualquier dato entrante o saliente es apropiado y en el formato
que se espera. Las características de estos datos deben estar predefinidas y
debe verificarse en todas las ocasiones.
Diseños simples Los mecanismos de seguridad deben diseñarse para que
sean los más sencillos posibles, huyendo de sofisticaciones que compliquen
excesivamente la vida a los usuarios. Si los pasos necesarios para proteger
de forma adecuada una función o modulo son muy complejos, la probabilidad
de que estos pasos no se ejecuten de forma adecuada es muy elevada.
Utilización y reutilización de componentes de confianza Debe evitarse
reinventar la rueda constantemente. Por tanto, cuando exista un componente
que resuelva un problema de forma correcta, lo más inteligente es utilizarlo.
Defensa en profundidad Nunca confiar en que un componente realizará su
función de forma permanente y ante cualquier situación. Hemos de disponer
de los mecanismos de seguridad suficientes para que cuando un
componente del sistema fallen ante un determinado evento, otros sean
capaces de detectarlo.
Tan seguros como en eslabón más débil La frase "garantizamos la seguridad,
ya que se utiliza SSL" es realmente muy popular, pero también es muy
inexacta. La utilización de SSL garantiza que el tráfico en tránsito entre el
58
servidor y el cliente se encuentra cifrado, pero no garantiza nada acerca de
los mecanismos de seguridad existentes.
Por tanto, no debemos fiarnos únicamente de los mecanismos de seguridad
"exteriores", sino que es preciso identificar cuáles son los puntos precisos en los
que deben establecerse las medidas de seguridad. Si nosotros no hacemos este
trabajo, seguro que los atacantes si lo harán.



La "seguridad gracias al desconocimiento" no funciona El simple hecho de
ocultar algo no impide que, a medio o largo plazo, llegue a ser descubierto.
Tampoco es ninguna garantía de que tampoco será descubierto a corto
plazo.
Verificación de privilegios. Los sistemas deben diseñarse para que funcionen
con los menos privilegios posibles. Igualmente, es importante que los
procesos únicamente dispongan de los privilegios necesarios para
desarrollar su función, de forma que queden compartimentados.
Ofrecer la mínima información Ante una situación de error o una validación
negativa, los mecanismos de seguridad deben diseñarse para que faciliten la
mínima información posible. De la misma forma, estos mecanismos deben
estar diseñados para que una vez denegada una operación, cualquier
operación posterior sea igualmente denegada.
Otros aspectos tratados en la guía son: consideraciones de arquitectura,
mecanismos de autenticación, gestión de sesiones de usuario, control de acceso,
registro de actividad, prevención de problemas comunes, consideraciones de
privacidad y criptografía
El proyecto OWASP, “The Open Web Application Security Project” presenta a
disposición de todos los usuarios en la web “A Guide to Building Secure Web
Applications”27 y ha sido reconocida como una metodología de desarrollo seguro
que ha dado resultados. Estos documento se presentan como anexos a este
módulo.
Se referencian estos documentos: Secure Programming for Linux and Unix
HOWTO28 que documentan estrategias seguras en el desarrollo de aplicaciones
web.
27
Disponible en internet desde <http://www.owasp.org/guide/>
28
Disponible en internet desde <http://www.dwheeler.com/secure-programs/>
59
SPSMM - Estándar de programación segura (Secure Programming Standards
Methodology Manual)29
LECCIÓN 12: CONTROLES DE AUTORIZACIÓN DE OBJETOS:
Un control simple de objeto en una aplicación web puede ser el solo simple hecho
de comprobar el tipo de dato. La validación de datos garantiza la corrección y
precisión de todos los valores de datos de la aplicación. Estas acciones se pueden
diseñar utilizando distintos enfoques: código de interfaz de usuario, código de
aplicación o restricciones de bases de datos.
Un ejemplo de validación de control de objetos es el código de servicio con tipo de
datos "character" sólo puede admitir caracteres alfabéticos de la A a la Z; el resto
de caracteres no sería válido. Otro tipo de control típico es el que se aplica al validar
un control TextBox y mostrar un mensaje personalizado cuando se produce un error
en la validación.
De manera predeterminada, la validación se realiza al hacer clic en un control de
botón, como Button, ImageButton o LinkButton. Hay varios tipos de validación de
datos:




Validación del tipo de datos.
Comprobación del intervalo.
Comprobación del código.
Validación compleja
La tabla 2 muestra las propiedades básicas de un control de validación
29
Disponible en internet dese <http://isecom.securenetltd.com/spsmm.0.5.1.en.pdf>
60
PROPIEDAD
DESCRIPCION
ControlToValidate
Id. de programación del control de salida que evaluará el control de validación. Si no
es un Id legítimo, se iniciará una excepción.
Display
Modo en que se muestra el control de validación especificado. Esta propiedad puede
ser uno de los siguientes valores:
Ninguno: El control de validación jamás se muestra en línea. Utilice esta opción
cuando desee mostrar el mensaje de error sólo en un control ValidationSummary
Estático: El control de validación muestra un mensaje de error si se produce un
error en la validación. Se asigna un espacio en la página Web para el mensaje de
error incluso si el control de entrada supera la validación. No cambia el diseño de la
página cuando el control de validación muestra su mensaje de error. Como el diseño
de página es estático, si hay varios controles de validación para el mismo control de
entrada, éstos deberán ocupar distintas ubicaciones en la página.
Dinámico: El control de validación muestra un mensaje de error si se produce un
error en la validación. El espacio para el mensaje de error se asigna dinámicamente
en la página cuando se produce un error en la validación. De este modo, varios
controles de validación pueden compartir la misma ubicación física en la página.
EnableClientScript
Indica si está habilitada la validación en el cliente. Para deshabilitar la validación en
el cliente en los exploradores que admitan esta función, establezca la propiedad
EnableClientScript en false.
Enabled
Indica si está habilitado el control de validación. Para impedir que el control de
validación valide un control de entrada, establezca esta propiedad en false.
ErrorMessage
Mensaje de error que se va a mostrar en el control ValidationSummary si se produce
un error en la validación. Si no está establecida la propiedad Text del control de
validación, también se muestra este texto en el control de validación cuando se
produce un error en la validación. Se utiliza normalmente la propiedad
ErrorMessage para proporcionar diferentes mensajes para el control de validación
y el control ValidationSummary.
ForeColor
Especifica el color en el que se va a mostrar el mensaje en línea cuando se produce
un error en la validación.
IsValid
Indica si el control de entrada especificado por la propiedad ControlToValidate se
determina como válido.
Text
Si esta establecida esta propiedad, se muestra este mensaje en el control de
validación cuando se produce un error en la validación. Si no está establecida esta
propiedad, el texto especificado en la propiedad ErrorMessage se muestra en el
control.
Tabla 2: Propiedades de los controles de validación
Fuente: <http://www.microsoft.com/asp.net >
61
12.1 LISTAS DE CONTROL DE ACCESO (ACL)
Los controles de acceso también están incluidos en aspectos de denegación de
servicio que no solo afectan a los accesos y validaciones propios del sitio, sino
también al entorno del mismo.
Un ACL es una lista secuencial de sentencias de permiso o denegación que se
aplican a direcciones IP o protocolos de capa superior. La ACL puede extraer la
siguiente información del encabezado del paquete, probarla respecto de las reglas
y decidir si “permitir” o “denegar” el ingreso según los siguientes criterios:



Dirección IP de Origen
Dirección IP de Destino
Tipo de mensaje ICMP
La ACL también puede extraer información de las capas superiores y probarla
respecto de las reglas. La información de las capas superiores incluye:


Puerto TCP / UDP de Origen
Puerto TCP / UDP de Destino
Figura 19: Filtrado de paquetes con ACL
Fuente: El Autor
62
El funciónenlo de ACL se basa en una búsqueda de arriba abajo (de la lista de texto
plano), una línea a la vez y se busca un patrón que coincida con el paquete entrante.
La figura 19 muestra cómo se realiza el filtrado de paquetes con ACL
12.1.1. Configuración de las ACL: Pueden configurarse por Protocolo, Por
dirección y Por interfaz.
ALC por Protocolo: Para controlar el flujo de tráfico de una interfaz, se debe definir
una ACL para cada protocolo habilitado en la interfaz.
ALC por Dirección: Las ACL controlan el tráfico en una dirección a la vez de una
interfaz. Deben crearse dos ACL por separado para controlar el tráfico entrante y
saliente.
ALC por Interfaz: Las ACL controlan el tráfico para una interfaz, ejemplo eth0 (si
se está en un sistema UNIX).
12.1.2. Funciones de la ACL: Las ACL realizan las siguientes tareas:







Limitar el tráfico de red para mejorar el rendimiento de esta.
Brindar control de flujo de tráfico
Proporciona un nivel básico de seguridad para el acceso a la red
Se debe decidir qué tipos de tráfico enviar o bloquear en las interfaces del
router
Controlar las áreas de red a las que puedan acceder un cliente.
Analizar los hosts para permitir o denegar su acceso a los servicios de red
Puede darle prioridad al tráfico de la red.
LECCIÓN 13: CONSIDERACIONES DE SEGURIDAD EN WEB SERVICES:
La mayoría de las aplicaciones web son usadas como un conducto entre muchas
fuentes de datos y el usuario, esto es, las aplicaciones web son usadas
frecuentemente para interactuar con una base de datos.
Aunque el tema de la seguridad en las bases de datos merece un tratamiento
diferente al de las aplicaciones web, se encuentran íntimamente relacionados. Toda
entrada al sistema debe ser filtrada, y toda salida escapada. Lo mismo aplica
cuando las entradas o salidas son de o hacia una base de datos.
63
Muchos programadores no dan importancia al filtrado de datos provenientes de una
consulta a la base de datos, debido a que consideran a esta fuente como confiable.
Aunque el riesgo a primera vista parecería menor, es una práctica recomendable no
confiar en la seguridad de la base de datos e implementar la seguridad a fondo y
con redundancia. Si algún dato malicioso pudiera haber sido inyectado a la base de
datos, nuestra lógica de filtrado puede percatarse de ello, pero sólo si se ha
implementado este mecanismo.
13.1 EXPOSICIÓN DE DATOS
Una de las preocupaciones más comunes relacionadas con las bases de datos es
la exposición de datos sensibles. Al almacenar números de tarjetas de crédito, o
algo tan delicado, es preferible asegurarse que los datos almacenados en la base
de datos se encuentran seguros e inaccesibles incluso para los administradores de
la base. Una buena recomendación es encriptar los datos más sensibles, de esta
manera si la base de datos llega a ser comprometida el desastre será menor. Un
ejemplo de esta técnica es almacenar las contraseñas de usuario convertidas con
md5. De esta manera, las cadenas de las claves almacenadas en la base de datos
como md5 no son útiles al atacante para conocer contraseñas que le permitirían el
acceso al sistema ya que no es posible conocer la cadena de texto original.
13.2 PÁGINAS PRIVADAS Y LOS SISTEMAS DE AUTENTICACIÓN
La autenticación es el proceso por el cual la identidad de un usuario en el sistema
es validada. Comúnmente el procedimiento involucra un nombre de usuario y una
contraseña a revisar. Una vez autenticado el usuario es registrado (logueado) como
un usuario que se ha autenticado. Muchas aplicaciones tienen recursos que son
accesibles sólo para los usuarios autenticados, recursos que son accesibles
únicamente para los administradores y recursos totalmente públicos.
El control de acceso debe encontrarse totalmente integrado al diseño original. No
debe ser algo improvisado sobre una aplicación ya existente.
13.3 ATAQUES DE FUERZA BRUTA
Un ataque de este tipo agota todas las posibilidades sin preocuparse por cuales
opciones son las que tienen mayor probabilidad de funcionar. En los términos del
control de acceso, generalmente encontramos al atacante intentando registrarse
64
mediante un gran número de pruebas. En algunos casos el atacante puede conocer
nombres de usuario válidos y la contraseña es la única parte que se trata de
adivinar.
Limitar el número de intentos que se le permite al usuario tratar de adivinar es una
medida efectiva en contra de estos ataques, pero tiene por desventaja de poder
afectar el uso del sistema a usuarios legítimos. Una propuesta un poco más
considerada con el usuario seria intentar encontrar patrones en las peticiones
enviadas por el atacante y únicamente bloquear el uso de la cuenta para peticiones
que cumplan con dicho patrón, de esta forma se interfiere menos el uso al usuario
legítimo.
Otra opción sería imponer un intervalo de tiempo pequeño (ejemplo 15 segundos)
que se debe esperar para poder intentar registrarse en el sistema de nuevo después
de una falta en la autenticación. De esta manera, se niega el acceso sin importar si
se presentaron las credenciales fue correcta, por supuesto que no se le dice al
atacante la razón por la que se le negó el acceso para evitar lo intente de nuevo
cuando haya terminado el plazo de espera. Trabajando de esta forma, se busca
reducir el tiempo útil que tiene el atacante para intentar adivinar las credenciales de
acceso.
13.4 ESPIONAJE DE CONTRASEÑAS (PASSWORD SNIFFING)
Cuando un atacante tiene los medios para analizar el tráfico entre los usuarios y el
servidor de la aplicación, debemos preocuparnos por la exposición que pueden
tener los datos en el trayecto, sobre todo cuando se trata de credenciales de acceso.
Una manera efectiva de prevenir este tipo de problemas es usar SSL para proteger
los contenidos enviados en las peticiones y respuestas en HTTP. Debemos
considerar utilizar esta tecnología tanto para cuando se envíen las credenciales de
acceso como los identificadores de una sesión ya establecida, de esta forma
evitamos un secuestro de la sesión.
Usar SSL para proteger el envío de HTML es además una medida útil para brindar
confianza a los usuarios de enviar sus datos cuando ven en su navegador el uso de
https. Pero como se vio en la lección “Mitos de seguridad en aplicaciones web”, ésta
sola medida no es suficiente.
65
13.5 REGISTROS PERSISTENTES
Cuando un usuario permanece en el estado de registrado después de un tiempo no
razonable (cuando la sesión expiró por ejemplo), tenemos un problema de registros
persistentes. Este tipo de problemas disminuyen la seguridad de nuestro
mecanismo de autenticación. Generalmente estos problemas son causados por una
cookie persistente, o un ticket enviado al usuario para hacer referencia a la sesión
de registro establecida que no se considera como expirado jamás o que no cambia
en cada nuevo registro establecido por el usuario.
Si el ticket de acceso permanece constante para cualquier sesión establecida
tenemos un problema serio, la manera más sencilla de evitarlo es haciéndolo
dependiente de una variable aleatoria.
Otra medida recomendable es requerir la contraseña del usuario cuando vaya a
realizar alguna tarea administrativa importante en el sistema. Con este esquema se
permite el acceso únicamente a los recursos que no son tan sensibles.
LECCIÓN 14: VALIDACIÓN DE ENTRADAS:
La debilidad de seguridad más común en aplicaciones web es la falta de validación
apropiada de las entradas del cliente o del entorno. Teniendo en cuenta una serie
de indicaciones y consejos a la hora de codificar nuestras aplicaciones podremos
evitar problemas como la inyección de código SQL, de comandos, LDAP, XPath,
XML o por XSS.
Esta debilidad lleva a casi todas las principales vulnerabilidades en las aplicaciones,
tales como intérprete de inyección, ataques locale/Unicode, ataques al sistema de
archivos y desbordamientos de memoria. Nunca se debe confiar en los datos
introducidos por el cliente, ya que podría manipularlos. Hay que garantizar que la
aplicación sea robusta contra todas las formas de ingreso de datos, ya sea obtenida
del usuario, de la infraestructura, de entidades externas o de sistemas de base de
datos.
Existen vulnerabilidades asociadas a la validación de los datos:
66
Vulnerabilidad de la integridad de los datos: El atacante manipula los datos
introduciendo intencionadamente datos erróneos que manipulan la función de
negocio.
Violación del formato de los datos: Un atacante consigue introducir datos sin la
sintaxis correcta, fuera de los límites de longitud, que contenga caracteres no
permitidos, con signo incorrecto o fuera de los límites del rango. Esto provoca un
mal funcionamiento de la aplicación.
Incumplimiento de las reglas de negocio: Se introducen datos que no cumplen
con las reglas de negocio. Lo que provoca un comportamiento no esperado de la
aplicación.
HTML resulta adecuado para aplicaciones simples, pero es poco adecuado para
aplicaciones complejas:




Conjuntos de datos complejos.
Datos que deben ser manipulados de formas diversas.
Datos para controlar programas.
Sin capacidad de validación formal.
Ante todo esto, el W3C desarrolló un nuevo lenguaje (XML), que proporciona:
Extensibilidad: se pueden definir nuevas marcas y atributos según sea necesario.
Estructura: se puede modelar cualquier tipo de datos que esté organizado
jerárquicamente.
Validez: podemos validar automáticamente los datos (de forma estructural).
Independencia del medio: podemos publicar el mismo contenido en multitud de
medios.
XML no es un lenguaje, sino un meta-lenguaje que permite definir multitud de
lenguajes para propósitos específicos. Estas definiciones, e incluso las definiciones
de programas de traducción y transformación de ficheros XML, se definen en XML,
lo que da una muestra de la potencia de XML. En XML se ha definido gran número
de lenguajes. De hecho, el fichero de configuración de algunos de los programas
más usados en la web (Tomcat, Roxen, etc.) está definidos con XML. Hay muchos
ficheros de datos, de documentos, etc., que también lo usan para su definición.
Algunos de los lenguajes definidos con XML más conocidos son:


SVG (scalable vector graphics).
DocBook XML (Docbook-XML).
67




XMI (XML metadata interface format).
WML (WAP markup language).
MathML (mathematical markup language).
XHTML (XML hypertext markup language).
XML posibilita la comprobación automática de la correcta forma de un documento,
pero sin información adicional es imposible comprobar la validez de éste a partir del
propio documento. Para ello, el W3C ha desarrollado algunos estándares de XML
que permiten validar un documento a partir de una especificación formal de cómo
debe ser éste. Dichos estándares son DTD y XSchema.
DTD es un estándar antiguo, derivado de SGML y que adolece de algunas
deficiencias graves, siendo la más grave de ellas el hecho de no estar escrito en
XML. XSchema, por otro lado, es un estándar relativamente moderno, muy potente
y extensible, que además está escrito en XML íntegramente. Muchas de las
entradas de validación de datos se apoyan en este estándar.
LECCIÓN 15: SQL IJECTION:
La inyección SQL (Structured Query Language) Injection es un ataque en el que
se inserta código SQL o como anexo en los parámetros de entrada de la solicitud
de usuario que posteriormente se pasan a un servidor back-end de SQL Server
para su análisis y ejecución. Cualquier procedimiento que construye declaraciones
SQL podría ser vulnerable, ya que la naturaleza diversa de SQL y los métodos
disponibles para la construcción que proporcionan una gran cantidad de
codificación.
Un ataque menos directo inyecta código malicioso en las cadenas que están
destinados para el almacenamiento en una tabla o como metadato. Cuando estas
cadenas son almacenadas posteriormente se concatenan en una tabla dinámica
que ejecuta comandos inesperados y sentencias de SQL y es allí donde el código
malicioso es ejecutado en la aplicación web.
Cuando se utiliza un servidor SQL para ejecutar comandos que interactúan con el
sistema operativo, el proceso se ejecutará con los mismos permisos que el
componente que ejecutó el comando (por ejemplo, servidor de base de datos,
servidor de aplicaciones o servidor web), que a menudo suelen ser sentencias,
sesione se instrucciones con información muy privilegiada.
68
Mediante un ejemplo sencillo se puede interpretar esta vulnerabilidad: Si un usuario
hace una consulta a un sitio web (tienda online) para ver todos los productos que
cuesten menos de $ 100, a través de la siguiente URL:
http://www.victim.com/products.php?val=100
El ejemplo de la URL anterior utiliza los parámetros GET en lugar de POST de parámetros
para facilitar la ilustración. Parámetros POST son tan fáciles de manipular, sin embargo,
esto generalmente implica el uso de otro componente, como una herramienta de
manipulación de tráfico, navegador Web plug-in o aplicación proxy en línea
El atacante intenta inyectar sus propios comandos SQL modificando el parámetro
de entrada “val” añadiendo la cadena 'OR '1' = '1 a la URL:
http://www.victim.com/products.php?val=100’ OR ‘1’=’1
Esta vez, la sentencia de SQL que el script de PHP genera y ejecuta, devolverá
todos los productos en la base de datos, independientemente de su precio. Esto se
debe a que se ha modificado la lógica de la pregunta. Esto sucede porque los
resultados de la instrucción del operando de consulta siempre devuelve “true”, es
decir, 1 siempre será igual a 1. Esta es la consulta que fue construida y ejecutada:
SELECT * FROM ProductsTbl WHERE Price < '100.00' OR '1'='1' ORDER BY ProductDescription;
Hay muchas maneras para aprovechar las vulnerabilidades de inyección SQL para
lograr una gran variedad de objetivos, el éxito del ataque es generalmente altamente
dependiente de la base de datos subyacente y de los sistemas interconectados que
están bajo ataque. A veces puede tomar una gran cantidad de habilidad y
perseverancia para explotar una vulnerabilidad en todo su potencial.
En el ejemplo anterior demuestra cómo un atacante puede manipular una sentencia
SQL creada dinámicamente que se forma a partir de la entrada que no se ha
validado o codificada para llevar a cabo acciones que el desarrollador de una
aplicación no previó.
69
El ejemplo, sin embargo, tal vez no ilustra la eficacia de esa vulnerabilidad; después
de todo, sólo se utiliza el vector (vec) para ver todos los productos en la base de
datos, y que un usuario legítimo podría haberlo hecho mediante la consulta a la
misma aplicación. Si esa misma aplicación fuera administrada de forma remota
mediante utilizando un sistema de gestión de contenidos (CMS) (Un CMS es una
aplicación Web que se utiliza para crear, editar, gestionar y publicar contenido en un sitio Web, sin
necesidad de tener un conocimiento en profundidad de la capacidad de codificar o en HTML ).
Se
podría acceder a la aplicación CMS mediante la siguiente URL:
http://www.victim.com/cms/login.php?username=foo&password=bar
La aplicación CMS requiere que usted proporcione un nombre de usuario y
contraseña para poder acceder a su funcionalidad de administrar y modificar el sitio.
Si un atacante digita un nombre de usuario y contraseña errados, la aplicación
devuelve un error "nombre de usuario o contraseña incorrecta, por favor, inténtelo
de nuevo". Aquí está el código para el script login.php que devuelve el error:
// connect to the database
$conn = mysql_connect("localhost","username","password");
// dynamically build the sql statement with the input$query = "SELECT userid FROM CMSUsers
WHERE user = '$_GET["user"]' " .
"AND password = '$_GET["password"]'";
// execute the query against the database
$result = mysql_query($query);
// check to see how many rows were returned from the database $rowcount =
mysql_num_rows($result);
// if a row is returned then the credentials must be valid, so
// forward the user to the admin pages if ($rowcount != 0){ header("Location: admin.php");}
// if a row is not returned then the credentials must be invalid else { die('Incorrect username or
password, please try again.')}
El script login.php crea dinámicamente una sentencia SQL que devuelve un
conjunto de registros si un nombre de usuario y contraseña correspondiente es
digitado. La sentencia SQL que el script de PHP genera y ejecuta, se ilustra más
claramente en la consulta siguiente:
70
SELECT userid
FROM CMSUsers
WHERE user = 'foo' AND password = 'bar';
Devolverá el ID de usuario que corresponde al usuario y los valores de la
contraseña si los datos introducidos coinciden con un valor correspondiente
almacenado en la tabla de CMSUsers
El problema con el código es que el desarrollador de aplicaciones asuma que el
número de registros devueltos cuando la secuencia de comandos se ejecuta
siempre será cero o uno. En el ejemplo anterior la inyección, se utilizó el vector
explotable para cambiar el significado de la consulta SQL para devolver siempre el
valor “true”. Si utilizamos la misma técnica con la aplicación de la CMS, podemos
hacer que la lógica de la aplicación falle. Añadiendo la cadena 'OR '1' = '1 a la
siguiente dirección URL, la sentencia SQL que el script PHP construye y ejecuta en
ese momento, devolverá todos los identificadores de usuario para todos los usuarios
de la URL que estén en la tabla CMSUsers:
http://www.victim.com/cms/login.php?username=foo&password=bar’ OR ‘1’=’1
Todos los identificadores de usuario se devuelven debido a que se altera la lógica
de las consultas o peticiones de acceso. Esto sucede porque los resultados de la
instrucción del operando de la consulta siempre se devuelven como verdaderas, es
decir, 1 siempre será igual a 1. Esta es la consulta que se ejecuta:
SELECT userid
FROM CMSUsers
WHERE user = 'foo' AND password = 'password' OR '1'='1';
La lógica de la aplicación significa que si la base de datos devuelve más de cero
registros, debemos haber entrado en las credenciales de autenticación correctas y
deben ser redirigido y con acceso al script admin.php. Con esto se ha modificado la
lógica de la aplicación y la inyección de código ha surtido efecto.
Ahora especifiquemos ¿Cómo un intruso inyectará una sentencia SQL en
lugar de colocar el nombre de usuario, Password y cuenta?:
71
En la figura 20 se muestra una web con formularios de ingreso que podrían ser
vulnerables:
Figura 20: Formulario de validación de datos
Fuente: El Autor
Si los campos de datos, la aplicación y el gestor de datos no están validados y
filtrados (no escapa a los caracteres especiales) y asegurados, se podrá incluir una
comilla simple ‘y seguido a ella, el resto de lo que será interpreta do por el gestor de
base de datos como código SQL.
SELECT id
FROM login
WHERE usuario = ‘admin’´
AND clave = ‘’’OR
AND cuenta = 46789675
Un parámetro no esperado, como esta comilla, cambia el comportamiento de la
aplicación. De este modo , si el usuario es el admin y tiene un Password / con la
72
condición, si 1 es igual a 1(que de hecho lo es), éste será válido y tendrá acceso a
la aplicación web o a la intranet en la mayoría de casos.
¿Cómo saber que determinado campo de datos o URL, es vulnerable a la
inyección de código SQL?
Esto se logra intentando escribir y enviar una comilla simple en el campo del
formulario para obtener determinado error del sistema que es generado por la base
de datos del sistema. Hay otros métodos que son propios de cada navegador o
aplicación de ataque o de monitoreo.
¿Cómo buscar en Internet sitios web
con formularios de acceso a
aplicaciones web tentativamente vulnerables?
En un buscador se pueden dar estas opciones de búsqueda que darán como
resultados muchos formularios de acceso, links o campos de consulta de datos para
ver dichos errores.
inurl:login.asp ó inurl:buscar.asp ó site:.ar ó password.asp ó intranet ó
contraseña.asp ó clave.asp ó intitle:”acceso restringido” ó site.asp
Incluso en muchos casos, son tan vulnerables que la aplicación leva al usuario al
salto de la famosa “pregunta secreta” para restaurar la contraseña.
15.1 VARIANTES DE SINTAXIS:
Las variantes de sintaxis (en inyección) varían según el gestor de base de datos
(MS-SQL, Mysql, Oracle, PostgreSQL).
15.2 OTRAS CLASES DE INYECCIÓN:
Las hay del tipo ORM, LDAP, XML (hacking SOAP), SSI, XPATH, e IMAP/SMTP.
El proyecto OWASP documenta cada tipo de vulnerabilidad en el sitio web oficial.
73
GLOSARIO DE TÉRMINOS:
Abuso de funcionalidad: Una técnica de ataque que usa las características
y la funcionalidad de un sitio web para consumir, estafar o evadir el
acceso al sitio. También puede tener referencia con el término (DoS).
Autenticación: El proceso de verificación de la identidad o localización de un
usuario, servicio o aplicación. La autenticación se realiza utilizando al menos
uno de tres mecanismos: "algo que tienes", "algo que sé "o" algo que es”. La
aplicación puede autenticar y proporcionar diferentes servicios basados en la
ubicación, método de acceso, el tiempo de permanencia y los hábitos de uso de la
aplicación web.
Autenticación Básica: Una forma simple de autenticación del cliente
apoyado en HTTP. El cliente HTTP envía un encabezado con la solicitud al servidor
web que contiene un nombre de usuario y la contraseña codificada en Base64.Si
la combinación de nombre de usuario / contraseña es válida, entonces se da el
acceso al recurso solicitado.
Autorización: La determinación de los recursos que un usuario, un servicio
o aplicación tienen como permisos de acceso. Recursos accesibles que pueden
ser URL, archivos, directorios, bases de datos, servelets, caminos de ejecución.
ADDRESS RESOLUTION PROTOCOL (ARP): protocolo de la familia TCP/IP que
asocia direcciones IP a direcciones MAC.
AGENTE: Programa que permite a un dispositivo responder a solicitudes SNMP.
APACHE: Es un software libre servidor HTTP de código abierto para plataforma
Unix (BSD, GNU/Linux, etc.), Windows, Macintosh y otras, que implementa el
protocolo HTTP/1.1, y la noción del sitio virtual.
ASN (Abstract Syntax Notation): Lenguaje utilizado para definir tipos de datos.
Backup File Disclosure: Divulgación del archivo de copia de seguridad:
(Obsoleto). Actualmente se usa el término: "Ubicación de archivo predecible".
Brute Force: Un proceso automatizado de prueba y error utilizado para adivinar
el "secreto" de la protección de un sistema. Ejemplos de estos secretos son
74
nombres de usuario, contraseñas o claves criptográficas. También puede asociarse
a términos como: "Autenticación", "Autenticación insuficiente", "Password
Recovery Sistema "," La débil validación de recuperación de contraseña ".
BROADCAST: Transmisión de un paquete que será recibido por todos los
dispositivos en una red.
Buffer Overflow: Desbordamiento de Buffer: Una técnica de explotación que altera
el flujo de una aplicación sobrescribiendo partes de la memoria. Desbordamientos
de búfer es una causa frecuente de un mal funcionamiento del software. Si los
datos escritos en un búfer superan su tamaño, el espacio de memoria adyacente
se corromperá y normalmente producen un fallo. Un atacante puede ser capaz de
utilizar esta situación de desbordamiento y alterar el proceso del flujo de una
aplicación. Si sobrecarga el buffer y se sobrescriben por ejemplo los punteros en
la pila de memoria, esta acción podría ser utilizada para ejecutar órdenes erradas
al sistema operativo. ".
CGI Scanner: Programa de seguridad automatizada que busca vulnerabilidades
en servidores web y en aplicaciones web. Su uso muchas veces no va más allá de
probar una serie de peticiones HTTP contra conocidas cadenas de CGI
Client-Side Scripting: Función de navegador Web que extiende la funcionalidad
e interactividad del lenguaje de marcado de hipertexto (HTML) est´tico en las
páginas web. Ejemplos de lenguajes de script del lado del cliente son JavaScript,
JScript y VBScript. Véase también "controles ActiveX", "Java Applets ".
CGI:
Acrónimo:
(Common
Gateway
Interface):
Programación
estándar para el software para conectar y ejecutar aplicaciones que residen
en los servidores web. Véase también "Aplicación Web", "Servidor de
aplicaciones",
"Servidor Web
Controles ActiveX: Controles ActiveX son programas informáticos basados en la
Component Object Model (COM) y anteriormente conocido como OLE
controles. Los controles ActiveX son portables y reutilizables, y pueden ser
utilizados por muchos lenguajes de programación. Ellos son ampliamente utilizados
por las aplicaciones web para extender su funcionalidad (por ejemplo: el sitio
Windows Update) Véase también "Java", "applets Java", "JavaScript", "Web
Browser ".
75
Content Spoofing: “La suplantación de contenido”: Una técnica de ataque utilizada
para engañar a un usuario para que acceda a contenidos falsos creyendo que son
datos legítimos.
Cookie: Pequeña cantidad de datos enviados por el servidor web, a una web de
un cliente, que puede ser almacenada y recuperada en un momento posterior.
Típicamente se utilizan cookies para realizar un seguimiento de un estado de los
usuarios a medida que usan, navegan o interactúan con un sitio web.
Cookie Poisoning: (Obsoleto). Vea “Manipulación Cookie”.
Cross-Site Scripting: (acrónimo - XSS) Una técnica de ataque que obliga a un
sitio web para hacerse eco de los datos suministrados por el cliente, que se
ejecutan en un navegador web por parte del usuario. Cuando un usuario interactúa
entre varios sitios y aplicaciones que están haciendo eco de datos entre sí, el
atacante tendrá acceso a todo el contenido navegador web (cookies, historial,
versión de la aplicación, etc). Véase también "Client-Side Scripting".
CSMA/CD (Carrier Sentido acceso múltiple / Detección de Colisión) es el protocolo
usado en Ethernet en red para garantizar que sólo un nodo de red se transmite en
el cable de red en cualquier momento.
CONFIDENCIALIDAD: Que la información solo sea vista por los lentes involucrados
en la comunicación y que un tercer no pueda ingresar.
CONTROL DE ACCESO Y AUTORIZACIÓN: el proceso de determinar los
recursos y servicios que puede usar una entidad.
CORTAFUEGOS: Elemento de prevención que realizara un control de acceso para
proteger una red de los equipos del exterior (potencialmente hostiles).
DENEGACIÓN DE SERVICIO (DoS): ataque que hace una apropiación exclusiva
de un recurso o servicio con la intención de evitar cualquier acceso a terceras
partes. En inglés, deny of service.
Debug Commands: Los comandos de depuración: Son características de
depuración de aplicaciones o comandos que ayudan a identificar los errores de
programación durante el proceso de desarrollo de software.
Directory Traversal:
Una técnica utilizada para explotar sitios web al
acceder a los archivos y los comandos más allá del directorio raíz de los
documentos que forman la estructura del sitio. La mayoría de los sitios web deben
restringir el acceso de usuarios a una parte específica del sistema de archivos que
normalmente se denomina “el directorio raíz” de documentos o de raíz CGI
76
directorio.
Estos
directorios
contienen
los
archivos
ejecutables
destinados al uso público. En la mayoría de los casos, un usuario no debería poder
acceder a los archivos más allá de este punto.
DESBORDAMIENTO DE BUFFER: posibilidad de corromper la pila de ejecución
para modificar el valor de retorno de una llamada a función y provocar la ejecución
de código arbitrario.
DISPONIBILIDAD: Los servicios y la información deben, en todo momento, estar
disponibles.
DNS: Servicio de Nombres de Dominio.
DoS: (de las siglas en inglés Denial of Service), Ataque de Denegación de servicio
DDoS: (de las siglas en inglés Distribuited Denial of Service), Ataque de Denegación
de servicio Distribuido
Encoding Attacks: Los ataques de codificación: una técnica que ayuda a la
explotación de un ataque de cambiar el formato de los datos proporcionados por el
usuario para omitir la comprobación de aplicación de filtros. Véase también " Null
Injection".
Examen de directorios: (Obsoleto) Véase "Indexación de Directorio".
Enumeración de Directorio: (Obsoleto) Consulte "Ubicación de archivo
predecible"
Expiración de sesión insuficiente: Cuando un sitio web permite a un
atacante reutilizar credenciales de sesiones viejas o anteriores para
autorización y poder tener ingreso.
Form Field Manipulation: Manipulación de campos en formularios: La alteración
o modificación de formularios HTML. Los valores del campo de entrada que se
ingresan mediante HTTP, sirven para explotar los problemas de seguridad en una
aplicación web. Véase también "Cookie”
ESCÁNER DE VULNERABILIDADES: aplicación que permite comprobar si un
sistema es vulnerable a un conjunto de deficiencias de seguridad.
EXPLOIT: aplicación, generalmente escrita en C o ensamblador, que fuerza las
condiciones necesarias para aprovecharse de un error de programación que
permite vulnerar su seguridad.
77
EXPLORACION DE PUERTOS: técnica utilizada para identificar los servicios que
ofrece un sistema.
EXPLOTACIÓN DE UN SERVICIO: actividad realizada por un atacante para
conseguir una escalada de privilegios, abusando de alguna deficiencia del servicio
o del sistema.
FINGERPRINTING: Huella identificativa.
FIREWALL: Un equipo que impone un conjunto de directivas de seguridad que
restringen de forma severa el acceso al sistema y a los recursos.
Formato de ataque String: Una técnica de explotación que altera el flujo de una
aplicación mediante operaciones de biblioteca de formato de cadenas para acceder
a otra instancia o momento de la aplicación.
FRAGMENTACIÓN IP: proceso de división de un datagrama IP en fragmentos de
menor longitud.
HERRAMIENTA DE MONITOREO JFFNMS: Es un sistema de gestión y
monitorización de red designando para monitorizar una red IP, puede ser utilizado
para monitorizar cualquier dispositivo SNMP, router, switch, servidor, puerto TCP o
cualquier elemento siempre que se programe una extensión adecuada a dicho
elemento JFFNSM.
HIDS: Sistemas de detección de intrusos de Ordenador
HUELLA IDENTIFICATIVA: información muy precisa que permite identificar un
sistema o una red en concreto. En inglés, fingerprinting.
ICMP: Internet Control Message Protocol.
IANA: Internet Assigned Numbers Authority
Indexación de Directorio: Una característica común a los servidores web más
populares, que expone el contenido de un directorio cuando no está presente la
página de índice. Véase también "Ubicación del archivo predecible".
Insuficiente Autenticación: cuando un sitio web permite a un atacante
acceder a contenido sensible o a sus funcionalidades sin verificar su
identidad. Véase también "Autenticación".
Insuficiente Autorización: Cuando un sitio web permite a un atacante
acceder a contenido sensible o a sus funcionalidades que deberían requerir
mayores restricciones de acceso y control. Véase también "Autorización".
78
IDS (Intrusion Detection System): Sistema de detección de Intrusos. Es una
herramienta que permite monitorear el comportamiento y el uso que se le da a los
recursos en una máquina y detectar si alguien está haciendo algo indebido.
IEEE: Tecnología desarrollada por Apple Computer en 1986 que permite transmitir
información a alta velocidad. Fue adoptado como estándar en 1995 y es similar al
puerto USB.
IEEE 802.3 proporciona una LAN estándar desarrollada originalmente por Xerox y
ampliada. Define dos categorías: banda base (específica una señal digital) y banda
ancha (especifica una señal analógica). IEEE define únicamente una especificación
para la categoría de banda ancha. Sin embargo, la restricción de la máxima longitud
del cable puede cambiar usando dispositivos de red tales como repetidores o
puentes.
INTEGRIDAD: los datos reflejen la realidad y que correspondan con lo que debe
ser y no ha sido modificadas indebidamente.
INTERNET CONTROL MESSAGE PROTOCOL (ICMP): protocolo encargado de
realizar el control de flujo de los datagramas IP que circulan por la red.
INTERNET PROTOCOL (IP): protocolo para la interconexión de redes.
INTEGRIDAD: Los datos reflejan la realidad y que correspondan con lo que debe
ser y no ha sido modificadas indebidamente.
Java:
Lenguaje
de
programación
popular
desarrollado
por
Sun
Microsystems (tm). Véase también "ActiveX controls", "Navegador Web",
"JavaScript", "Client-Side Scripting".
Java Applets: Un applet es un programa escrito en un lenguaje de programación
como Java que puede ser incluido en una página web. Cuando un
navegador web tiene habilitado java, y la página contiene applets , el
código es ejecutado por la máquina virtual de Java (JVM). Véase también "Web
Browser "," Java "," ActiveX "," JavaScript "," Client-Side Scripting ".
JavaScript: Lenguaje de scripting del lado cliente utilizado por el navegador web,
para crear contenido dinámico página web. Véase también "ActiveX", "Java
Applets "," Client-Side Scripting ".
LDAP Inyección: Una técnica para la explotación de un sitio web mediante la
alteración de backend sentencias LDAP a través de la manipulación de entrada de
79
la aplicación. Al igual que en la metodología de inyección SQL. Véase también
"Parámetro Manipulación "," Manipulación de campos de formulario”.
MAC: Media Access Control
Manipulación Cookie: La alteración o modificación de los valores de las cookies
del navegador web del cliente, para explotar aspectos de seguridad dentro de una
aplicación web. Los atacantes normalmente manipulan los valores de los cookies
para autenticarse y realizar fraudes a la aplicación web. Este es un típico ejemplo
de establecer por defecto la configuración predeterminada de los navegadores .
Véase también "Cookie".
Manipulación de Nombre de Archivo: Una técnica de ataque usada para explotar
sitios web mediante la manipulación de los nombres de archivo de URL para
provocar errores de aplicación, descubrir el contenido oculto, o visualizar el código
fuente de una aplicación. Véase también "Ubicación del archivo predecible".
MODEM ADSL: Modula las señales enviadas desde la red local para que puedan
transmitirse por la línea ADSL y demodula las señales recibidas por ésta para que
los equipos de la LAN puedan interpretarlos. De hecho, existen configuraciones
formadas por un módem ADSL y un router que hacen la misma función que un router
ADSL.
MTU: Maximum Transfer Unit
MySQL: Es un sistema de gestión de base de datos relacional y multiusuario ubica
las tablas en ficheros diferenciados, es recomendable para desarrollos que
necesiten manejar numerosos registros y sesiones simultaneas.
NIDS: Sistema de detección de intrusos de Red.
NMAP: Programa de código abierto que abierto que sirve para efectuar rastreo de
puertos TCP y UDP. Se usa para evaluar la seguridad de sistemas informáticos así
como para descubrir servicios o servidores en una red informática.
NMS (Network Management Station): estación de red encargada de gestionar
varios dispositivos de red.
OID (Object ID): identifica de manera única cada objeto representado en la MIB y
es una secuencia de números enteros no negativos separados por un punto.
OSI: El Modelo OSI es un lineamiento funcional para tareas de comunicaciones y,
por consiguiente, no especifica un estándar de comunicación para dichas tareas.
80
OWASP:(The Open Web Application Security Project).
PDU (Protocol Data Unit): define la estructura de la información que va a ser
enviada por la red.
PHP: Es Un lenguaje de programación interpretado, diseñado originalmente para la
creación de páginas web dinámicas. Es usado principalmente en interpretación del
lado del servidor (server–side scripting) pero actualmente puede ser utilizado desde
una interfaz de línea de comandos o en la creación de otros tipos de programas
incluyendo aplicaciones con interfaz grafica.
PUERTA DE ENLACE: Es La que proporciona salida hacia el exterior a una red
local.
ROUTER: Es un dispositivo que permite conectar uno o varios equipos o incluso
una red de área local (LAN) a Internet a través de una línea telefónica con un servicio
ADSL.
Revelación de Información: Cuando un sitio web revela datos sensibles, tales
como comentarios de los desarrolladores o mensajes de error, lo que ayuda a un
atacante a explotar el sistema.
Servidor de aplicaciones: Un servidor de software, normalmente a través de
HTTP, que tiene la capacidad de ejecutar aplicaciones web dinámicas. También se
conoce como middleware.
RRDTOOL: Herramienta que trabaja con una base de datos que maneja
planificación según Round-Robin. Esta técnica trabaja con una cantidad de datos
fija, definida en el momento de crear la base de datos, y un puntero al elemento
actual. Su finalidad principal es el tratamiento de datos temporales y datos seriales
como temperaturas, transferencias en redes, cargas del procesador, entre otros.
SNMP: (Simple Network Managment Protocol): usado para administrar la
configuración de dispositivos de red desde una estación de trabajo.
SMI (Structure of Management Information): define agrupaciones, nombres, tipos
de datos permitidos y la sintaxis para escribir MIB’s.
SYN: Bit de control dentro del segmentoTCP.
SYN FLOODING: Ataque de denegación de servicio que se basa en no
complementar intencionadamente el protocolo de intercambio de TCP.
TCP: Transmission Control Protocol.
81
TCP/IP: Es la base de Internet, y sirve para enlazar computadoras que utilizan
diferentes sistemas operativos, incluyendo PC, minicomputadoras y computadoras
centrales sobre redes de área local (LAN) y área extensa (WAN)
TIA:
Telecommunications Industry Association.
TRANSMISSION CONTROL PROTOCOL (TCP): Protocolo de transporte de la
arquitectura de protocolos TCP/IP.
TTL: Time To Live
UDP: User Datagram Protocol.
USER DATAGRAM PROTOCOL (UDP): protocolo de transporte de la arquitectura.
USM (User-based Security Model): modelo de seguridad utilizado por SNMPv3
para administrar el envío de mensajes SNMPv3.
Ubicación de Archivo Predecible: Una técnica que se utiliza para acceder a los
datos ocultos de un sitio web o a su contenido o funcionalidad, haciendo conjeturas,
de forma manual o automáticamente a los los nombres y ubicaciones de los
archivos. Los lugares pueden incluir directorios, archivos de configuración de copia
de seguridad archivos, archivos temporales, etc
Validación de proceso insuficiente: cuando un sitio web permite a un
atacante para eludir o evadir el control de flujo previsto de un
aplicación.
VACM (View-based Access Control Model): modelo de control de acceso que
permite administrar quien tiene acceso a qué información en la MIB.
WINPCAP: Es el mejor motor de captura de paquetes y filtrado de muchas de las
herramientas de las herramientas de red comerciales y de código abierto,
incluyendo analizadores de protocolos, monitores de red, sistemas de detección de
intrusos de red.
82
ANEXOS
ANEXO 1:
OWASP Top 10. Traducido al español: Documento pdf de 22p.
Copyright © 2003 – 2010 Fundación
OWASP
Este documento es publicado bajo la licencia Creative Commons Attribution ShareAlike 3.0. Para
cualquier reutilización o distribución, usted debe dejar en claro a otros los términos de la licencia
sobre este trabajo.
ANEXO 2: Informe que compara las licencias de desarrollo, la tecnología y las
fuentes de los diferentes escáneres.
ANEXO 3: Informes comparativo de la detección de vulnerabilidades de los distintos
escáneres probados:
ANEXO 4: Informe que compara las características complementarias de detección
de vulnerabilidad en los buscadores probados:
ANEXO 5: Informe donde se comparan las características de usabilidad, cobertura
y estabilidad de los buscadores probados:
83
FUENTES DOCUMENTALES

LUIS GÓMEZ FERNÁNDEZ Y ANA ANDRÉS ÁLVAREZ . Guía de aplicación de la Norma UNEISO/IEC 27001 sobre seguridad en sistemas de información para pymes. 2.ª edición Autores:
© AENOR (Asociación Española de Normalización y Certificación), 2012 Todos los derechos
reservados. AENOR. ISBN: 978-84-8143-7 áÜ - ß Impreso en España Edita: AENOR Maqueta
y diseño de cubierta: AENOR
Disponible en internet http://site.ebrary.com/lib/unadsp/Doc?id=10637105&ppg=2 Con
acceso Noviembre de 2012

Miguel Colobran Huguet, Josep Maria Arqués Soldevila y Eduard Marco Galindo. Editorial
UOC Primera edición en lengua castellana: noviembre 2008. España: Editorial UOC, 2008.
p 4.
Disponible en Internet < http://site.ebrary.com/lib/unadsp/Doc?id=10638510&ppg=5>
con acceso Octubre de 2012

HOWARD, MICHAEL LEBLANC, DAVID. 19 puntos críticos sobre seguridad de software:
fallas de programación y cómo corregirlas. Pág: 305. Editorial: McGraw-Hill Professional
Publishing Ubicación: México. Fecha de publicación: 12/2010. Idioma: es pISBN:
9789701058985

DÍAZ, GABRIEL MUR, FRANCISCO SANCRISTÓBAL, ELIO. Seguridad en las comunicaciones y
en la información. Páginas: 473. Editorial: UNED - Universidad Nacional de Educación a
Distancia. Ubicación: España. Fecha de publicación: 2004. Idioma: es
Número de clasificación de la Biblioteca del Congreso: eISBN: 9788436247893

JUSTIN, CLARKE. SQL Injection Attacks and Defense. Syngress Publishing, Inc. Elsevier,
Inc. 30 Corporate Drive ISBN 13: 978-1-59749-424-3.

CUI-MEI, B. Intrusion Detection Based on One-class SVM and SNMP MIB data.
Shandong University of Technology Zibo. China 2009. Fifth International
Conference on information Assurance and Security, p. 346-351.

SCHUBA, C; KRSUL, I; KUHN, M; SPAFFORD, E; SUNDARAM, A y
ZAMBONI,D. Analysis of Denial of Service Attack on TCP. COAST Laboratory.
Departament of Computer Sciences Purdue University, p. 66-82.

TSUNODA, H ; OHTA, K[b]; YAMAMOTO , A; ANSARI, N [d]; WAIZUMI, Y , y
NEMOTO, Y . Detecting DRDoS attacks by a simple response packet confirmation
mechanism. Computer Comunications Journal. 2008, p. 3299-3307
84

CARVAJAL, A. Introducción a las técnicas de ataque e investigación Forense,
Un enfoque pragmático. Colombia, Agosto de 2007, seg Ed, p. 245

CRUZ, A y TORRES, P. Sistema para Generar Gráficas a Partir de Logs
Tcpdump usando Hadoop. Escuela Superior Politécnica del Litoral. Guayaquil,
Ecuador, p. 59

HIA, H y MIDKIFF, S. Securing SNMP Across Backbone Networks. Bradley
Departament of Electrical and Computer Engineering. Virginia Polytechnic
Insttitute and State University. Virgini USA, p . 190-198.

ZENG, W y WANG, Y. Design and implementation of Server Monitoring System
Based on SNMP. College of Information & Technology, Hebei University of
Economics & Business. Information and Network Management Center, North
China Electric Power University, p. 680-682

HATEFI, F y GOLSHANI, F. A new framework for secure network
management. Departament of Computer Science and Engineering, Arizona State
University, Tempe, USA. 1999, p. 629-636.

BERNSTEIN. J. Daniel. Bernstein's own explanation of SYN Cookies Disponible
en Internet. http://cr.yp.to/syncookies.html
85