L Material12-ModuloSeguridaddeAplicacionesWebUNAD PDF

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD
Escuela de Ciencias Bsicas Tecnologa e Ingeniera

Especializacin en Seguridad Informtica / Curso de Seguridad en Aplicaciones Web
SEGURIDAD EN APLICACIONES WEB
233008
CONTENIDO DIDACTICO DEL CURSO
Elaborado por:
Ing. Carlos Alberto Amaya Tarazona
DUITAMA (Boyac).
Enero de 2013

ASPECTOS DE PROPIEDAD INTELECTUAL Y

VERSIONAMIENTO
GUA DIDCTICA Autor: Carlos Alberto Amaya Tarazona

Ingeniero de Sistemas
Magister en Software Libre y Administracin de Redes y sistemas
Operativos
COMIT DIRECTIVO
Jaime Alberto Leal Afanador
Rector
Gloria Herrera
Vicerrectora Acadmica y de Investigacin
Roberto Salazar Ramos
Vicerrector de Medios y Mediaciones Pedaggicas
Gustavo Velsquez
Decano Escuela de Ciencias Bsicas Tecnologa e Ingeniera
Celia del Carmen Lpez
Secretaria Acadmica Escuela de Ciencias Bsicas Tecnologa e Ingeniera
Alexandra Aparicio
Coordinadora Nacional Ingeniera de Sistemas.
CURSO SEGURIDAD EN APLICACIONES WEB

MATERIAL ACADEMICO
Primera Edicin
@Copy Right
Universidad Nacional Abierta y a Distancia
ISBN
2005
Centro Nacional de Medios para el aprendizaje
2008
Actualizacin: No aplica
2

CONTENIDO
Pg
INTRODUCCION:
UNIDAD I: INTRODUCCION A LA SEGURIDAD EN APLICACIONES WEB
CAPITULO 1: CONCEPTOS BSICOS DE SEGURIDAD EN
APLICACIONES WEB
9
11
11
Leccin 1: INTRODUCCION AL PROTOCOLO HTTP
14
1.1 Caractersticas y Funcionamiento

1.2 Anlisis de una cabecera HTTP
1.3 Mtodos HTTP
1.4 Codificacin de la Informacin
15
16
19
21
Leccin 2: VULNERABILIDADES EN APLICACIONES WEB
22
2.1 Como trabajan las aplicaciones web

2.2 Arquitecturas mas complejas
2.3 Proyecto OWASP y las Vulnerabilidades en Aplicaciones Webs
2.4 Sniffeo y codificacin de cabeceras
2.5 Inyectando cdigo
2.6 CR/LF Injections
2.7 XSS y SQL Injections
2.8 PHP Injections
2.9 Banner Grabbing
2.10 HTTP Fingerprinting
22
23
25
27
28
28
29
30
31
32
Leccin 3: HERRAMIENTAS PARA LA DETECCIN DE VULNERABILIDADES 35

3.1 Fiabilidad de los Analizadores Automticos de Vulnerabilidades
35
3.2 Ventajas y Beneficios
36
3.3 Inconvenientes y Desventajas
37
3.4 Criterios de valoracin para herramientas de seguridad web
38
3.4.1 Herramientas Comerciales
38
3.4.2 Herramientas de Cdigo abierto
39
3.4.3 Herramientas de auditora aplicadas a SQL Injection
40
3.4.4 Herramientas de auditora aplicadas a XSS (Ataques de Cross-Site Scripting)
Leccin 4: MITOS EN LA SEGURIDAD WEB
43
4.1 Auditora y control de vulnerabilidades

4.2 Puntos dbiles
4.3 Tipos de Escaners
45
45
46
Leccin 5: SISTEMA DE LOGS
46
5.1 Formato del fichero de LOG
47
3

5.2 Anlisis del fichero de LOG

5.3 Programas de anlisis de LOGS
48
49
CAPITULO 2: PROTOCOLOS DE SEGURIDAD PARA APLICACIONES WEB 49

Leccin 6: TIPOS DE ANALISIS
51
6.1 Metodologas de anlisis de seguridad web
51
Leccin 7: ESCALACION DE PRIVILEGIOS EN APLICACIONES WEB
52
Leccin 8: AUTENTICACION Y AUTORIZACION
53
8.1 La Autenticacin
8.2 La Autorizacin
53
55
Leccin 9: EJECUCION DE INSTRUCCIONES DE ACCESO
55
9.1 Codificacin y las validaciones de Entrada / Salida

9.2 Gestin de sesiones y usuarios
9.3 Gestin de errores y excepciones
55
56
57
Leccin 10: CONFIGURACION SEGURA DE SERVIDORES
58
10.1 Organizacin del servidor Web

10.2 Organizacin de las aplicaciones Web
58
59
CAPITULO3: DESARROLLO SEGURO DE APLICACIONES
60
Leccin 11: CONCEPTOS GENERALES PARA EL DESARROLLO SEGURO

DE APLICACIONES
60
11.1 Normas bsicas de seguridad
62
Leccin 12: CONTROLES DE AUTORIZACION DE OBJETOS
64
12.1 Listas de control de acceso (ACL)

12.1.1 Configuracin de las ACL
12.1.2 Funciones de la ACL
66
67
67
Leccin 13: CONSIDERACIONES DE SEGURIDAD EN WEB SERVICES
67
13.1 Exposicin de datos

13.2 Pginas privadas y los sistemas de autenticacin
13.3 Ataques de fuerza bruta
13.4 Espionaje de contraseas (Password sniffing)
13.5 Registros persistentes
68
68
68
69
70
Leccin 14: VALIDACION DE ENTRADAS
70
4

Leccin 15: SQL INJECTION

15.1 Variantes de sintaxis
15.2 Otras clases de Inyeccin
72
77
77
UNIDAD 2: ANALISIS Y DISEO SEGURO DE APLICACIONES WEB

CAPITULO 4: AREAS CRITICAS DE DESARROLLO
78
78
Leccin 16: SECUENCIAS DE COMANDOS EN SITIOS CRUZADOS (XSS)
78
16.1 Tipos de vulnerabilidades XSS
78
Leccin 17: PERDIDA DE AUTENTICACION Y GESTION DE SESIONES
81
Leccin 18: REFERENCIA DIRECTA INSEGURA A OBJETOS
83
Leccin 19: ALMACENAMIENTO CRIPTOGRAFICO INSEGURO
84
Leccin 20: RESTRICCIONES DE ACCESO A URL
86
CAPITULO 5: CICLO DE VIDA DE DESARROLLO SEGURO DEL SOFTWARE (SDLC)

Leccin 21: INTRODUCCION A SDLC
88
Leccin 22: Fases de SDLC
89
22.1 Seguridad en la fase de anlisis

22.2 Seguridad en la etapa de diseo
22.3 Seguridad en la codificacin
22.4 Seguridad en la etapa de pruebas
22,5 Seguridad en la implementacin
90
91
92
93
94
Leccin 23: SDLC-IT
95
Leccin 24: APLICACIN DE SDLC
99
Leccin 25: OTRAS VULNERABILIDADES QUE AFECTAN SDLC
101
25.1 Vulnerabilidades de la capa de transporte

25.2 Origen de las vulnerabilidades
25.3 Herramientas de monitoreo
25.4 Sistema de deteccin de intrusos
25.5 Tipos de IDS
25.6 Herramientas de gestin
102
103
104
105
105
107
CAPITULO 6: ATAQUES DE DENEGACION DE SERVICIO (DDoS) APLICACIONES

WEB
Leccin 26: DENEGACION DE SERVICIO (DoS) / (DDoS)
109

26.1 Denegacin De Servicio Distribuido: DDoS

26.2 Denegacin De Servicio Distribuido: DDoS
26.3 Plataformas afectadas
26.4 Caracterizacin de los ataques DoS
26.4.1 Uso de IP Source Spoofing
26.4.2 Similitud de trfico legtimo
110
111
112
112
112
113
Leccin 27: FASES PREVIAS A LA REALIZACION DEL ATAQUE
114
27.1 Actividades previas al ataque (DoS)

27.2 Topologa o distribucin fsica
27.3 Funcin de ICMP en los ataques DoS
27.4 Descubrimiento de usuarios
27.5 Informacin del Dominio
114
115
116
119
119
Leccin 28: FINGERPRINTING
120
28.1 Transmisin en el protocolo de control

28.2 Exploracin de puertos
28.2.1 Exploracin de puertos UDP
28.2.2 Escaneo basado en el protocolo ICMP
28.3 Fragmentacin IP
120
122
123
124
125
Leccin 29: TIPOS DE ATAQUES
129
29.1 ATAQUE TCP/SYN Flooding:

29.2 Ataque Broadcast IP Flooding
29.3 Smurf
29.4 STeardrop
29.5 Snork
29.6 Ataque Distribuido TRINOO /TRIN00
129
133
134
134
136
137
Leccin 30: HERRAMIENTAS QUE AYUDAN A PREVENIR ATAQUES DoS
139
GLOSARIO DE TERMINOS
ANEXOS
FUENTES DOCUMENTALES
143
152
153

LISTADO DE TABLAS
Pg
Tabla 1: Cdigos de estado en HTTP

Tabla 2: Propiedades de los controles de validacin
Tabla 3: Tipos de Amenazas
Tabla 4: Mensajes y cdigos del protocolo ICMP
Tabla 5: Escenario para un ataque DoS TCP/SYN Flooding
Tabla 6: Descripcin de los parmetros del ataque TCP/SYN Flooding
Tabla 7: Herramientas de gestin que ayudan a detectar ataques DoS
Tabla 8: Herramientas utilizadas
20
65
103
118
131
132
141
142
LISTADO DE FIGURAS
Pg
Figura 1: Niveles superiores de OSI. Origen de vulnerabilidades en sitios

web
Figura 2: Tecnologas y protocolos de red modelo OSI
Figura 3: Operaciones de solicitud respuesta con HTTP
Figura 4: Anlisis de cabeceras HTTP
Figura 5: Niveles de comunicacin en aplicaciones web
Figura 6: Arquitectura de cuatro capas en aplicaciones web
Figura 7: OWSP Top 10 2013
Figura 8: Banner deteccin FTP
Figura 9: Banner grabbing por mtodo 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 auditora en escneres de aplicaciones web.
Herramientas comerciales
Figura 13: de auditora en escneres de aplicaciones web.
Herramientas de cdigo
Figura 14: Funciones de auditora en escneres de aplicaciones
web para SQL Injection
Figura 15: Funciones de auditora en escneres de aplicaciones
web para XSS
Figura 16: Categora de Vulnerabilidades
Figura 17: Formato de fichero de Logs
Figura 18: Metodologa de desarrollo seguro
Figura 19: Filtrado de paquetes con ACL
Figura 20: Formulario de validacin de datos
Figura 21: Prdida de Autenticacin
7
13
14
16
18
22
24
26
31
32
33
34
39
40
41
42
44
47
61
66
76
82

Figura 22: Almacenamiento criptogrfico inseguro

Figura 23: Relacin costo tiempo en el desarrollo de aplicaciones web
Figura 24: SDLC
Figura 25: Escenario de un Ataque de Denegacin de servicio (DoS)
Figura 26: Escenario de un Ataque de Denegacin de servicio Distribudo
Figura 27: Estructura de un datagrama IP V 4.0
Figura 28: Estructura de un mensaje ICMP
Figura 29: Cabecera de un datagrama ICMP
Figura 30: Topologa de una red genrica
Figura 31: Mecanismo de tres vas
Figura 32: Datagrama IP No fragmentado
Figura 33: Datagrama IP de 4028 fragmentado con MTU de 1500 bytes
Figura 34: Reensamblado de frames en Wireshark
Figura 35: Fragmentacin y Reensamblado de 4028 bytes con una MTU
de 1500 bytes. Analizado en Wireshark
Figura 36: Fragmentacin Reensamblado TCP. Diagrama Flow Graph
Figura 37: Escenario para un ataque DoS TCP/SYN Flooding
Figura 38: Ataque Broadcast IP Flooding
Figura 39: Ataque Smurf
Figura 40: Cabecera Paquete IP V 4.0.
Figura 41: Ataque DoS Snork
Figura 42: Ataque DDoS TRIN00
Figura 43: Esquema de comunicaciones de TRIN00
86
88
90
110
111
115
116
117
120
121
126
127
128
128
129
130
133
134
135
136
138
139

INTRODUCCIN
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 temticas que tienen que ver con la privacidad formacin tanto
personal como profesional. En la web encontramos funcionando a tiendas en
lnea, redes sociales, negocios que mueven grandes cantidades de dinero, redes
de los servicios que habilitan el comercio a nivel internacional que contienen
informacin muy delicada de la vida privada de sus miembros.
Para dar inicio a este universo de la privacidad y seguridad de la informacin que
en la web viaja, el presente contenido acadmico hace relevancia a la necesidad
de implementar procedimientos seguros cuando se desarrollan aplicaciones web
para compartir y publicar informacin pueden haber muchos puntos de vista pero
uno de los ms ms crticos 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 acadmico, es necesario tener como
base muchos de los conceptos de seguridad abordados en redes de
telecomunicaciones, sistemas operativos e informtica forense. Es por ello que el
tema de seguridad se debe asimilar como un engranaje en el que intervienen
muchas reas y tcnicas cuando se trata de proteger la integridad de la
informacin y la privacidad de los datos de los usuarios.-
El contenido que a continuacin se presenta aborda los conceptos y mecanismos

fundamentales para la deteccin de vulnerabilidades en aplicaciones web, en las
que primero se incluyen temticas bsicas introductorias pero especficas al
diseo de aplicaciones web seguras, para luego tratar con los protocolos de
seguridad ms usados en aplicaciones web.
Las reas crticas del diseo de aplicaciones web demostrarn que van desde la
misma infraestructura en telecomunicaciones, el entorno de implementacin, hasta
el cdigo c y los lenguajes de programacin 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 disear y de implementar aplicaciones que solo den
una buena imagen y gusto al cliente, sino tambin aspectos de seguridad que
minimicen el riesgo de prdida de informacin o de manipulacin de la misma.
9

En cuanto a la utilidad prctica de estos contenidos, alcanza a llevar a que el

estudiante sea competente en la identificacin de diseos inseguros en
aplicaciones web y que lo lleve a proponer mejoras o planes de contingencia que
reduzcan el riesgo. El mdulo, no pretende conceptualizar ni ejercitar al estudiante
en el proceso de implementacin de servidores web o soluciones tipo LAMP1,
WAMP 2, ni ahondarnos en el desarrollo web, que deben ser competencias previas
como presaberes a estos contenidos. Tampoco es posible llegar a la prctica o
demostracin de cada herramienta que detecte vulnerabilidades o demostrar cada
riesgo. Estos son aspectos Tcnicos que se aplican de forma operativa y el curso
entindase tiene un carcter acadmico investigativo que lleva al estudiante a
formular diseos propios, soluciones y anlisis de todas las herramientas y que lo
lleven a detectar vulnerabilidades y controlarlas. Durante el desarrollo del aula, se
ejercitarn prcticas que en lo posible toquen cada tema expuesto en los
contenidos de este mdulo.
Finalmente el contenido de este mdulo, 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 intensiones de
plantear proyectos que a su vez trabajaran en temas de seguridad de
aplicaciones, buenas prcticas para desarrollo seguro, pruebas de seguridad para
software entre otros. Muchas referencias, actividades y experiencias en la
temtica de aplicaciones web, estn apoyadas en este proyecto.
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
10

PRIMERA UNIDAD
INTRODUCCION A LA SEGURIDAD EN APLICACIONES WEB
CAPITULO I:
1. CONCEPTOS BSICOS 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, topologas, 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 tambin 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
informacin que en la web viaja, el presente contenido acadmico hace relevancia
a la necesidad de implementar procedimientos seguros cuando se desarrollan
aplicaciones web para compartir y publicar informacin pueden haber muchos
puntos de vista pero uno de los ms crticos 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 diseadores, 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 diseo, arquitectura, conceptualizacin e
implementacin de aplicaciones web que medianamente puedan ser seguras o
que estn enmarcadas en su implementacin dentro de un protocolo y estndar de
funcionamiento medianamente seguro.
Respecto a los servidores web, es comn escuchar sobre fallas en los sistemas de
proteccin de los servidores ms frecuentemente utilizados:
11

Apache: Este es el ms comn y ms utilizado en todo el mundo. Adems, es

gratuito y de cdigo abierto, as que se podra 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 tambin 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
cdigo 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 ms popular de la red y
tambin se distribuye bajo licencia BSD. 8
Lighttp: Este servidor Web es otro de los ms ligeros que hay en el mercado.
Est especialmente pensado para hacer cargas pesadas sin perder balance,
utilizando poca RAM y poca de CPU. Algunas pginas populares que lo usan son
Youtube, Wikipedia y otras que soportan gran trfico diariamente. Tambin es
gratuito y se distribuye bajo licencia BSD. 9
O en los lenguajes de programacin en los que son escritas las aplicaciones que
son ejecutadas por estos servidores. Es de reconocer, que la mayora de los
problemas de vulnerabilidad detectados en servicios web no son provocados por
fallas intrnsecas 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 mayora de los problemas de seguridad en
los sitios web que tienen su origen en los niveles superiores del modelo OSI a
nivel de aplicacin (Ver figura 1) y que son el resultado de escritura defectuosa
de cdigo, que por lo general viene motivada por aspectos de forma en los que el
diseador le importa cmo se vea un sitio web o una aplicacin 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
12

no es una tarea fcil, ya que requiere por parte del programador, no nicamente
mostrar atencin en cumplir con el objetivo funcional bsico de la aplicacin, sino
una concepcin general de los riesgos que puede correr la informacin contenida,
solicitada y recibida por el sistema.
No quiere decir esto que en los dems niveles no se presenten amenazas y
vulnerabilidades que afecten a los sitios web. E la Leccin 25, trataremos aspectos
de seguridad en otros niveles y protocolos de la capa OSI que afectan
aplicaciones web.
Figura 1: Niveles superiores de OSI, orgenes de vulnerabilidades en sitios web

Fuente: El autor
En la figura1, se puede identificar los niveles superiores del modelo OSI donde
son tpicas 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 cdigo
abierto (comunidades libres), que permiten formar un criterio sobre el tema, no
existen acuerdos bsicos 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 sern las que
describo en este documento junto con los ataques ms comunes a aplicaciones
web y las tcnicas de defensa a las inicialmente el profesional puede aplicar en
primera instancia. Es tarea del profesional que aborde estas temticas, que
13

defina su estrategia de diseo e implementacin segura de sus aplicaciones

web basado en experiencias como las que presenta este mdulo y comparto.
En el contenido de este escrito, se tratan temas esenciales de seguridad que se
suelen encontrar en las aplicaciones PHP, adems se remiten ejemplos y
estrategias para evitar cometer los mismos errores, si bien, la mayora de los
problemas (sino es que todos) revisados sern para cdigo PHP, los mismos
consejos suelen aplicar para otros lenguajes de tecnologas similares que por lo
mismo enfrentan problemas parecidos y cuya solucin es la misma, slo con las
variantes propias del lenguaje.
LECCION 1: INTRODUCCION AL PROTOCOLO HTTP:
El modelo TCP/IP cuenta con diversos protocolos en su capa de aplicacin: HTTP,

SMTP y FTP son tres de los ms importantes. En principio, cualquiera de ellos
puede ser utilizado para la transferencia de mensajes SOAP pero HTML es el
protocolo estndar para la web y el ms usado en los servicios web XML.
En la figura 2 se observa los protocolos que actan en las respectivas capas del
modelo OSI. Todos los protocolos presentan deficiencias en su diseo y por tanto
ofrecen de alguna forma vulnerabilidades que afectan las caractersticas de
seguridad de una aplicacin web (integridad, disponibilidad, confidencialidad).
Figura 2: Tecnologas y protocolos de red modelo OSI

Fuente: El autor
14

El Protocolo de Transferencia de HiperTexto (Hypertext Transfer Protocol) es un

sencillo protocolo cliente-servidor que articula los intercambios de informacin
entre los clientes web y los servidores HTTP.
Es un protocolo del nivel de aplicacin usado para la transferencia de informacin
entre sistemas, de forma clara y rpida. Este protocolo ha sido usado por el WorldWide Web desde 1990. La especificacin 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 distribucin de informacin como el World
Wide Web.
El protocolo HTTP se basa en un paradigma de peticiones y respuestas. Un
cliente enva una peticin en forma de mtodo, una URI, y una versin de
protocolo seguida de los modificadores de la peticin de forma parecida a un
mensaje MIME, informacin sobre el cliente y al final un posible contenido. El
servidor contesta con una lnea de estado que incluye la versin del protocolo y un
cdigo que indica xito o error, seguido de la informacin del servidor en forma de
mensaje MIME y un posible contenido
1.1 CARACTERISTICAS Y FUNCIONAMIENTO
Desde el punto de vista de las comunicaciones, HTTP se establece sobre la capa
de conexin 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 conexin de
los clientes web. Una vez que se establece la conexin, el protocolo TCP se
encarga de mantener la comunicacin y garantizar un intercambio de datos libre
de errores.
HTTP se basa en sencillas operaciones de solicitud/respuesta. Un cliente
establece una conexin con un servidor y enva un mensaje con los datos de la
solicitud. El servidor responde con un mensaje similar, que contiene el estado de
la operacin y su posible resultado. Todas las operaciones pueden adjuntar un
objeto o recurso sobre el que actan; cada objeto web es identificado por su URL.
La figura 3 muestra estas sencillas operaciones de dilogo que genera HTTP
cuando se lanza una solicitud de servicio a una aplicacin web.
10
Disponible en internet desde <http://www.freesoft.org/CIE/RFC/1945/index.htm>
15

Figura 3: Operaciones de solicitud - respuesta con HTTP

Fuente: El autor
Se detalla a continuacin las principales caractersticas del protocolo HTTP:
Toda la comunicacin 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 clasificacin MIME.
Existen ocho verbos que permiten que un cliente pueda dialogar con el
servidor. Los tres ms utilizados son: GET, para recoger un objeto, POST,
para enviar informacin al servidor y HEAD, para solicitar las caractersticas
de un objeto (por ejemplo, la fecha de modificacin de un documento
HTML).
16

Cada operacin HTTP implica una conexin con el servidor, que es liberada
al trmino de la misma. Es decir, en una operacin se puede recoger un
nico objeto. Con la versin HTTP 1.1 se ha mejorado este procedimiento,
permitiendo que una misma conexin 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
mayora de los clientes y servidores modernos.
No mantiene estado. Cada peticin de un cliente a un servidor no es influida

por las transacciones anteriores. El servidor trata cada peticin como una
operacin totalmente independiente del resto.
Cada objeto al que se aplican los verbos del protocolo est identificado a
travs de un localizador uniforme de recurso (URL) nico.
Cada vez que un cliente realiza una peticin a un servidor, se ejecutan los
siguientes pasos:
1. Un usuario accede a una URL, seleccionando un enlace de un documento
HTML o introducindola directamente en el navegador.
2. El cliente web descodifica la URL, separando sus diferentes partes. As
identifica el protocolo de acceso, la direccin DNS o IP del servidor, el
puerto (de carcter opcional; el valor por defecto es 80) y el objeto
requerido del servidor.
3. Se abre una conexin TCP/IP con el servidor, llamando al puerto TCP

correspondiente.
4. Se realiza la peticin. Para ello, se enva el comando necesario (GET,

POST, HEAD,), la direccin del objeto requerido (el contenido de la URL
que sigue a la direccin del servidor), la versin del protocolo HTTP
empleada y un conjunto variable de informacin, 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 cdigo de
estado y el tipo de dato MIME de la informacin de retorno, seguido de la
propia informacin.
17

6. Se cierra la conexin TCP. Si no se utiliza el modo HTTP Keep Alive, este

proceso se repite para cada acceso al servidor HTTP.
El dilogo con los servidores HTTP se establece a travs de mensajes formados
por lneas 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 ANALISIS DE UNA CABECERA HTTP:
Realizando una peticin 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
sesin de consola en un sistema operativo BackTrack 5 con permisos de root y
accediendo a la web mediante una conexin ADSL sin restricciones o puertas
traseras firewalls configurados y sin restriccin de puertos.
Figura 4: Anlisis de cabeceras HTTP

Fuente: El autor
Al realizar la peticin al sitio web, el servidor nos manda el cdigo de respuesta [2]
200. Los cdigos de rango 2xx indican que la operacin se ha realizado con xito,
Cache-Control: Genera las directivas que deben ser usadas por cualquier
mecanismo a lo largo de la peticin/respuesta.
Connection: Indica que la conexin 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)
18

Content-Length: Campo que indica el tamao del cuerpo del documento o, en

decimal, enviado al destinatario que hubiera enviado la peticin.
ContenrtType: Tipo de contenido y codificacin del archivo al que realizamos la
peticin
Expires: Muestra la fecha en la que va caducar la cache de nuestra peticin.
Set-Cookie: Es la coockie que nos enva la pagina a la que hemos realizado la
peticin, en ella aparece su ID. Su fecha de expiracin, sobre que directorio acta
y el dumio desde donde se ha obtenido.
1.3 METODOS HTTP:
Los mtodos HTTP ms comunes y los ms usados son los que a continuacin se
mencionan. Es importante identificarlos ya que son los ms manipulados en la
aplicacin en ataques y tcnicas de PenTesting y de snifeo de cabeceras HTTP.
GET: Sirve para recoger cualquier tipo de informacin del servidor. Se utiliza
siempre que se pulsa sobre un enlace o se teclea directamente a una URL. Como
resultado, el servidor HTTP enva el documento ubicado en la direccin
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 cachs de pginas o los
servidores proxy para conocer cundo es necesario actualizar la copia que se
mantiene de un fichero.
POST: Este comando enva datos de informacin al servidor, normalmente
procedentes de un formulario web, para que el servidor los administre o los aada
a una base de datos.
PUT: Almacena un objeto en la URL especificada. Si la direccin de destino ya
contena un objeto, se considera que se est enviando una versin 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 estn aadiendo informacin o modificando la peticin.
OPTIONS: Devuelve los mtodos 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 tnel
dinmicamente (por ejemplo, un tnel SSL).
Ante cada transaccin con un servidor HTTP, ste devuelve un cdigo numrico
en la primera lnea del mensaje de respuesta que informa sobre el resultado de la
operacin. Estos cdigos aparecen en algunos casos en la pantalla del cliente,
cuando se produce un error. Los cdigos de estado estn clasificados en cinco
categoras:
1xx: Mensajes informativos.

2xx: Mensajes asociados con operaciones realizadas correctamente.
19

3xx: Mensajes de redireccin, que informan de operaciones

complementarias que se deben realizar para finalizar la operacin.
4xx: Errores del cliente; el requerimiento contiene algn 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 cdigos que se utilizan con
mayor frecuencia:
La tabla 1 muestra los cdigos de estado ms comunes en una conversacin

establecida con el protocolo HTTP. Estos cdigos son los que generalmente se
modifican en interceptaciones o ataques a servicios HTTP y sern parte del
anlisis 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
Operacin realizada satisfactoriamente
La operacin 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 operacin 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 informacin.
La operacin ha sido aceptada, pero no ha producido ningn resultado de
inters. 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, adems, 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, adems, la nueva URL en el campo Location de la
respuesta. El cliente no debe modificar ninguna de las referencias a la URL
errnea.
Se devuelve cuando se hace un GET condicional y el documento no ha sido
modificado
La peticin tiene un error de sintaxis y no es entendida por el servidor.
La peticin requiere una autorizacin especial, que normalmente consiste en
un nombre y clave que el servidor verificar. El campo WWW-Autenticate
informa de los protocolos de autentificacin aceptados para este recurso.
Est prohibido el acceso a este recurso. No es posible utilizar una clave para
modificar la proteccin.
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 diseo 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 haba solicitado el cliente.
El servidor est actualmente deshabilitado y no es capaz de atender el
requerimiento.
Tabla 1: Cdigos de estado en HTTP

Fuente: <http://www.rfc-editor.org/rfc/rfc1866.txt>
20

1.4 CODIFICACION DE LA INFORMACION:
Una de las caractersticas de HTTP reside en que la comunicacin entre cliente y

servidor se realiza a partir de caracteres US-ASCII de 7 bits. El problema aparece
cuando deseamos realizar la transmisin de un archivo binario, cuyo contenido no
puede ser representado por este grupo tan reducido de caracteres.
Para solventar esta limitacin se utiliza el estndar de Internet MIME (Extensiones
de correo de Internet multipropsito). Son una serie de convenciones o
especificaciones dirigidas a que se puedan intercambiar a travs de Internet todo
tipo de archivos (texto, audio, vdeo, 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 especificacin de este
estndar se encuentra recogidas en las RFC 2045, 2046, 2047, 2048 y 2049.11
Los recursos u objetos que actan como entrada o salida de un comando HTTP
estn clasificados por su descripcin 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 identificacin 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 mtodos bsicos de codificacin:
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 latn. 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/>
21

LECCION 2: VULNERABILIDADES EN APLICACIONES WEB:
2.1 COMO TRABAJAN LAS APLICACIONES WEB
Iniciemos con una breve descripcin de cmo trabajan e interactan las

aplicaciones y servicios web con diferentes componentes y escenarios
tecnolgicos.
El uso de aplicaciones web es tan comn como tan masificado hoy en da por todo
tipo de usuarios, empresas e instituciones. Su uso va desde la simple accin de
leer un correo electrnico hasta realizar una compra en lnea o una transaccin
bancaria sin importar el cubrimiento de estas aplicaciones, el tamao, diseo,
cdigo en que estn realizadas, plataformas y arquitecturas en las que estn
montadas.
Algo en comn de estas aplicaciones es que la mayora son interactivas,
agradables para el usuario, con datos en lnea que se comparten y que ponen a
disposicin del usuario. Muchas de ellas soportadas por grandes bases de datos y
que usan como canal de distribucin Internet.
La forma como una aplicacin web trabaja, a simple vista es sencilla y prctica.
Tal vez por ello y sin ser una afirmacin, es que son vulnerables. Po lo general
consisten en una base de datos que por decirlo as, est ubicada detrs del sitio
web alojado en un servidor y que est escrita en un lenguaje de programacin que
es capaz de extraer informacin especfica de esa base de datos por solicitudes y
peticiones de los usuarios remotos o locales mediante interacciones dinmicas
con esos usuarios o clientes.
Cuando se usan bases de datos para la gestin de los mismos en aplicaciones
web, es comn que estas aplicaciones estn compuestas por tres niveles:
Un nivel de presentacin (un navegador web o motor de bsqueda).
Un nivel lgico (un lenguaje de programacin, como C #, ASP, NET, PHP, JSP,
etc.).
Y un nivel de almacenamiento (base de datos como Microsoft SQL Server,
MySQL, Oracle, etc.)
22

Figura 5: Niveles de comunicacin en aplicaciones web.

Fuente: El autor
En la (figura 5) se identifica la secuencia de peticiones y operacin de los tres

niveles en donde si el navegador Web (el nivel de presentacin, por ejemplo,
Internet Explorer, Safari, Firefox, etc) enva peticiones a la capa media (la capa de
lgica), que define los servicios, las solicitudes, consultas y actualizaciones de la
base de datos (el nivel de almacenamiento).
2.2 UNA ARQUITECTURA MS COMPLEJA:
En los ltimos aos, el modelo de tres niveles fue reevaluado y un nuevo concepto
basado en la escalabilidad y mantenimiento fue creado. Surge una solucin de
cuatro niveles que implica el uso de una pieza de middleware, tpicamente
llamado un servidor de aplicaciones, entre el servidor Web y el servidor de
aplicaciones de base de datos.
Esta nueva capa de abstraccin, consta de un servidor que aloja una interfaz de
programacin de aplicaciones (API) para exponer la lgica de negocio y procesos
de negocio para uso de los servidores Web. Adems, el servidor de aplicaciones
23

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 (presentacin) enva peticiones a la capa

intermedia (lgica), que a su vez llama a la API expuesta del servidor de
aplicaciones que residen en la capa de aplicacin 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 lgica carga
una secuencia de comandos del sistema de archivos y se lo pasa a travs de su
motor de scripting en el que se analiza y se ejecuta El script llama a una API
expuesta desde el servidor de aplicacin que reside en la capa de aplicacin. El
servidor de aplicacin abre una conexin con el nivel de almacenamiento usando
un conector de base de datos y ejecuta una instruccin 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 lgica de aplicacin o negocio antes
de devolver los datos al servidor Web que aplica un retoque de (lgica final)
antes de la presentacin de los datos en formato HTML en el navegador Web del
usuario. La presentacin de la web se hace mediante HTML que le muestra al
usuario una representacin grfica de la cdigo Esto sucede de manera
instantnea y es transparente para el usuario.
Pero por que se dividen las tareas en capas o niveles?: El concepto bsico de una
arquitectura estratificada implica dividir una aplicacin en trozos lgicos, o niveles,
cada uno de los cuales se le asignan roles. Las capas se pueden localizar
24

(implementar) en diferentes mquinas o en la misma mquina de forma

virtualizada o separados el uno del otro.
Ventajas: Cuando se dividen las responsabilidades de una aplicacin en mltiples
capas hace que sea ms fcil de escalar la aplicacin, permite una mejor
distribucin de las tareas de desarrollo entre los desarrolladores, y hace una
aplicacin ms fcil de leer dndole incluso enfoque de rehso y de adaptabilidad
a otras aplicaciones existentes o nuevas.
Le da caractersticas de robustez a las aplicaciones permitiendo eliminar puntos
de fallos crticos y nicos que se puedan presentar si la aplicacin sufre una cada
total o irreparable.
Por ejemplo, la decisin de cambiar de proveedor de bases de datos debe requerir
nada ms que algunos cambios en las porciones aplicables de la capa de
aplicacin, la presentacin y los niveles lgicos.
2.3 EL PROYECTO OWASP Y LAS VULNERABILIDADES EN APLICACIONES

WEB
Antes de dar inicio y entrar en la temtica 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 ingls) 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 temtica
es amplia y de trabajo continuo. Este mdulo acadmico que se presenta ac, no
pretende abarcar la totalidad de las vulnerabilidades, estrategias, escenarios,
herramientas y metodologa usados tanto para detectar, disear, proveer,
monitorear y corregir fallos de seguridad en aplicaciones web. Es un referente
para que el profesional tome como partida y apoyo para el anlisis de las
temticas que ac se presentan.
Existen otros proyectos que tratan este tema y de los cuales tambin se han
referenciado lecciones en este mdulo, pero con OWASP se pretende que el
estudiante lo identifique y derive sus conclusiones, aportes y posiciones con
referencia a la temtica.
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 acadmica, objetiva, investigativa
y como un ejercicio profesional en el rea de la seguridad, as: No sin antes
25

referenciar el OWASP top 10 de 2013 que lo encuentran ac:

necesaria lectura antes de continuar.
13
y que es 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 gua completa del Top 10, es parte del anexo de este mdulo:
No se detenga en el Top 10. Existen cientos de problemas que pueden afectar la seguridad
14
general de una aplicacin web tal como se ha discutido en la Guia de Desarrollo OWASP. Este
documento es de lectura esencial para cualquiera desarrollando aplicaciones web hoy en da. Una
efectiva orientacin 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>
26

Guia de Testeo OWASP15 y la Guia de Revision de Codigo OWASP, 16 las cuales han sido
significativamente actualizadas desde la ltima edicin del Top 10.
Cambio constante. Este Top 10 continuara cambiando. Incluso sin cambiar una lnea de
cdigo en su aplicacin, la misma puede ser vulnerable a algo que nadie haya pensado
anteriormente. Por favor revise los consejos detallados al final del Top 10 Prximos pasos para
Desarrolladores, Verificadores y Organizaciones para mayor informacin.
Piense positivamente. Cuando se encuentre preparado para dejar de buscar
vulnerabilidades y focalizarse en establecer controles seguros de aplicaciones, OWASP ha
17
como una gua para
producido el Application Security Verification Standard (ASVS)
organizaciones y revisores de aplicaciones que detalla los controles de seguridad a verificar en una
aplicacin.
Utilice herramientas inteligentemente. Las vulnerabilidades de seguridad pueden ser

bastante complejas y encontrarse ocultas en montaas de cdigo. En virtualmente todos los casos,
el enfoque mas eficiente y econmico 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 orientacin sobre como implementar un SDLC Seguro, leer el Open Software Assurance
Maturity Model (SAMM), 18 el cual es una actualizacin significativa al OWASP CLASP Project. 19
2.4 SNIFFEO Y CODIFICACION DE CABECERAS:

La temtica que hasta aqu se ha tratado, ha descrito de forma general el
protocolo HTTP y las negociaciones entre cliente-servidor que se establecen a
travs 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 anlisis o su modificacin. Estas utilidades se denominan sniffers,
y funcionan interceptando el trfico 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 tambin 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
27

cdigo 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 algn programa que haga
negociaciones TCP, como por ejemplo pueden ser Telnet, Putty, o los populares
Netcat y CryptCat.
2.5 INYECTANDO CODIGO

Cuando se hace un proceso de sniffing a las cabeceras HTTP, se puede hacer
con dos objetivos: Observar los datos que se envan y de ah buscar un posible
CSRF (Cross Site Request Forguery) o bien para modificar la cabecera y
aadirle cdigo malicioso, el cual provoque en una aplicacin vulnerable una
respuesta que no era la que deba.
Se inyecta cdigo a las cabeceras y si se manejan datos procedentes de la
cabecera sin realizarles un correcto filtrado, es ah cuando una aplicacin web se
vuele ms vulnerable y ms cuando sin restricciones o controles de acceso, se le
permite al front-End (usuarios hackers) la modificacin de la cabecera para que
la aplicacin web maneje cdigos 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 detallarn los procedimientos para detectar
inyecciones de cdigo como el SQL Injection
2.6 CR/LF INJECTIONS:

Esta vulnerabilidad hace referencia a un trmino comn: (HTTP Splitting). Hace
referencia al manejo de cabeceras con caracteres especiales que trabajan en
conjunto llamados CR (Carriage Retun) y LF (Line Feed) que bsicamente
traducen un Salto de lnea en el momento de una conversacin o salto de
cabecera. En programacin las seales de salto de lnea se plasman con los
caracteres de escape \r\n.
Una aplicacin 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
28

manipular a su antojo las cabeceras de un servidor y ms si es bien conocido que

la finalizacin de una cabecera se seala con un doble salto de lnea
Es aqu cuando un atacante identificando ese salto de lnea final, provocar la
particin de la cabecera, permitiendo colocar junto al doble salto de lnea el
cdigo que l considere oportuno, normalmente ser una segunda cabecera.
A la tcnica de truncar o cortar una cabecera para controlar una respuesta del
servidor se la denomina HTTP Splitting. Una tcnica derivada del HTTP Splitting
puede ser lo que se denomina File Download Injection y consiste en infectar con
el cdigo que nosotros deseemos una descarga.
2.7 XSS Y SQL INJECTIONS
Las fallas de inyeccin, ya sea de SQL, LDAP o comandos del sistema operativo,
son comunes en aplicaciones Web. La inyeccin ocurre cuando los datos
proporcionados por el usuario son enviados e interpretados como parte de una
orden o consulta. Los atacantes interrumpen el intrprete para que ejecute
comandos no intencionados proporcionando datos especialmente modificados.
Esta tcnica es usada para explotar aplicaciones web que no validan la
informacin suministrada por el cliente, para generar consultas SQL maliciosas. El
proceso de inyeccin requiere de verificar cada parmetros que se enva y se
recibe, lo que suele no ser sencillo y muchas veces se puede creer que no es
vulnerable una aplicacin que lo es. Se debe chequear cada parmetro de cada
script de cada aplicacin.
Para el siguiente ejemplo en la que se inyecta el comando (se solicita una
informacin):
SELECT id FROM usuarios WHERE user=$f_user

AND password=$f_pass;
Si no se identifica un usuario (campo en blanco en la validacin) o si se typean los

parmetros predeterminados de los usuarios: admin, administrator, guest, invitado
entre otros, al modificar la injeccin de SQL por:
$f_user= or 1=1 --
en las que se usa:
; para ejecutar mltiples queries

-- para comentar el final del query
construcciones del tipo or =
construcciones del tipo numero or 1=1
29

Se podra explotar esta vulnerabilidad de validacin de usuario e ingresar al

sistema
Ataques de Cross
Site Scripting : Las fallas de XSS ocurren cuando una
aplicacin toma informacin originada por un usuario y la enva 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 vctima 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 tpicamente se valen
de cdigo HTML y de scripts ejecutados en el cliente.
Desde la liberacin del lenguaje JavaScript, se previeron los riesgos de permitir a
un servidor Web enviar cdigo ejecutable al navegador. Un problema se presenta
cuando los usuarios tienen abiertos varias ventanas de navegador, en algunos
casos un script de una pgina podra acceder datos en otra pgina u objeto,
observando el peligro de que un sitio malicioso intentara acceder datos sensibles
de esta forma. 20
Poltica sameorigin: Esencialmente esta poltica permite la interaccin entre

objetos y pginas, 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 va JavaScript. A partir de entonces se
han introducido otros mecanismos y polticas 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 tcnicas de evasin de las
polticas de proteccin.
La mayora de casos la variable vulnerable (en el caso de los XSS) suele ser
alguna que se utiliza para mostrar alguna informacin tipo IP, User-Agent y
dems. Por so la mayora 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 sesin 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 aplicacin de subir
archivos al servidor. Estos ataques funcionan de la siguiente manera:
20
Tomado de: UNAM CERT; Aspectos Bsicos de la Seguridad en Aplicaciones Web
30

Generalmente PHP almacena los archivos subidos en un carpeta temporal, sin

embargo es comn en las aplicaciones cambiar la localizacin del archivo subido a
una carpeta permanente y leerlo en la memoria. Al hacer este tipo de
procedimientos debemos revisar el parmetro que har referencia al nombre del
archivo, ya que puede ser truqueado a modo de apuntar a archivos de
configuracin del sistema (como /etc/passwd en sistemas Unix).
Las aplicaciones invocan comandos externos a travs de un intrprete de
comandos. Segn 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 informacin 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 bsicamente banner a la
informacin (aplicacin, versin, plataforma sobre la que corre) que trasmite un
servicio cuando se trabaja sobre en el.
Un ejemplo de deteccin de esta informacin (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 tpico del sitio www.hp.com.
Figura 8: Banner deteccin por ftp

Fuente: El autor
31

En la figura 9 se aplica un banner grabbing hacia la web www.unad.edu.co:

Informacin del tipo de servidor, versin sistema operativo sobre el cual se
ejecuta, versin de PHP entre otros.
Figura 9: Banner grabbing por mtodo HEAD

Fuente: El autor
El ataque consistira 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 informacin de un sistema concreto y de alguna
vulnerabilidad especfica. Esto se hace obteniendo su huella identificativa
respecto de la pila TCP/IP de los equipos atacados. Esta tcnica es la que se
conoce como Fingerprinting y la informacin que puede brindar esta tcnica dentro
de las muchas opciones que tiene de descubrir datos de la vctima es la de
permitir descubrir de forma muy fiable el sistema operativo que se ejecuta en la
maquina analizada. La aplicacin de esta tcnica consiste en la ejecucin de 4
tests (orden de campos al hacer un HEAD, respuesta ante un DELETE, respuesta
ante una versin del protocolo HTTP incorrecta, y por ltimo, la respuesta que da
el servidor ante un protocolo errneo).
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. Adems de las versiones de
32

sistema operativo, puertos abiertos y capas de seguridad implementadas al

protocolo HTTP. La informacin que puede brindar esta tcnica dentro de las
muchas opciones que tiene de descubrir datos de la vctima son:
Permitir descubrir de forma muy fiable el sistema operativo que se ejecuta

en la maquina analizada.
Identificar el tipo de servidor y la versin en la que se soporta el servicio
El tipo de servicio que se ejecuta y la versin.
Una de las muchas tcnicas que existen para levantar este tipo de informacin 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 informacin con el nmero
de puertos cerrados que tiene la vctima, en este caso con la direccin IP
10.1.1.16, los puertos en servicio abiertos, la identificacin del sistema Operativo y
la direccin fsica de la interfaz de red. Se ha ejecutado en una consola haciendo
uso de nmap como herramienta de exploracin.
Figura 10: Uso de un Escucha de Red para hallar huellas identificativas de un host en la red
Ethernet
Fuente: El autor
33

En la Figura 11 se ha realizado la inspeccin 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 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 desempeo de la red utilizando diferentes
protocolos, tamaos de paquetes, TOS (type of service, o sea, tipo de servicio), y
fragmentacin; 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; deteccin
remota de OS (`remote OS fingerprinting'); auditar una implementacin 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>
34

LECCION 3: HERRAMIENTAS PARA LA DETECCION DE VULNERABILIDDES
3.1
FIABILIDAD
DE
LOS
VULNERABILIDADES WEB
ANAIZADORES
AUTOMATICOS
DE
Se llega al punto de definir qu tan fiables los analizadores automticos de

vulnerabilidades Web. En primera instancia al gran nmero 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 deteccin
y proteccin total.
Los profesionales informticos, empresas, administradores de TICS, diseadores,
desarrolladores e incluso usuarios, concentran sus actividades en aspectos de
seguridad en emplear, cada vez ms, herramientas para facilitar la ardua tarea de
verificar el nivel de seguridad real de una aplicacin web. Nombres como
Appscan, Webinspect, Acunetix y otros tantos son cada vez ms conocidos y
utilizados por los profesionales en cualquier proyecto de auditora o de pentest.
Las ventajas son innumerables pero tambin los riesgos, y es necesario
conocerlos y valorarlos a la hora de decidir el presupuesto de que se dispone para
analizar si una pgina Web puede ser comprometida, desde el punto de vista de la
seguridad, o si, por el contrario, cumplir con su cometido a la perfeccin.
Por Escner Web se entiende cualquier programa con la capacidad de analizar la
seguridad de una aplicacin o pgina Web, es decir, debe incluir los siguientes
complementos:
a) Un navegador Web para poder interpretar el cdigo HTML, javascript y dems
de la propia pgina.
b) Un "spider" o "crawler" para poder detectar toda la estructura de navegacin de
la Web (archivos, directorios, ficheros de imgenes, etc.)
c) Un escner propiamente dicho para hallar fallos de configuracin y
vulnerabilidades a nivel Web.
d) Un interface de usuario amigable y fcil de utilizar, que permita configurar de
forma sencilla la aplicacin y todos los parmetros de anlisis.
35

e) Un generador de reportes que incluya las vulnerabilidades y errores

encontrados, su posible impacto para la aplicacin Web y la forma de corregir los
mismos de forma genrica.
Existen multitud de herramientas as, comerciales de pago y con licencia GNU,
para Windows y para Linux, ms sencillas y ms completas, de desarrolladores
conocidos como RedHat, Oracle, Cisco.
3.2 VENTAJAS Y BENEFICIOS
1. Reduccin de costes: el precio y el esfuerzo en horas de revisar una

aplicacin 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 anlisis y revisiones para amortizar la
herramienta. Adems, existen incluso aplicaciones que no son comerciales
sino Open Source que tambin son importantes, es el caso de Wapiti 22,
Skipfish, Nikto, etc.
2. Disponibilidad y automatizacin: al poder programar y automatizar

cualquier anlisis de seguridad, se puede repetir tantas veces como sea
necesario para verificar que se han corregido los errores y vulnerabilidades
ya detectados. Tambin se puede definir una frecuencia determinada para
que se revise una pgina Web concreta una vez al mes, por ejemplo, y
comprobar as si ha habido cambios en la misma y detectar incluso
anomalas que pudieran indicar un ataque a la pgina en forma de intrusin
o Denegacin de Servicio (DoS). Si en un escaneo programado la pgina
no est operativa puede ser debido a un ataque de DoS o un problema de
disponibilidad no controlado.
3. Constante revisin y mantenimiento de la aplicacin: La mayora de
herramientas lo hacen todo, revisan, analizan detectan las vulnerabilidades
y errores de configuracin, 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>
36

3.3 INCONVENIENTES Y DESVENTAJAS
1. Gran cantidad de falsos positivos y falsos negativos: dos peticiones

iguales en momentos diferentes a la aplicacin Web por parte del escner,
pueden generar respuestas distintas que la herramienta puede interpretar
de forma errnea y reportar como una vulnerabilidad inexistente. Anuncios,
dependencias con otras pginas y aplicaciones, usuarios conectados
interactuando con la Web analizada, etc. En multitud de ocasiones la
revisin de seguridad se limita a pasar la herramienta automtica 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. Tambin, otras veces, la pgina Web
analizada presenta diverso cdigo y contenido intil para revisar la
seguridad de la misma que una persona puede identificar de forma rpida y
sencilla, pero que no lo es tanto para un ordenador y la correspondiente
aplicacin automtica. Un ordenador no es capaz de entender la lgica de
la aplicacin Web, y el escaneo de seguridad se basa en comprobar la
respuesta de la pgina Web ante los controles y tests que tiene
predefinidos la herramienta de anlisis como vulnerabilidades ya conocidas.
2. Imposibilidad de encontrar 0days y errores de diseo: al basarse el

anlisis en comprobar la respuesta de la pgina Web ante los controles y
tests que la herramienta tiene predefinidos como vulnerabilidades ya
conocidas, es muy difcil detectar la presencia de errores no conocidos
(0days) y que no estn incluidos en la base de datos del escner Web con
el que se realiza la revisin de seguridad. Adems, es complicado que un
ordenador pueda entender la lgica de la aplicacin, cosa que para un
tcnico con conocimientos no supone ningn reto.
3. Problemas con vulnerabilidades de aplicacin 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 adems se encuentran por en medio
mecanismos de seguridad como WAF, IPS, firewalls y otros, las
herramientas automticas 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 estndar
como Blind SQL y la solucin para corregirla es ligeramente distinta. Otro
37

problema es que numerosas herramientas automticas no detectan como

ataque de SQLi una vulnerabilidad en "ORDER BY", adems es diferente la
forma de tratar esta vulnerabilidad en funcin del motor de base de datos
existente, ya sea MS SQL, MySQL, PostgreSQL, etc.
4. Riesgos directos para la aplicacin Web: ya no solo por el lmite de
peticiones que una herramienta automtica puede lanzar en paralelo contra
la aplicacin Web que puede saturar a la misma y dejarla inaccesible para
sus usuarios legtimos, sino tambin 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 peticin de "SELECT" no hay problema pero si eso
mismo acompaa a una peticin de "DELETE" quedara una cosa parecida
a "DELETE FROM users where id=1 or 1=1 --" con lo que esto supondra
para la aplicacin Web. Un tcnico no usara nunca este mtodo de ataque
pero an existen muchas herramientas que se sirven de ella como patrn
de ataque
Resumiendo, para entornos productivos, lo ms recomendable para disponer de
un nivel aceptable de seguridad en las aplicaciones Web es combinar escaneos
con herramientas automticas y detectar aquellas vulnerabilidades de bajo nivel ya
conocidas, y disponer tambin de tcnicos de seguridad con amplios
conocimientos que puedan realizar pruebas manuales especficas para cada
aplicacin. No es lo mismo revisar un CMS conocido tipo Wordpress, Joomla, etc.
que una pgina Web sin contenido dinmico ni base de datos detrs. Un tcnico
puede ajustar las pruebas y los anlisis a realizar en funcin de las necesidades
de cada caso, se trata de soluciones no industrializadas
3.4 CRITERIOS DE VALORACION PARA HERRAMIENTAS DE SEGURIDAD
WEB
Continuacin se presenta un anlisis de las principales herramientas usadas para
deteccin y gestin de riesgos en seguridad de aplicaciones web. Tanto
herramientas de cdigo privado como de cdigo libre. Dentro de los parmetros
que se han tenido en cuenta para esta evaluacin, se han tenido e cuenta que las
vulnerabilidades y las herramientas se han aplicado en sistemas con seguridad
perimetral, interna y de entorno bsicas, con conexiones de internet libres sin
restricciones, como las que tienen la mayora de usuarios.
El criterio de valoracin fue la primera serie de caractersticas de auditora de cada
herramienta soporta. Una herramienta automatizada no puede detectar una
exposicin que no puede reconocer (al menos no directamente, y no sin un
38

anlisis manual), y por lo tanto, el nmero de caractersticas de auditora afectar

la cantidad de exposiciones que la herramienta ser capaz para detectar
(suponiendo que la funcin de auditora 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 aplicacin, en cuanto a la deteccin
de los riesgos que se podran presentar para atacar a la aplicacin web, y el
ataque a los clientes legtimos.
3.4.1 Herramientas Comerciales: El nmero de funciones de auditora en
escneres de aplicaciones Web - Herramientas Comerciales.
Figura 12: Funciones de auditora en escneres de aplicaciones web. Herramientas comerciales

Fuente: <Proyecto OWASP>
3.4.2 Herramientas de cdigo Abierto: El nmero de funciones de auditora en

escneres de aplicaciones Web - Herramientas de cdigo abierto.
39

Figura 13: Funciones de auditora en escneres de aplicaciones web. Herramientas de cdigo

abierto
3.4.3 Herramientas de auditora aplicadas a SQL INJECTION

El anlisis aplica a las herramientas que pueden detectar de SQL Injection, una de
las exposiciones ms famosas en ataques comnmente aplicado en los escneres
de aplicaciones web. El anlisis siguiente es producto de la evaluacin de que tan
buenas son las herramientas en la deteccin de riesgos de inyeccin SQL,
partiendo de un punto sin ningn tipo de restricciones que pueden impedir que la
herramienta funcione correctamente.
40

La evaluacin se realiz en una aplicacin que utiliza MySQL 5.5.x como su

repositorio de datos, y por lo tanto, reflejar la exactitud de la deteccin de la
herramienta cuando se escanean los repositorios de datos similares.
La barra azul representa el caso vulnerable prueba de precisin de deteccin,
mientras que la barra roja representa falsas categoras positivas detectadas por la
herramienta.
Herramientas de cdigo privado
Herramientas de cdigo abierto
Figura 14: Funciones de auditora en escneres de aplicaciones web para SQL Injection
41

3.4.4 Herramientas de auditora aplicadas a XSS (Ataques de CrossSite

Scripting)
Para el segundo ataque ms comn implementado en los escneres de
aplicaciones web se aplic le mismo procedimiento que en los atajes de SQL
Injection.
Herramientas de cdigo privado

Herramientas de cdigo abierto
Figura 15: Funciones de auditora en escneres de aplicaciones web para XSS

42

Continuando con la evaluacin de herramientas y aplicando ciertos criterios de

efectividad y de aplicabilidad, se adjunta como ANEXOS de este mdulo, los
anlisis de ciertas variables que son de importancia analizarlas.
Todas estas herramientas son tan solo un puado entre la cantidad de estrategias,
mtodos y utilidades que se pueden seguir para realizar la explotacin de las
vulnerabilidades en una aplicacin web. El objetivo es obtener informacin de la
aplicacin, tratar de realizar una evaluacin de la vulnerabilidad con el fin de
obtener informacin 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 aplicacin web vulnerable diseado para ayudar
a evaluar las caractersticas, la calidad y la precisin de los escneres de
vulnerabilidades de las aplicaciones web.23
LECCION 4: MITOS EN LA SEGURIDAD WEB
Siempre se cree que las vulnerabilidades ms comunes como SQL Injection,

DDoS y XSS, son las que afectan a las aplicaciones web. Tambin que los errores
son por deficiencias en la programacin e implementacin 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 bsicas del sitio y accede a los links que solo
le referencia la pgina 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
aplicacin, por ejemplo si la aplicacin utiliza campos ocultos para enviar
informacin sensible estos pueden ser fcilmente manipulados desde el
cliente.
Disponible en internet desde <http://code.google.com/p/wavsep/>
43

La validacin solo se puede realizarse nicamente del lado del cliente con
JavaScript (esto es falso) si no se efecta ninguna validacin del lado del
servidor, cualquier atacante que evite esta validacin (para nada difcil de
lograr) tendr acceso total a toda la aplicacin.
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 aplicacin sea accesible al exterior, no podr hacer nada para
detectar entradas maliciosas del cliente, y por supuesto no es proteccin
contra ataques internos.
El uso de SSL es una solucin suficiente - SSL simplemente cubre el
request/response HTTP dificultando la intercepcin del trfico entre cliente y
servidor, pero no agrega seguridad al servidor ni evita el envo de cdigo
malicioso desde el cliente.
Otro Mito es el que los desarrolladores y tcnicos encargados de la seguridad

enmarcan dentro de solo las supuestas cinco vulnerabilidades ms comunes,
dejando a un lado las estrategias de prevenir, analizar, detectar y sobre todo
disear aplicaciones expuestas a otro tipo de vulnerabilidades.
Figura 16: Categora de Vulnerabilidades

Fuente: El Autor
44

4.1 AUDITORA Y CONTROL DE VULNERABILIDADES:

Muchas empresas slo realizan el escaneo de vulnerabilidades para los periodos
de las famosas auditoria seguridad informticas y quizs rara vez, generalmente
como una vez al ao. Este es un gran error; no slo se deben realizar las
actualizaciones a las redes de forma frecuente, si no 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 anlisis de seguridad regular con una mayor
cantidad de escaneos, mucho ms frecuente (un ejemplo podra ser realizar el
escaneo de vulnerabilidades, de forma exhaustiva, cada 4 meses, o sea unas 3
veces al ao).
4.2 PUNTOS DEBILES:

Los hackers siempre quieren encontrar el acceso ms fcil a las redes de las
organizaciones valindose de una variedad de tcnicas diferentes. Pero una
caracterstica que todos los atacantes hackers tienen en comn es su deseo de
buscar los puntos dbiles de una red, cul de ellos puedan usar para lanzar
ataques con el mnimo esfuerzo.
Un ladrn normal busca una puerta abierta en una casa, un ladrn de autos busca
el vehculo en donde el conductor se haya dejado la llave olvidada, un hacker
puede examinar mltiples redes para encontrar la que le proporcione un acceso
rpido y simple. Esta situacin plantea un desafo 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:
Exploracin de puertos: El escaneo o exploracin de puertos permite determinar
las caractersticas 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, cmo estn organizados los equipos, que sistemas operativos
ejecutan y cual es le propsito de cada uno. Una herramienta de cdigo abierto
que sirve para efectuar rastreo de puertos es nmap.
Con la herramienta hping2 en el modo SCAN (-8 --scan): Permite realizar anlisis
de puertos, se pueden especificar distintas opciones para los puertos, rangos,
excluir determinados puertos, los puertos incluidos en /etc/services, etc.
45

4.3 TIPOS DE ESCANERS:

Parte de los mitos que rodean la seguridad en aplicaciones web, est el que
aplican los tcnicos, administradores de red, desarrolladores y profesionales, que
les llevan a pensar que solo se deben implementar escneres que detecten
riesgos en las capas superiores del modelo OSI, La seguridad de la informacin
es un conjunto engranado que enmarca todos los aspectos en comunicacin,
transferencia, trato de informacin. Es por ello que se deben aplicar escner de
este tipo para que medianamente se puedan minimizar riesgos y maximizar la
seguridad:
Escner de Red: escner de uso general usado para encontrar vulnerabilidades
potenciales en la red de la empresa. (Tambin se podra incluir a los escaners de
redes VoIP)
Escner de Puerto: software diseado para buscar en una red los puertos
abiertos que podran ser usados por los atacantes como puntos de entrada.
Escner para la Seguridad de aplicaciones web: Permite a los negocios realizar
evaluaciones de riesgo para identificar las vulnerabilidad en aplicaciones web y as
evitar ataques. Este tipo de escaners deben ser utilizados tambin por el
departamento de desarrollo (programacin) de una aplicacin web, ayudando as
a encontrar todos los bugs que puedan generarse durante la creacin de la
aplicacin, antes de poner la aplicacin a un entorno de produccin.
Escner de Base de datos: permite encontrar puntos dbiles en bases de datos,
protegiendo as el activo ms importante de una empresa.
LECCION 5: SISTEMA DE LOGS
La auditora 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 informtica se utiliza para registrar datos o
informacin sobre quin, qu, cundo, dnde y por qu un evento ocurre en un
dispositivo en particular o aplicacin.
46

La mayora de los logs son almacenados o desplegados en el formato estndar, 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 ledo y
desplegado en otro diferente.
Tambin se le considera como aquel mensaje que genera el programador de un
sistema operativo, alguna aplicacin o algn proceso, en virtud del cual se
muestra un evento del sistema. 24
Los sistemas de los deben garantizar la monitorizacin de los eventos que se
producen en la aplicacin y asegurar la informacin 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 opcin 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>
24
Disponible en internet dese

<http://www.juntadeandalucia.es/servicios/madeja/contenido/subsistemas/desarrollo/auditoria-yregistro>
47

Existen variantes extendidas que se aplican a estos formatos. Variantes que

dependen del sistema usado y que generalmente en herramientas de tipo IDS con
cdigo abierto, el administrador de la red puede modificar y parametrizar para
obtener la informacin deseada.
5.2 ANALISIS DEL FICHERO DE LOG:
Mucha informacin que suministran estos ficheros de registro, no son claros y
requieren que se asocien a otros para poderlos interpretar. Lo ms comn es
encontrar los siguientes datos:
Nmero de peticiones recibidas (hits).

Volumen total en bytes de datos y ficheros servidos.
Nmero de peticiones por tipo de fichero (por ejemplo, HTML).
Direcciones de clientes diferentes atendidas y peticiones para cada una de
ellas.
Nmero de peticiones por dominio (a partir de direccin IP).
Nmero de peticiones por directorio o fichero.
Nmero de peticiones por cdigo de retorno HTTP.
Direcciones de procedencia (referrer).
Navegadores y versiones de stos usados.
A pesar de que las informaciones que podemos obtener del anlisis de los ficheros
de log son numerosas, hay unas cuantas que no podemos obtener. De ellas,
algunas resultaran de especial inters:
Identidad de los usuarios, excepto en aquellos casos en los que el usuario

se identifique por peticin del servidor.
Nmero de usuarios. A pesar de tener el nmero de direcciones IP
distintas, no podemos saber de forma absoluta el nmero de usuarios, y
ms 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 despus del nuestro.
El anlisis de estos ficheros, es especfico para cada aplicacin de captura que se

tenga.
48

5.3 PROGRAMAS DE ANALISIS DE LOGS

Al igual que las herramientas de deteccin de vulnerabilidades, y escuchas de red;
son innumerables las que hay disponibles tanto en cdigo propietario como de
cdigo abierto. Los programas de anlisis de ficheros de log de cdigo libre y que
se pueden usar para obtener informacin sobre los registros de visitas de nuestro
sitio web permiten mayor manipulacin de la informacin y tratamiento de la
misma. La mayora de ellos generan los correspondientes informes en forma de
pginas web que podemos publicar incluso en nuestro sitio web.
Es de mencionar los ms comunes que poseen interfaces grficas y con
caractersticas completas en cuanto a registros capturados: Webalizer, Awstats,
Analog,
CAPITULO 2: PROTOCOLOS DE SEGURIDAD PARA APLICACIONES WEB

El anlisis de estos protocolos nos ubica especialmente en los procesos que
incluyen transacciones e informacin que se intercambie en sitios web y que por
supuesto es manejada por aplicaciones web. A continuacin se detalla los
principales protocolos de seguridad que se manejan actualmente:
1. Secure Socket Layer (SSL)

Secure Sockets Layer (SSL) es el estndar mundial de la seguridad en la Web. La
tecnologa SSL se enfrenta a potenciales problemas derivados de la visualizacin
no autorizada de informacin confidencial, la manipulacin de datos, la
apropiacin de datos, el phishing y los dems tipos de amenazas en los sitios
Web. Para ello, se cifra la informacin confidencial a fin de que slo los
destinatarios autorizados puedan leerla. Adems de evitar la manipulacin de la
informacin confidencial, SSL contribuye a que los usuarios tengan la seguridad
de acceder a un sitio Web vlido.
Los principales sistemas operativos, aplicaciones Web y hardware del servidor son
compatibles con SSL, lo que significa que esta poderosa tecnologa 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 tecnologa
SSL, existe una amplia variedad de tipos de SSL.
49

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
bsqueda fue el protocolo TLS, que permite una compatibilidad total con SSL
siendo un protocolo pblico, 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 "tnel" que se implement con SSL sea realmente
transparente a las aplicaciones que se estn 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 autenticacin mediante firma y certificados digitales, pero se diferencia de
SSL en que se implementa a nivel de aplicacin. Se puede identificar rpidamente
a una pgina web servida con este protocolo porque la extensin de la misma
pasa a ser .shtml en vez de .html como las pginas normales.
4. Protocolo SET
SET se basa en el uso de certificados digitales para asegurar la perfecta
identificacin de todas aquellas partes que intervienen en una transaccin on-line
basada en el uso de tarjetas de pago, y en el uso de sistemas criptogrficos de
clave pblica para proteger el envo de los datos sensibles en su viaje entre los
diferentes servidores que participan en el proceso. Con ello se persigue mantener
el carcter estrictamente confidencial de los datos, garantizar la integridad de los
mismos y autenticar la legitimidad de las entidades o personas que participan en la
transaccin, creando as un protocolo estndar abierto para la industria que sirva
de base a la expansin del comercio electrnico por Internet.
50

LECCION 6: TIPOS DE ANALISIS:
6.1 METODOLOGAS DE ANLISIS DE SEGURIDAD WEB:

Las aplicaciones web pueden ser analizadas utilizando distintos enfoques, entre
ellos, es posible distinguir los siguientes:
Anlisis esttico de cdigo: El analista de seguridad posee acceso al cdigo
fuente de la aplicacin, y posiblemente a manuales del usuario pero NO POSEE
acceso a la aplicacin en s misma. Tiene como desventajas: Suele suceder,
sobre todo con sistemas grandes, que la cantidad de informacin es tanta que
puede resultar muy complejo manejarla. No es posible analizar todas las lneas del
programa en bsqueda de vulnerabilidades, lo cual hace que sea complejo definir
exactamente que secciones analizar.
Cuando no es posible acceder a la aplicacin, es comn que el analista se
"pierda" entre tanto cdigo.
White box: En este enfoque, el analista de seguridad posee acceso al cdigo
fuente de la aplicacin, manuales del usuario, credenciales vlidas del sistema,
configuracin del servidor Web, y acceso a la aplicacin en s misma. Tiene como
ventajas: Ms informacin disponible, ms 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 cdigo.
Black box: En este enfoque, el analista de seguridad posee nicamente acceso a
la aplicacin. 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
aplicacin que un potencial intruso.
Como desventajas estn: Vulnerabilidades trivialmente detectables con white box
testing, no pueden ser detectadas con esta enfoque.
(if user == tester002 and password == backdoor__)
No se aprovecha el cdigo fuente de la aplicacin a favor de la seguridad de la
misma.
Dependiendo del tipo de enfoque, se aplican herramientas de anlisis como las
vistas en la Leccin 2 de este mdulo.
51

LECCION 7: ESCALACION DE PRIVILEGIOS EN APLICACIONES WEB:
Su definicin es la obtencin de los privilegios del administrador. Por ello, debe

existir una poltica o normativa especfica que establezca el uso de mecanismos
para impedir intentos de escalado de privilegios en nuestras aplicaciones web. Se
considera que un sistema aplica polticas para evitar el escalado de privilegios
cuando: No es posible acceder a informacin del sistema que pueda ser utilizada
para la escalada de privilegios, no es posible ejecutar acciones hacindose pasar
por otro usuario, etc.
Las pruebas de escalada en aplicaciones web involucran por lo menos dos tipos
de autenticacin y validacin. Un escenario tpico para analizar la jerarqua de
privilegios es si dada una aplicacin web que debe tener al menos dos tipos de
credenciales: para un usuario con privilegios elevados y bajos de privilegio. Al
iniciar sesin como usuario con privilegios elevados (por ejemplo, admin),
obviamente tenemos acceso a mucha ms informacin (ms elementos de men,
ms funcionalidad, etc.)
El punto de anlisis crtico 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 navegacin por toda la aplicacin de un usuario con
privilegios bajos es confiable y que abarco cada entrada y salida de la aplicacin.
El manejo de estos privilegios suele ser administrado mediante credenciales de
acceso haciendo uso de bases de datos. La exposicin de estas credenciales son
huecos vulnerables para la aplicacin.
Los datos de usuario y password son sensibles, por lo que deben tener
garantizada una atencin especial. Su presencia en el cdigo fuente es un riesgo
inevitable. Un caso tpico de diseo de software es que sean administradas por un
lenguaje de programacin de uso general de cdigo del lado del servidor
originalmente diseado 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);
?>
52

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
raz del directorio. Todo recurso localizado en la raz tiene una direccin 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 podran observar las credenciales del servidor.
La mejor solucin a este problema es almacenar los archivos a incluir en otro lugar
fuera del directorio raz. No es necesario tenerlos en algn 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 raz los recursos que se deseen
sean accesibles, o configurar un directorio pblico con las respectivas directivas
de seguridad.
LECCION 8: AUTENTICACION Y AUTORIZACION:
Normalmente, casi todas las aplicaciones o sistemas necesitan de los procesos de

autentificacin y autorizacin.
8.1 LA AUTENTIFICACIN:
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
categoras de autentificacin:
Qu sabes?: Informacin que el usuario conoce, ejemplos: contraseas,
respuestas a preguntas de indicio a contraseas.
Qu tienes?: Elementos fsicos que el usuario posee, como por ejemplo una
determinada tarjeta.
Quin eres?: Tcnicas biomtricas 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 caractersticas de autentificacin: autenticacin del
protocolo que se utiliza para intercambiar mensajes. Para la mayora de los
53

servicios Web XML, esto significa aprovechar las caractersticas de autenticacin

disponibles en HTTP.
Los tipos de autenticacin tpica son:
Bsica: utilizada para identificacin no segura o poco segura de clientes, ya que

el nombre de usuario y la contrasea se envan como texto codificado en base 64,
que puede ser fcilmente 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 vlida.
Bsica sobre SSL: igual que la autenticacin bsica, excepto que el canal de
comunicacin est cifrado y protege de ese modo el nombre de usuario y la
contrasea. Una buena opcin para entornos en Internet; sin embargo, el uso de
SSL influye negativamente en el rendimiento.
Implcita: 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 vlida.
Autenticacin 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 confa. IIS
autorizar el acceso a los servicios Web XML si las credenciales coinciden con las
de una cuenta de usuario vlida.
Certificados de cliente a travs 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 solucin 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. Slo est disponible en conexiones SSL, de modo que el rendimiento puede
verse afectado
54

8.2 LA AUTORIZACIN: 25
Se refiere a la gestin 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 slo estn
disponibles para los usuarios autenticados, recursos que slo estn disponibles
para los administradores, y los recursos que estn disponibles para todos. As, al
establecer privilegios de acceso a los usuarios podemos asegurar la
confidencialidad y disponibilidad de la informacin; pero, adems, podemos:
Que slo las personas autorizadas podrn 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 categoras de Autorizacin:

Autorizacin declarativa: En este tipo de autorizacin los privilegios son
gestionados un administrador independientemente de manera externa al cdigo de
la aplicacin
Autorizacin programtica: En este tipo de autorizacin las decisiones de
autorizacin se realizan desde el cdigo fuente de la aplicacin.
LECCION 9: EJECUCION DE INSTRUCCIONES DE ACCESO:
9.1 CODIFICACIN Y LAS VALIDACIONES DE ENTRADA / SALIDA:

Indican que la debilidad de seguridad ms comn en aplicaciones web es la falta
de validacin 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 inyeccin de cdigo 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>
55

Esta debilidad lleva a casi todas las principales vulnerabilidades en las

aplicaciones, tales como intrprete de inyeccin, 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 podra
manipularlos. Hay que garantizar que la aplicacin 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 validacin de los datos,
Vulnerabilidad de la integridad de los datos: El atacante manipula los datos
introduciendo intencionadamente datos errneos que manipulan la funcin de
negocio.
Violacin del formato de los datos: Un atacante consigue introducir datos sin la
sintaxis correcta, fuera de los lmites de longitud, que contenga caracteres no
permitidos, con signo incorrecto o fuera de los lmites del rango. Esto provoca un
mal funcionamiento de la aplicacin.
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
aplicacin.
9.2 GESTIN DE SESIONES Y USUARIOS:
El manejo de la sesin es uno de los aspectos crticos de la seguridad WEB.
Veremos cmo es posible mejorar la seguridad en el control de acceso y la
autenticacin a travs del manejo de las sesiones y de la informacin de los
usuarios de nuestras aplicaciones.
Se detectan las siguientes vulnerabilidades significativas.
Fijacin de sesin que intenta explotar la vulnerabilidad de un sistema que
permite a una persona fijar el identificador de sesin de otra persona. La mayora
de ataques de fijacin del perodo de sesiones estn basados en la web, y la
mayora depende de los identificadores de sesin que han sido aceptados de URL
o datos POST
Identificador de la sesin vulnerable, si no se reserva un tamao adecuado el
atacante, mediante tcnicas de fuerza bruta atacante puede conocer el
identificador de una sesin autenticada y por lo tanto hacerse con el control de la
sesin.
56

Manejo de la informacin de sesin errnea, ya sea por estar en un espacio

compartido o mal encriptada, el atacante puede obtener datos de la sesin de otro
usuario.
Ataques de proxys o cachs, las aplicaciones web deben especificar
mecanismos para impedir estos ataques de tal manera que no sea posible
suplantar sesiones de otros usuarios.
9.3 GESTIN 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 ejecucin y el
tratamiento correcto de las excepciones. Veremos cmo disminuir los riesgos de
ser atacados a partir de la generacin de un error o excepcin en la aplicacin.
El manejo de errores y excepciones son dos aspectos para realizar un
seguimiento de fallos dentro de una aplicacin. En trminos generales, hay tres
situaciones que hacen que las excepciones sean lanzadas:
Excepciones que se producen en el cdigo del cliente: El cdigo cliente
intenta hacer algo que no est permitido por la API, de esta forma viola el contrato.
El cliente puede tomar algn camino alternativo, si hay informacin til
proporcionada en la excepcin. Por ejemplo: una excepcin es lanzada cuando se
est analizando un documento XML que no est bien formado. La excepcin
contiene informacin til acerca de la localizacin en el documento XML donde se
produce el problema. El cliente puede utilizar esta informacin 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 conexin cuando se cae una red. La respuesta del cliente a
los recursos que fallan depende del contexto. El cliente puede reintentar la
operacin despus de algn tiempo o simplemente registrar el fallo del recurso y
detener la aplicacin.
Excepciones por errores derivados del cdigo programado: En esta categora,
las excepciones se producen en la ejecucin del cdigo. El cdigo cliente
usualmente no puede hacer nada con estos errores.
57

LECCION 10: CONFIGURACION SEGURA DE SERVIDORES:
La mayora de los servidores web modernos nos permiten controlar desde el

programa servidor aquellos aspectos relacionados con la seguridad y la
autenticacin de los usuarios.
El modo ms 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, mquinas, etc., tienen acceso a los
ficheros y subdirectorios del directorio donde est el fichero. Como el servidor de
NCSA fue el servidor ms usado durante mucho tiempo, la mayora 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 configuracin del servidor web, indicando all qu usuarios, mquinas, etc.,
pueden acceder al recurso indicado.
Por lo que respecta a la autenticacin (validacin del nombre de usuario y
contrasea proporcionados por el cliente), las prestaciones ofrecidas por los
diversos servidores web son de lo ms variado. La mayora permiten, como
mnimo, proporcionar al servidor web un fichero con nombres de usuario y
contraseas 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 autenticacin y validacin a otro software (por ejemplo
RADIUS, LDAP, etc.). Si usamos un sistema operativo como Linux, que dispone
de una infraestructura de autenticacin como PAM (pluggable authentication
modules), podemos usar esta funcionalidad como modo de autenticacin del
servidor web, permitindonos as usar los mltiples mtodos disponibles en PAM
para autenticar contra diversos sistemas de seguridad. 26
10.1 ORGANIZACIN 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 econmica,
es necesario definir algunos trminos.
26
<MATEU, Carles; Desarrollo de aplicaciones web, p 24, 25 >
58

Proceso: la unidad ms pesada de la planificacin de tareas que ofrece el

sistema operativo. No comparte espacios de direcciones ni recursos relacionados
con ficheros, excepto de manera explcita (heredando referencias a ficheros o
segmentos de memoria compartida), y el cambio de tarea lo fuerza el ncleo del
sistema operativo (preemptivo).
Flujo o thread: la unidad ms ligera de planificacin de tareas que ofrece el
sistema operativo. Como mnimo, 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 ncleo 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
explcitos: al llamar a ciertas funciones. La acostumbran a implementar libreras
fuera del ncleo, 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 (creacin de procesos). En servidores de alto
rendimiento, los modelos con flujos parecen mejores, aunque tienen el problema
de la portabilidad difcil y la posible necesidad de mecanismos que anticipan el
coste de creacin de procesos o flujos y, por lo tanto, son muy rpidos atendiendo
peticiones.
En mquinas uniprocesador, los modelos con un solo flujo funcionan bien. En
mquinas multiprocesador, es necesario usar mltiples flujos o procesos para
aprovechar el paralelismo del hardware.
10.2 ORGANIZACIN DE LAS APLICACIONES WEB:

Los servidores web se encargan de atender y servir peticiones HTTP de recursos,
que en su forma ms simple acostumbran a ser documentos guardados en el
sistema de ficheros. Sin embargo, la otra funcin importante de un servidor web es
la de actuar de mediador entre un cliente y un programa que procesa datos.
Recibe una peticin con algn argumento, la procesa y devuelve un resultado que
el servidor web entrega al cliente. La interaccin entre el servidor web y los
procesos que tiene asociados es otro aspecto que hay que considerar.
Existen distintas maneras de organizar una aplicacin web. A continuacin, por
orden cronolgico de complejidad y rendimiento creciente, se presentan distintos
modelos de organizacin.
59

CGI: es el modelo ms antiguo y simple. Para cada peticin HTTP se invoca un

programa que recibe datos por las variables del entorno y/o de entrada estndar, y
devuelve un resultado por la salida estndar. Consumir un proceso por cada
peticin genera problemas importantes de rendimiento, que el modelo FastCGI
intenta mejorar.
Servlets: es un modelo diseado para Java, ms eficiente y estructurado, que
permite elegir distintos modelos de gestin de flujos o threads, duracin de
procesos del servidor, etc. Partiendo de este modelo, se han construido servidores
de aplicaciones con mltiples funciones adicionales que facilitan el desarrollo de
aplicaciones web complejas.
CAPITULO 3 DESARROLLO SEGURO DE APLICACIONES:

LECCION 11: CONCEPTOS GENERALES PARA EL DESARROLLO SEGURO
DE APLICACIONES:
La importancia de una metodologa 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 mas 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? Suplantacin de
identidad, robo de credenciales, alteracin de los contenidos de la web, ejecucin
de acciones sin su conocimiento. Cada uno de ellos est derivado tanto de una
mala metodologa de desarrollo como de una falta de concienciacin de los
usuarios, los cuales acceden a cualquier enlace sin identificar su procedencia.
Las amenazas, debido a una mala programacin, pueden permitir al atacante
desde la obtencin de las credenciales de un usuario, hasta la modificacin del
contenido de la pgina web vulnerable pasando por la realizacin de acciones sin
conocimiento del usuario como compras o transacciones bancarias. Para cada
una de estas acciones hay soluciones ms o menos sencillas pero hace falta ms
concienciacin 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 diseo adems de
los casos de uso, los casos de abuso. Un caso de abuso, es la identificacin de
las diferentes amenazas que pueden asociarse a un caso de uso. Por ejemplo, en
60

una ventana de login (pgina donde se introduce el usuario y la contrasea)

Cules son las amenazas principales? autenticarse sin conocer la contrasea,
obtencin de credenciales, enumeracin de usuarios, Una vez identificados los
diferentes casos de abuso, el siguiente paso sera implantar y disear los
controles para evitar estas amenazas. La mayora de las amenazas se mitigan a
travs de una validacin robusta de los datos de entrada.
Cada vez es ms 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 Cul es el impacto para
la organizacin? Prdida de confianza de sus clientes con la consiguiente prdida
econmica y de imagen, impacto econmico en base a las normativas vigentes de
proteccin de datos si se publican datos de carcter personal.
Adems hay que aadir el gasto que supone la correccin de las vulnerabilidades,
este gasto es superior al gasto econmico que hubiera supuesto la realizacin de
pruebas de identificacin de vulnerabilidades en el proceso de desarrollo software.
.No existen pginas webs 100% seguras a pesar de que se les haya
implementado un ciclo de desarrollo seguro de aplicaciones.
Figura 18: Metodologa de desarrollo seguro

Fuente: <http://www.consultec.es/>
61

Entendemos por aplicaciones web a todo aqul 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 BASICAS DE SGEURIDAD:

El proyecto OWASP (Open Web Application Security Project) tiene como objetivo
ofrecer una metodologa, de libre acceso y utilizacin, 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
diseo, desarrollo, despliegue y verificacin de la seguridad de las aplicaciones y
servicios web.
La gua empieza estableciendo el principio bsico de seguridad que cualquier

aplicacin o servicio web debe cumplir:
Validacin de la entrada y salida de informacin La entrada y salida de

informacin es el principal mecanismo que dispone un atacante para enviar
o recibir cdigo 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 caractersticas de estos datos deben estar
predefinidas y debe verificarse en todas las ocasiones.
Diseos simples Los mecanismos de seguridad deben disearse para que
sean los ms sencillos posibles, huyendo de sofisticaciones que
compliquen excesivamente la vida a los usuarios. Si los pasos necesarios
para proteger de forma adecuada una funcin o modulo son muy
complejos, la probabilidad de que estos pasos no se ejecuten de forma
adecuada es muy elevada.
Utilizacin y reutilizacin de componentes de confianza Debe evitarse
reinventar la rueda constantemente. Por tanto, cuando exista un
componente que resuelva un problema de forma correcta, lo ms inteligente
es utilizarlo.
Defensa en profundidad Nunca confiar en que un componente realizar su
funcin de forma permanente y ante cualquier situacin. 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.
62

Tan seguros como en eslabn ms dbil La frase "garantizamos la

seguridad, ya que se utiliza SSL" es realmente muy popular, pero tambin
es muy inexacta. La utilizacin de SSL garantiza que el trfico en trnsito
entre el 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 cules 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 harn.
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 garanta de que tampoco ser descubierto a corto
plazo.
Verificacin de privilegios. Los sistemas deben disearse para que
funcionen con los menos privilegios posibles. Igualmente, es importante que
los procesos nicamente dispongan de los privilegios necesarios para
desarrollar su funcin, de forma que queden compartimentados.
Ofrecer la mnima informacin Ante una situacin de error o una validacin
negativa, los mecanismos de seguridad deben disearse para que faciliten
la mnima informacin posible. De la misma forma, estos mecanismos
deben estar diseados para que una vez denegada una operacin,
cualquier operacin posterior sea igualmente denegada.
Otros aspectos tratados en la gua son: consideraciones de arquitectura,

mecanismos de autenticacin, gestin de sesiones de usuario, control de acceso,
registro de actividad, prevencin de problemas comunes, consideraciones de
privacidad y criptografa
El proyecto OWASP, The Open Web Application Security Project presenta a
disposicin de todos los usuarios en la web A Guide to Building Secure Web
Applications27 y ha sido reconocida como una metodologa de desarrollo seguro
que ha dado resultados. Estos documento se presentan como anexos a este
mdulo.
27
Disponible en internet desde <http://www.owasp.org/guide/>
63

Se referencian estos documentos: Secure Programming for Linux and Unix

HOWTO28 que documentan estrategias seguras en el desarrollo de aplicaciones
web.
SPSMM - Estndar de programacin segura (Secure Programming Standards
Methodology Manual)29
LECCION 12: CONTROLES DE AUTORIZACION DE OBJETOS:
Un control simple de objeto en una aplicacin web puede ser el solo simple hecho
de comprobar el tipo de dato. La validacin de datos garantiza la correccin y
precisin de todos los valores de datos de la aplicacin. Estas acciones se pueden
disear utilizando distintos enfoques: cdigo de interfaz de usuario, cdigo de
aplicacin o restricciones de bases de datos.
Un ejemplo de validacin de control de objetos es el cdigo de servicio con tipo
de datos "character" slo puede admitir caracteres alfabticos de la A a la Z; el
resto de caracteres no sera vlido. Otro tipo de control tpico es el que se aplica al
validar un control TextBox y mostrar un mensaje personalizado cuando se produce
un error en la validacin.
De manera predeterminada, la validacin se realiza al hacer clic en un control de
botn, como Button, ImageButton o LinkButton. Hay varios tipos de validacin de
datos:
Validacin del tipo de datos.

Comprobacin del intervalo.
Comprobacin del cdigo.
Validacin compleja
La tabla 2 muestra las propiedades bsicas de un control de validacin
28
29
Disponible en internet desde <http://www.dwheeler.com/secure-programs/>

Disponible en internet dese <http://isecom.securenetltd.com/spsmm.0.5.1.en.pdf>
64

PROPIEDAD
DESCRIPCION
ControlToValidate
Id. de programacin del control de salida que evaluar el control de validacin. Si no

es un Id legtimo, se iniciar una excepcin.
Display
Modo en que se muestra el control de validacin especificado. Esta propiedad puede

ser uno de los siguientes valores:
Ninguno: El control de validacin jams se muestra en lnea. Utilice esta opcin
cuando desee mostrar el mensaje de error slo en un control ValidationSummary
Esttico: El control de validacin muestra un mensaje de error si se produce un
error en la validacin. Se asigna un espacio en la pgina Web para el mensaje de
error incluso si el control de entrada supera la validacin. No cambia el diseo de la
pgina cuando el control de validacin muestra su mensaje de error. Como el diseo
de pgina es esttico, si hay varios controles de validacin para el mismo control de
entrada, stos debern ocupar distintas ubicaciones en la pgina.
Dinmico: El control de validacin muestra un mensaje de error si se produce un
error en la validacin. El espacio para el mensaje de error se asigna dinmicamente
en la pgina cuando se produce un error en la validacin. De este modo, varios
controles de validacin pueden compartir la misma ubicacin fsica en la pgina.
EnableClientScript
Indica si est habilitada la validacin en el cliente. Para deshabilitar la validacin en

el cliente en los exploradores que admitan esta funcin, establezca la propiedad
EnableClientScript en false.
Enabled
Indica si est habilitado el control de validacin. Para impedir que el control de

validacin 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 validacin. Si no est establecida la propiedad Text del control de
validacin, tambin se muestra este texto en el control de validacin cuando se
produce un error en la validacin. Se utiliza normalmente la propiedad
ErrorMessage para proporcionar diferentes mensajes para el control de validacin y
el control ValidationSummary.
ForeColor
Especifica el color en el que se va a mostrar el mensaje en lnea cuando se produce

un error en la validacin.
IsValid
Indica si el control de entrada especificado por la propiedad ControlToValidate se

determina como vlido.
Text
Si esta establecida esta propiedad, se muestra este mensaje en el control de

validacin cuando se produce un error en la validacin. 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 validacin

Fuente: <http://www.microsoft.com/asp.net >
65

12.1 LISTAS DE CONTROL DE ACCESO (ACL)

Los controles de acceso tambin estn incluidos en aspectos de denegacin de
servicio que no solo afectan a los accesos y validaciones propios del sitio, sino
tambin al entorno del mismo.
Un ACL es una lista secuencial de sentencias de permiso o denegacin que se
aplican a direcciones IP o protocolos de capa superior. La ACL puede extraer la
siguiente informacin del encabezado del paquete, probarla respecto de las reglas
y decidir si permitir o denegar el ingreso segn los siguientes criterios:
Direccin IP de Origen
Direccin IP de Destino
Tipo de mensaje ICMP
La ACL tambin puede extraer informacin de las capas superiores y probarla

respecto de las reglas. La informacin 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
66

El funcinenlo de ACL se basa en una bsqueda de arriba abajo (de la lista de

texto plano), una lnea a la vez y se busca un patrn que coincida con el paquete
entrante. La figura 19 muestra como se realiza el filtrado de paquetes con ACL
12.1.1. Configuracin de las ACL: Pueden configurarse por Protocolo, Por
direccin y Por interfaz.
ALC por Protocolo: Para controlar el flujo de trfico de una interfaz, se debe
definir una ACL para cada protocolo habilitado en la interfaz.
ALC por Direccin: Las ACL controlan el trfico en una direccin a la vez de una
interfaz. Deben crearse dos ACL por separado para controlar el trfico entrante y
saliente.
ALC por Interfaz: Las ACL controlan el trfico 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 trfico de red para mejorar el rendimiento de esta.

Brindar control de flujo de trfico
Proporciona un nivel bsico de seguridad para el acceso a la red
Se debe decidir qu tipos de trfico 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 trfico de la red.
LECCION 13: CONSIDERACIONES DE SEGURIDAD EN WEB SERVICES:
La mayora 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.
67

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 parecera menor, es una prctica
recomendable no confiar en la seguridad de la base de datos e implementar la
seguridad a fondo y con redundancia. Si algn dato malicioso pudiera haber sido
inyectado a la base de datos, nuestra lgica de filtrado puede percatarse de ello,
pero slo si se ha implementado este mecanismo.
13.1 EXPOSICION DE DATOS

Una de las preocupaciones ms comunes relacionadas con las bases de datos es
la exposicin de datos sensibles. Al almacenar nmeros de tarjetas de crdito, 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 recomendacin es encriptar los datos ms sensibles, de
esta manera si la base de datos llega a ser comprometida el desastre ser menor.
Un ejemplo de esta tcnica es almacenar las contraseas 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 contraseas que le
permitiran el acceso al sistema ya que no es posible conocer la cadena de texto
original.
13.2 PGINAS PRIVADAS Y LOS SISTEMAS DE AUTENTICACIN

La autenticacin es el proceso por el cual la identidad de un usuario en el sistema
es validada. Comnmente el procedimiento involucra un nombre de usuario y una
contrasea a revisar. Una vez autenticado el usuario es registrado (logueado)
como un usuario que se ha autenticado. Muchas aplicaciones tienen recursos que
son accesibles slo para los usuarios autenticados, recursos que son accesibles
nicamente para los administradores y recursos totalmente pblicos.
El control de acceso debe encontrarse totalmente integrado al diseo original. No
debe ser algo improvisado sobre una aplicacin 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 trminos del
68

control de acceso, generalmente encontramos al atacante intentando registrarse

mediante un gran nmero de pruebas. En algunos casos el atacante puede
conocer nombres de usuario vlidos y la contrasea es la nica parte que se trata
de adivinar.
Limitar el nmero 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 legtimos. Una propuesta un poco ms
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 patrn, de esta forma se interfiere menos el uso
al usuario legtimo.
Otra opcin sera imponer un intervalo de tiempo pequeo (ejemplo 15 segundos)
que se debe esperar para poder intentar registrarse en el sistema de nuevo
despus de una falta en la autenticacin. 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 razn 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 CONTRASEAS (PASSWORD SNIFFING)

Cuando un atacante tiene los medios para analizar el trfico entre los usuarios y el
servidor de la aplicacin, debemos preocuparnos por la exposicin 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 tecnologa tanto para cuando se enven las
credenciales de acceso como los identificadores de una sesin ya establecida, de
esta forma evitamos un secuestro de la sesin.
Usar SSL para proteger el envo de HTML es adems 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 leccin Mitos de seguridad en aplicaciones web,
sta sola medida no es suficiente.
69

13.5 REGISTROS PERSISTENTES

Cuando un usuario permanece en el estado de registrado despus de un tiempo
no razonable (cuando la sesin expir por ejemplo), tenemos un problema de
registros persistentes. Este tipo de problemas disminuyen la seguridad de nuestro
mecanismo de autenticacin. Generalmente estos problemas son causados por
una cookie persistente, o un ticket enviado al usuario para hacer referencia a la
sesin de registro establecida que no se considera como expirado jams o que no
cambia en cada nuevo registro establecido por el usuario.
Si el ticket de acceso permanece constante para cualquier sesin establecida
tenemos un problema serio, la manera ms sencilla de evitarlo es hacindolo
dependiente de una variable aleatoria.
Otra medida recomendable es requerir la contrasea 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.
LECCION 14: VALIDACION DE ENTRADAS:
La debilidad de seguridad ms comn en aplicaciones web es la falta de

validacin 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 inyeccin de cdigo SQL, de comandos,
LDAP, XPath, XML o por XSS.
Esta debilidad lleva a casi todas las principales vulnerabilidades en las
aplicaciones, tales como intrprete de inyeccin, 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 podra manipularlos. Hay que
garantizar que la aplicacin 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 validacin de los datos:
70

Vulnerabilidad de la integridad de los datos: El atacante manipula los datos

introduciendo intencionadamente datos errneos que manipulan la funcin de
negocio.
Violacin del formato de los datos: Un atacante consigue introducir datos sin la
sintaxis correcta, fuera de los lmites de longitud, que contenga caracteres no
permitidos, con signo incorrecto o fuera de los lmites del rango. Esto provoca un
mal funcionamiento de la aplicacin.
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
aplicacin.
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 validacin formal.
Ante todo esto, el W3C desarroll un nuevo lenguaje (XML), que proporciona:
Extensibilidad: se pueden definir nuevas marcas y atributos segn sea necesario.
Estructura: se puede modelar cualquier tipo de datos que est organizado
jerrquicamente.
Validez: podemos validar automticamente 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 propsitos especficos. Estas definiciones, e incluso las
definiciones de programas de traduccin y transformacin de ficheros XML, se
definen en XML, lo que da una muestra de la potencia de XML. En XML se ha
definido gran nmero de lenguajes. De hecho, el fichero de configuracin de
algunos de los programas ms usados en la web (Tomcat, Roxen, etc.) est
definidos con XML. Hay muchos ficheros de datos, de documentos, etc., que
tambin lo usan para su definicin.
Algunos de los lenguajes definidos con XML ms conocidos son:
SVG (scalable vector graphics).

71

DocBook XML (Docbook-XML).

XMI (XML metadata interface format).
WML (WAP markup language).
MathML (mathematical markup language).
XHTML (XML hypertext markup language).
XML posibilita la comprobacin automtica de la correcta forma de un documento,

pero sin informacin adicional es imposible comprobar la validez de ste a partir
del propio documento. Para ello, el W3C ha desarrollado algunos estndares de
XML que permiten validar un documento a partir de una especificacin formal de
cmo debe ser ste. Dichos estndares son DTD y XSchema.
DTD es un estndar antiguo, derivado de SGML y que adolece de algunas
deficiencias graves, siendo la ms grave de ellas el hecho de no estar escrito en
XML. XSchema, por otro lado, es un estndar relativamente moderno, muy
potente y extensible, que adems est escrito en XML ntegramente. Muchas de
las entradas de validacin de datos se apoyan en este estndar.
LECCION 15: SQL IJECTION:
La inyeccin SQL (Structured Query Language) Injection es un ataque en el que

se inserta cdigo SQL o como anexo en los parmetros de entrada de la solicitud
de usuario que posteriormente se pasan a un servidor back-end de SQL Server
para su anlisis y ejecucin. Cualquier procedimiento que construye declaraciones
SQL podra ser vulnerable, ya que la naturaleza diversa de SQL y los mtodos
disponibles para la construccin que proporcionan una gran cantidad de
codificacin.
Un ataque menos directo inyecta cdigo malicioso en las cadenas que estn
destinados para el almacenamiento en una tabla o como metadato. Cuando estas
cadenas son almacenadas posteriormente se concatenan en una tabla dinmica
que ejecuta comandos inesperados y sentencias de SQL y es all donde el cdigo
malicioso es ejecutado en la aplicacin web.
Cuando se utiliza un servidor SQL para ejecutar comandos que interactan 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 informacin muy privilegiada.
72

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 travs de la siguiente URL:
http://www.victim.com/products.php?val=100
El ejemplo de la URL anterior utiliza los parmetros GET en lugar de POST de parmetros
para facilitar la ilustracin. Parmetros POST son tan fciles de manipular, sin embargo,
esto generalmente implica el uso de otro componente, como una herramienta de
manipulacin de trfico, navegador Web plug-in o aplicacin proxy en lnea
El atacante intenta inyectar sus propios comandos SQL modificando el parmetro

de entrada val aadiendo 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 lgica de la pregunta. Esto sucede porque los
resultados de la instruccin 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 inyeccin 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 estn 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 cmo un atacante puede manipular una

sentencia SQL creada dinmicamente 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 aplicacin no previ.
73

El ejemplo, sin embargo, tal vez no ilustra la eficacia de esa vulnerabilidad;

despus de todo, slo se utiliza el vector (vec) para ver todos los productos en la
base de datos, y que un usuario legtimo podra haberlo hecho mediante la
consulta a la misma aplicacin. Si esa misma aplicacin fuera administrada de
forma remota mediante utilizando un sistema de gestin de contenidos (CMS) (Un
CMS es una aplicacin 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 podra acceder a la aplicacin CMS mediante la siguiente URL:
http://www.victim.com/cms/login.php?username=foo&password=bar
La aplicacin CMS requiere que usted proporcione un nombre de usuario y

contrasea para poder acceder a su funcionalidad de administrar y modificar el
sitio. Si un atacante digita un nombre de usuario y contrasea errados, la
aplicacin devuelve un error "nombre de usuario o contrasea incorrecta, por
favor, intntelo de nuevo". Aqu est el cdigo 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
mysql_num_rows($result);
rows
were returned from
the database
$rowcount
// 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 dinmicamente una sentencia SQL que devuelve un

conjunto de registros si un nombre de usuario y contrasea correspondiente es
74

digitado. La sentencia SQL que el script de PHP genera y ejecuta, se ilustra ms

claramente en la consulta siguiente:
SELECT userid
FROM CMSUsers
WHERE user = 'foo' AND password = 'bar';
Devolver el ID de usuario que corresponde al usuario y los valores de la

contrasea si los datos introducidos coinciden con un valor correspondiente
almacenado en la tabla de CMSUsers
El problema con el cdigo es que el desarrollador de aplicaciones asuma que el
nmero de registros devueltos cuando la secuencia de comandos se ejecuta
siempre ser cero o uno. En el ejemplo anterior la inyeccin, se utiliz el vector
explotable para cambiar el significado de la consulta SQL para devolver siempre el
valor true. Si utilizamos la misma tcnica con la aplicacin de la CMS, podemos
hacer que la lgica de la aplicacin falle. Aadiendo la cadena 'OR '1' = '1 a la
siguiente direccin 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 estn 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 lgica

de las consultas o peticiones de acceso. Esto sucede porque los resultados de la
instruccin 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 lgica de la aplicacin significa que si la base de datos devuelve ms de cero

registros, debemos haber entrado en las credenciales de autenticacin correctas y
deben ser redirigido y con acceso al script admin.php. Con esto se ha modificado
la lgica de la aplicacin y la inyeccin de cdigo ha surtido efecto.
75

Ahora especifiquemos Cmo un intruso inyectar una sentencia SQL en

lugar de colocar el nombre de usuario, Password y cuenta?:
En la figura 20 se muestra una web con formularios de ingreso que podran ser
vulnerables:
Figura 20: Formulario de validacin de datos

Fuente: El Autor
Si los campos de datos, la aplicacin y el gestor de datos no estn 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 cdigo SQL.
SELECT id
FROM login
WHERE usuario = admin
AND clave = OR
AND cuenta = 46789675
76

Un parmetro no esperado, como esta comilla, cambia el comportamiento de la

aplicacin. De este modo , si el usuario es el admin y tiene un Password / con la
condicin, si 1 es igual a 1(que de hecho lo es), ste ser vlido y tendr acceso a
la aplicacin web o a la intranet en la mayora de casos.
Cmo saber que determinado campo de datos o URL, es vulnerable a la
inyeccin de cdigo 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 mtodos que son propios de cada navegador
o aplicacin de ataque o de monitoreo.
Cmo buscar en Internet sitios web
con formularios de acceso a
aplicaciones web tentativamente vulnerables?
En un buscador se pueden dar estas opciones de bsqueda que darn 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
contrasea.asp clave.asp intitle:acceso restringido site.asp
Incluso en muchos casos, son tan vulnerables que la aplicacin leva al usuario al
salto de la famosa pregunta secreta para restaurar la contrasea.
15.1 VARIANTES DE SINTAXIS:

Las variantes de sintaxis (en inyeccin) varan segn el gestor de base de datos
(MS-SQL, Mysql, Oracle, PostgreSQL).
15.2 OTRAS CLASES DE INYECCIN:

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.
77

UNIDAD 2: ANALISIS Y DISEO SEGURO DE APLICACIONES WEB

CAPITULO 4: AREAS CRTICAS DE DESARROLLO:
LECCION 16: SECUENCIA DE COMANDOS EN SITIOS CRUZADOS (XSS)
XSS es un tipo de vulnerabilidad de seguridad informtica tpicamente encontrada

en aplicaciones web que permiten la inyeccin de cdigo por usuarios maliciosos
en pginas web vistas por otros usuarios.
Los atacantes tpicamente se valen de cdigo HTML y de scripts ejecutados en el
cliente. Una vulnerabilidad de este tipo puede ser usada por los atacantes para
burlar los controles de acceso comunes. Recientemente este tipo de ataques han
sido explotados para crear poderosos ataques de phishing y de abusos en el
navegador.
Desde la liberacin del lenguaje JavaScript, se previeron los riesgos de permitir a
un servidor Web enviar cdigo ejecutable al navegador. Un problema se presenta
cuando los usuarios tienen abiertos varias ventanas de navegador, en algunos
casos un script de una pgina podra acceder datos en otra pgina u objeto,
observando el peligro de que un sitio malicioso intentara acceder datos sensibles
de esta forma. Por ello se introdujo la poltica same
origin. Esencialmente esta
poltica permite la interaccin entre objetos y pginas, 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 va
JavaScript.
A partir de entonces se han introducido otros mecanismos y polticas 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 tcnicas de evasin de las
polticas de proteccin. Encontrando formas ingeniosas de inyectar cdigos
maliciosos en las pginas servidas por otros dominios, un atacante puede ganar
privilegios a datos sensibles, cookies de sesin y otros objetos.
16.1 TIPOS DE VULNERABILIDAD XSS
Existen dos diferentes tipos de vulnerabilidades XSS:
78

Tipo 0: Tambin conocido como basado en el DOM o Local. Con este tipo de
vulnerabilidad, el problema existe en el script del lado del cliente.
Si un cdigo de JavaScript accede a una URL como un parmetro de una peticin
al servidor y utiliza esta informacin para escribir HTML en la misma pgina sin ser
codificada empleando entidades HTML, existe un agujero XSS, dado que estos
datos escritos sern interpretados por los navegadores como cdigo HTML que
puede incluir en si cdigo adicional del lado del cliente.
Los ataques de este tipo pueden devenir en la ejecucin remota de comandos. En
el caso de que el atacante suba un sitio malicioso, que contenga un link a una
pgina vulnerable en el sistema de archivos del cliente, resultando en la ejecucin
con privilegios del navegador del sistema. De esta manera no slo se pasan las
restricciones de comunicacin entre dominios.
Tipo 1: A este tipo de agujero XSS se le conoce tambin como no persistente o

reflejado, y es por mucho el ms comn. Estos agujeros aparecen cuando los
datos provistos por un cliente web son usados inmediatamente en el lado del
servidor para generar una pgina de resultados para el usuario. Si los datos no
validados por el usuario son incluidos en la pgina resultante sin codificacin
HTML, se le permite al cliente inyectar cdigo en la pgina dinmica.
Un ejemplo clsico de este tipo es en los motores de bsqueda, si alguno busca
una cadena que incluya caracteres especiales HTML, comnmente la cadena de
bsqueda ser formateada para representar lo que se busc, o al menos incluir
los trminos de la bsqueda en la caja de texto para ser editados. Si las
ocurrencias de los trminos no son codificados como entidades HTML existe un
agujero XSS.
Esto no parecera un problema dado que los usuarios son los nicos que pueden
inyectar cdigo en sus propias pginas. Pero con un pequeo esfuerzo de
ingeniera social, un atacante puede convencer a alguien de seguir una URL que
se encargue de inyectar el cdigo en esta pgina de resultados, dando al atacante
acceso completo al contenido de la pgina.
La mejor forma de proteger una aplicacin de ataques XSS es asegurarse de que
la aplicacin valide todas las cabeceras, cookies, queries a la base de datos,
campos de las formas (entre estos los campos ocultos). Es decir, todos los
parmetros entrantes teniendo como referencia una especificacin rigurosa de lo
que debe ser permitido.
79

De ninguna manera el proceso de validacin debe intentar identificar el contenido

peligroso y removerlo, filtrarlo o sanearlo. Existen muchos tipos de contenido
activo o peligros y muchas maneras de codificarlo para burlar los filtros para este
tipo de contenido.
Se recomienda ampliamente utilizar un esquema positivo de poltica de seguridad
(listas blancas) que especifique de forma clara lo nico que es permitido
Las polticas de lista negra son complicadas de mantener actualizadas y siempre
con posibilidades de quedar incompletas.
Codificar la salidas que dependan de los datos provistos por el usuario es una
manera eficaz de evitar vulnerabilidades XSS previniendo la transmisin de scripts
insertados a usuarios en una forma ejecutable.
Las aplicaciones pueden ganar proteccin de los ataques basados en JavaScript
convirtiendo los caracteres especiales en su equivalente codificado en entidad
HTML.
1.< < or <

2.> > or >
3.& & or &
4." " or "
5.' ' or '
6.( (
7.) )
8.# #
9.% %
10.; ;
11.+ +
12. &#45
Es preferible utilizar un esquema de lista blanca como la funcin
HTMLEntityEncode de Java. Adems es crucial deshabilitar el soporte de HTTP
TRACE en los servidores web (Apache, IIS, etc.) al hacerlo evitaremos que el
servidor devuelva los parmetros de la solicitud errnea recibida.
La secuencia de comandos en sitios cruzados, ms conocida como XSS 30,
es en realidad un subconjunto de inyeccin HTML El proyecto OWASP incluye
dentro de su Top 10 esta vulnerabilidad con todos los matices y aspectos de
30
Disponible en internet desde <https://www.owasp.org/index.php/Top_10_2007Secuencia_de_Comandos_en_Sitios_Cruzados_%28XSS%29>
80

proteccin, entornos afectados, herramientas usadas, monitoreo, ejemplos y sitios

online de prueba para realizar los ataques.
LECCION 17: PERDIDA DE AUTENTICACION Y GESTION DE SESIONES
Concepto:
Permiten suplantar la informacin de un usuario determinado.
Ejemplo la cuenta del Administrador para sabotear controles de autorizacin y
registro. Otra caracterstica es el acceso no autorizado a informacin que se
encuentre almacenada en el servidor o los servicios que han sido comprometidos.
Cuando se presentan:
Cuando se gestionan las contraseas.

Cuando expiran las sesiones o el proceso de cierre de sesin.
Cuando hay recuperacin de los valores del usuario de forma automtica.
Cuando se trae la famosa Pregunta secreta.
Cuando se actualiza una cuenta.
Cuando el usuario pierde su contrasea y solicita Recordar contrasea
EJEMPLO DE PRDIDA DE AUTENTICACION:

Un usuario autenticado puede consultar una serie de artculos de una determinada
categora. Navegando por cada uno de los artculos accede a uno que le interesa
y que quiere compartir con sus amigos, por lo que accede a la URL que tiene en
su navegador.
Luego cierra su navegador y postea en una red social este enlace para que todos
puedan acceder a este curioso artculo.
El servidor no cierra la sesin del usuario. Cualquiera de sus amigos que acceda
a dicho enlace aparecer registrado en la aplicacin como el usuario autenticado
En la figura 21 se ilustra este ejemplo de prdida de autenticacin
81

Figura 21: Prdida de Autenticacin

Fuente: El Autor
Formas de proteccin:
Cierre de sesin correctamente mediante los enlaces del sitio para ello (no
cerrar ventanas)
Gestin de contraseas
Tiempo de desconexin.
Eliminar la opcin recordar contrasea en los navegadores
Pregunta secreta.
Actualizacin de cuentas.
Utilizar conexiones SSL.
Ingreso de identificadores no validos.
82

LECCION 18: REFERENCIA DIRECTA INSEGURA A OBJETOS
Una referencia directa insegura a objetos ocurre cuando un desarrollador expone

una referencia a un objeto de implementacin interno, tal como un fichero,
directorio, o base de datos. Sin un chequeo de control de acceso u otra proteccin,
los atacantes pueden manipular estas referencias para acceder datos no
autorizados.
Por ejemplo, en las aplicaciones Home Banking, es comn usar el nmero de
cuenta como clave primaria. Por lo tanto, es tentador usar el nmero de cuenta
directamente en la interfaz web. Incluso si los desarrolladores tomaron las
medidas necesarias para prevenir ataques de SQL Injection, si no hay
validaciones extra que verifiquen que el usuario es el dueo de la cuenta y que
est autorizado para verla, un atacante puede forzar el parmetro nmero de
cuenta y lograr ver o cambiar todas las cuentas.
Los escenarios tpicos donde se presentan: Una aplicacin presenta una
referencia directa insegura a objetos, por ejemplo, una lista con posibles
documentos que pueden ser seleccionados para ser visualizarlos, donde cada
entrada de la lista referencia directamente a un fichero del sistema de archivos.
Un atacante, como usuario autorizado en el sistema, simplemente modifica el valor
de un parmetro (uno de esos documentos) que se refiere directamente a un
objeto del sistema a otro objeto para el que el usuario no se encuentra autorizado.
Normalmente, las aplicaciones utilizan el nombre o clave actual de un objeto
cuando se generan las pginas web. Las aplicaciones no siempre verifican que el
usuario tiene autorizacin sobre el objetivo. Esto resulta en una vulnerabilidad de
referencia directa insegura a objetos. Los auditores pueden manipular fcilmente
los valores del parmetro para detectar estas vulnerabilidades y un anlisis de
cdigo mostrara rpidamente si la autorizacin se verifica correctamente.
Definicin de objeto: Elementos internos de la aplicacin, es decir, ficheros,
directorios y registros de bases de datos que utiliza nuestra aplicacin para
almacenar informacin, y que son referenciados a travs de parmetros en urls o
en formularios. Por esto ltimo se dice que se realiza una referencia directa de
ellos, porque segn la informacin que contengan estos parmetros, se acceder
a uno u otro dato.
83

Ejemplo de algunas vulnerabilidades:
Enlace a una carga de con la informacin de un nmero de cuenta: Si se

desea ingresar a la informacin de un nmero de cuenta de un usuario que
tiene por identificacin el nmero: 1234567890
URL: https://www.ejemplo/cuentas.php?cuenta=1234567890
Con esto se cargaran los movimientos de dicha cuenta propiedad del usuario. Si
se introduce otro nmero de cuenta cercano por arriba o abajo del nuestro, por
ejemplo 1234567891, en principio, si todo se hubiera hecho correctamente,
debera mostrar un error al estar introduciendo una cuenta ajena, pero si somos
vulnerable a la referencia directa de objetos de forma insegura, mostrar los datos
de esta cuenta sin ser nuestra.
Descarga de un archivo que no es controlada o sin restriccin: Si se tiene

un enlace de descarga de un archivo pdf con el reporte bancario de un
extracto o algo similar en la que el nombre del archivo de la descarga se
referencia por el nmero de cdula del cliente as:
URL: http://www.banco.com/descarga.php?dir=nomina&file=10234765.pdf
Con tan solo modificar un nmero en la cdula del usuario, se podra estar
descargando la informacin de otro usuario,
La referencia directa insegura a objetos, es incluido en el proyecto OWASP dentro
de su Top 10.31
LECCION 19: ALMACENMIENTO CRIPTOGRAFICO INSEGURO:
Este tipo de vulnerabilidad ocurre cuando:
No se identifican todos los datos sensitivos

No se identifican todos los lugares donde estos datos son almacenados:
Base de datos, ficheros, carpetas, archivos de log, backups, etc.
No se protege esta informacin en todas sus ubicaciones
31
Disponible en internet desde <https://www.owasp.org/index.php/Top_10_2007Referencia_Insegura_y_Directa_a_Objetos>
84

Los impactos:
Atacantes acceden o modifican informacin privada o confidencial: Ej.,

tarjetas de crdito, registros mdicos, datos financieros
Atacantes extraen secretos a ser usados en otros ataques
Mala Imagen para la Compaa, clientes insatisfechos, y prdida de
confianza
Gastos para corregir el incidente, tales como anlisis forense, enviar cartas
de disculpas, nueva impresin de tarjetas de crdito, etc.
El Negocio es demandado o multado
Como evitarlo:
Verificar la arquitectura
Identificar todos los datos sensitivos

Identificar todos los lugares donde estos datos son almacenados
Utilice encripcion para contrarrestar las amenazas, no solo para encriptar
datos
Proteger la informacin con mecanismos apropiados
Encripcin en ficheros, base de datos, etc.
Utilizar los mecanismos correctamente
Usar nicamente algoritmos pblicos reconocidos (como AES, RSA, y SHA256)

No utilizar algoritmos considerados dbiles (como MD5 o SHA1)
Nunca transmitir claves privadas por canales inseguros
No almacenar informacin innecesaria. Ej, cdigo CVV de tarjeta de crdito
(req. PCI DSS)
Verificar la implementacin
Un algoritmo estndar es utilizado, y es el algoritmo apropiado para dicha

situacin
Todas las llaves, certificados, y contraseas se encuentran debidamente
almacenadas y protegidas
Los mtodos para distribuir las llaves son seguros y efectivos
Mas difcil: Analizar el cdigo de encripcin por posibles fallas
85

Figura 22: Almacenamiento criptogrfico inseguro

Fuente: El Autor
LECCION 20: RESTRICCIONES DE ACESO A URL:
Comnmente, la nica proteccin de una URL, es que el enlace a esa pgina no

se muestre a usuarios no autorizados. Sin embargo, un atacante motivado,
habilidoso o simplemente con suerte, puede ser capaz de encontrar el acceso a
estas pginas, invocar funciones, y visualizar informacin. La seguridad por
oscuridad no es suficiente para proteger la funcionalidad e informacin en una
aplicacin. La revisin de control de acceso debe ser realizada antes de que una
peticin a una funcin sensible se conceda, lo cual asegura que el usuario est
autorizado para acceder a esa funcin.
Muchas aplicaciones web verifican los privilegios de acceso a URL antes de
generar enlaces o botones protegidos. Sin embargo, las aplicaciones necesitan
realizar controles similares cada vez que estas pginas son accedidas, o los
atacantes podrn falsificar URL para acceder a estas pginas igualmente.
86

Entornos afectados
Todos los entornos de aplicaciones Web son vulnerables a las fallas de
restricciones de acceso a URL.
Caractersticas:
Explotacin fcil: Explotacin es fcil porque solo basta con cambiar la URL
sin privilegios a una pgina con privilegios.
Prevalencia Poco comn: La deteccin de esta falla porque para el atacante
es difcil identificar que URLS tienen esta vulnerabilidad
Deteccin media: Suele pasar inadvertida esta vulnerabilidad por los
escneres. Los escneres de vulnerabilidades y los motores de anlisis
esttico tienen dificultades con la verificacin de control de acceso a URLs,
pero por razones diferentes. Los escneres de vulnerabilidades tienen
dificultades para adivinar las pginas ocultas y determinar qu pginas se
deben permitir para cada usuario, mientras que los motores de anlisis
esttico batallan para identificar los controles de acceso personalizado en el
cdigo y vincular la capa de presentacin con la lgica de negocio.
Impacto moderado: El impacto de esta falla es moderado porque permite el
acceso no autorizado a funciones administrativas de la aplicacin.
Vulnerabilidad:
El mtodo primario de ataque para esta vulnerabilidad es llamado "navegacin
forzada", que abarca adivinado de enlaces y tcnicas de fuerza bruta para
encontrar paginas desprotegidas. Las aplicaciones permiten con frecuencia que el
cdigo de control de acceso se desarrolle y se separe a travs de cdigo fuente,
dando como resultado un modelo complejo que sea difcil de entender para los
desarrolladores y para los especialistas de la seguridad tambin. Esta complejidad
hace que sea probable que se produzcan errores de pginas perdidas, dejndolas
expuestas
Algunos ejemplos comunes de estos defectos incluyen:
URL "ocultas" o "especiales, suministradas slo a administradores o

usuarios con privilegios, pero accesibles a todos los usuarios si ellos saben
que
existen,
tales
como
/administrar/agregarusuario.php
o
/aprobarTransferencia.do. Esto es particularmente predominante con cdigo
de men.
87

Las aplicaciones a menudo permiten el acceso a archivos "ocultos", tales

como XML estticos o reportes generados por el sistema, confiando en la
seguridad por oscuridad para ocultarlos
Proteccin.
Bloquear o eliminar pginas mediante un archivo robots.txt
CAPITULO 5: CICLO DE VIDA DE DESARROLLO SEGURO DE SOFTWARE

(SDLC)
LECCION 21: NTRODUCCION A SDLC:
Actualmente la mayora de los procesos de desarrollo no incluyen seguridad, o

bien la incluyen al final (etapa de testing). El costo de solucionar las
vulnerabilidades es mayor cuanto ms tarde se detectan las mismas (igual que los
bugs). En la figura 23 se identifica al relacin costo tiempo con las fases de
desarrollo de una aplicacin web.
Figura 23: Relacin costo tiempo en el desarrollo de aplicaciones web

Fuente: El Autor
88

El modelado de amenazas es una tcnica formal, estructurada y repetible que

permite determinar y ponderar los riesgos y amenazas a los que estar expuesta
una aplicacin y que puede aplicarse al Ciclo de Vida del Desarrollo de Software
(SDLC).
AL rededor de este ciclo de vida de desarrollo seguro de software, surgen mitos
que vencer como:
La seguridad de la aplicacin es responsabilidad del programador.

Nadie sabe cmo funciona, por ende, no la van a atacar.
A nadie le interesara atacar nuestra aplicacin.
La aplicacin es segura porque corre detrs de un firewall.
La aplicacin es segura porque usa encripcin.
Si no corre como Administrator / root, no funciona.
No hay tiempo para incluir seguridad
Para eliminar estas premisas, la tendencia actual y que se debe seguir para
aplicar el ciclo de desarrollo, enmarca aspectos como:
Participacin de Seguridad Informtica desde el comienzo de todos los proyectos
de desarrollo.
Incorporar seguridad a lo largo de todas las etapas del ciclo de vida del desarrollo
de software (SDLC).
LECCION 22: FASES DE SDLC:
El ciclo de desarrollo de los sistemas o ciclo de vida de los sistemas (SDLC:

Systems Devetopment Life Cycle) es un enfoque por etapas de anlisis y de
diseo, que postula que el desarrollo de los sistemas mejora cuando existe un
ciclo especfico de actividades del analista y de los usuarios.
89

Figura 24: SDLC

Fuente: <CLARK, Justin. SDLC >
22.1 SEGURIDAD EN LA FASE DE ANLISIS: Durante el anlisis de

requerimientos, se pueden identificar diversas caractersticas que derivarn en los
requerimientos de seguridad del software. Por ejemplo:
Arquitectura de la aplicacin: Cliente/servidor o Desktop?
Plataforma donde correr la aplicacin: PC / Palm / Telfono celular
Tipos de datos que se almacenan o transfieren: Confidenciales / pblicos
Requerimiento de compliance con normativas y marcos regulatorios: SOX, PCIDSS, A 4609
Tipos de registro que el sistema debe generar: Acceso a recursos, uso de
privilegios, etc.
Perfiles de usuario necesarios para la aplicacin: Administrador, revisor, editor,
usuario bsico, etc.
Tipos de acceso a los datos por parte de cada perfil: Lectura, escritura,
modificacin, agregado, borrado, etc.
Acciones sobre el sistema que puede hacer cada perfil: Cambiar la configuracin
del sistema, arrancar o detener servicios
Modos de autenticacin: Passwords, Tokens, Biomtricos.
90

22.2 SEGURIDAD EN LA ETAPA DE DISEO: Muchas de las vulnerabilidades

encontradas en aplicaciones web tienen su causa en errores de diseo. Ejemplos
de ello:
Aplicacin Home banking (WEB): Inclua el nmero de cuenta en el request de
transferencias. No validaba que la cuenta origen perteneciera al usuario logueado.
Vulnerabilidad: Transferencias desde cuentas ajenas
Aplicacin de Adm y Finanzas (Consola Unix): Tomaba el usuario de una variable
de entorno. Permita que el usuario escapara a un Shell. Vulnerabilidad: Se
puede establecer un usuario arbitrario
Buenas prcticas para el diseo de una aplicacin segura incluyen aspectos
como:
Reduccin de Superficie de ataque

Criterio del menor privilegio
Fallar de manera segura
Criterio de defensa en profundidad
Diseo seguro de mensajes de error
Diseo seguro de autenticacin
Separacin de privilegios
Interaccin amigable con Firewalls e IDS's.
Administracin segura informacin Sensible
Diseo de Auditora y Logging
Anlisis de riesgo
Durante esta etapa de diseo se suelen aplicar tcnicas para analizar el riesgo,
como:
Anlisis de riesgo Threat Modeling: Tcnica formal, estructurada y repetible
que permite determinar y ponderar los riesgos y amenazas a los que estar
expuesta nuestra aplicacin.
Consta de las siguientes etapas:
1) Conformar un grupo de anlisis de riesgos
2) Descomponer la aplicacin e identificar componentes clave.
3) Determinar las amenazas a cada componente de la aplicacin.
4) Asignar un valor a cada amenaza.
91

5) Decidir cmo responder a las amenazas.

6) Identificar las tcnicas y tecnologas necesarias para mitigar los riesgos
identificados.
Mtodo STRIDE: Ayuda a identificar amenazas en los componentes de un

sistema. Su nombre es un acrnimo de:
Spoofing Identity: Suplantar la identidad de otro usuario o servicio.

Tampering with Data: Modificar maliciosamente datos almacenados.
Repudiation: Imposibilidad de identificar el autor de una accin.
Information Disclosure: Divulgar informacin a usuarios no autorizados.
Denial of Service: Provocar que un servicio deje de funcionar.
Elevation of privilege: Conseguir privilegios mayores a los asignados
Mtodo DREAD: Ayuda a ponderar las amenazas identificadas. Es un acrnimo

de los siguientes 5 tems:
Damage Potencial: Cun importante es el dao de esta amenaza?

Reproducibility: Cun reproducible es la vulnerabilidad?
Exploitability: Cun fcil es de explotar?
Affected Users: Cules y cuntos usuarios se veran afectados?
Discoverability: Cun fcil de descubrir es la vulnerabilidad?
22. 3 SEGURIDAD EN LA CODIFICACION: La falta de controles adecuados en la

codificacin, muchas veces deriva en vulnerabilidades que pueden comprometer a
la aplicacin o a los datos de la misma
Los tipos de vulnerabilidades ms habituales y que directamente son producto de
una codificacin de mediano y bajo perfil de seguridad son:
92

Stack buffer overflows

Heap buffer overflows
SQL Injections
Cross Site Scripting (XSS)
Directory Traversal
Stack buffer overflows
Heap buffer overflows
SQL Injections
Cross Site Scripting (XSS)
Directory Traversal
Las prcticas recomendadas para la codificacin segura cuando se desarrollan

aplicaciones web son:
Validar siempre los datos de entrada antes de procesarlos

Nunca confiar en que los datos recibidos sean correctos.
Realizar validacin de datos en todas las capas
Usar siempre criterio de White List en las validaciones
Controlar tamao y tipo de datos
Sanitizar los valores de entrada y salida
Eliminar o escapear caracteres especiales
Transformar los datos de entrada a un encoding establecido
Reemplazar sentencias SQL dinmicas por Stored Procedures
Evitar generar cdigo con valores ingresados por el usuario
No mezclar datos con cdigo
Capturar errores de capas inferiores y no mostrarlos al usuario
22.4 SEGURIDAD EN LA ETAPA DE TESTING (PRUEBAS): Se aplican varias

tcnicas en esta etapa:
Testing de seguridad funcional: Testing Funcional (clsico) aplicado a las
funcionalidades de seguridad de una aplicacin. Ejemplos:
Requisitos. de autenticacin
Requisitos. de complejidad de contraseas Bloqueo automtico de cuentas
Funcionalidad de captchas
Restricciones de acceso segn diseo
Mecanismos de registro y logging
Mensajes de error especificados
93

Testing de seguridad basado en Riesgo: Tcnica que se desprende del Threat

Modelling. Se identifican todas las interfaces de la aplicacin. Se generan casos
de test sobre cada interfaz basado en STRIDE
Testing con un cliente / server falso: Consiste en disear un cliente o server Ad
Hoc que permita:
Enviar peticiones /respuestas incorrectas o invlidas.

Enviar peticiones/ respuestas fuera de orden.
Insertar delays arbitrarios.
Comportarse de manera diferente al cliente o servidor real.
Test de stress: Consiste en llevar la carga o funcionalidad de la aplicacin al

lmite
Generar una carga alta de peticiones/transacciones a la aplicacin.

Mantener esta carga durante tiempos prolongados.
Simular trfico en rfagas.
Test de mutacin de datos: Se testea la aplicacin ingresando en sus interfaces

datos mutados. Entre estos datos se pueden citar: Diferente signo, diferente tipo,
diferente longitud, fuera de rango, caracteres especiales, cdigo (ej: javascripts),
valores nulos, valores aleatorios
22.5 SEGURIDAD EN LA ETATA DE IMPLEMENTACION: Se suelen aplicar

tcnicas como: Hardening de software de base que comprende aplicar aspectos
como:
Servicios innecesarios
Usuarios y contraseas default
Configuracin de intrpretes
Proceso de implementacin
Separacin de ambientes
Administracin de implementacin y mantenimiento
Releases y Patches
Firma de cdigo
94

LECCION 23: SDLC - IT:
(SDLC - IT: Systems Devetopment Life Cycle for Information Tecnologies) En

general, los analistas no estn de acuerdo respecto al nmero exacto de etapas
que conforman el ciclo de desarrollo de los sistemas para aplicaciones, y en
general para las tecnologas de la informacin; sin embargo, se reconoce la
importancia de su enfoque sistemtico. Este ciclo especfico de vida consta de
siete capas o etapas que aunque se presentan de manera discreta, nunca se
llevan a cabo como un elemento Independiente. En lugar de ello se realizan
al mismo tiempo diversas actividades, y stas llegan a repetirse. Por ello es de
mayor utilidad suponer que e! ciclo de desarrollo de los sistemas transcurre en
etapas (con actividades en accin que luego cesan poco a poco) y no como
elementos separados
1) Identificacin de problemas, oportunidades y objetivos.
En esta primera etapa del ciclo de desarrollo de los sistemas, el analista se
involucra en la identificacin de los problemas, de las oportunidades y de los
objetivos. Esta fase es crucial para el xito del resto del proyecto, pues nadie
estar dispuesto a desperdiciar su tiempo dedicndolo al problema equivocado.
La primera etapa requiere que el analista observe de forma objetiva lo que ocurre
en una empresa. Luego, en conjunto con los otros miembros de la organizacin
har notar los problemas. Muchas veces esto ya fue realizado previamente: y por
ello es que se llega a invitar al analista.
Las oportunidades son acuellas situaciones que el analista considera que pueden
perfeccionarse mediante el uso de los sistemas de informacin computarizados. Al
aprovechar las oportunidades, la empresa puede lograr una ventaja competitiva o
llegar a establecer un estndar industrial.
La identificacin de objetivos tambin es un componente importante de la primera
fase. En un comienzo, el analista deber descubrir lo que la empresa intenta
realizar, y luego estar en posibilidad de determinar si el uso de los sistemas de
informacin apoyara a la empresa para alcanzar sus metas, el encaminarla a
problemas u oportunidades especficas.
2) Determinacin de los requerimientos de informacin.
La siguiente etapa que aborda el analista, es la determinacin de los
requerimientos de informacin a partir de los usuarios particularmente
95

involucrados. Para identificar los requerimientos de informacin dentro de a

empresa, pueden utilizarse diversos instrumentos, los cuales incluyen: el
muestreo, el estudio de los datos y formas usadas por la organizacin,
la
entrevista, los cuestionarios: la observacin de la conducta de quien toma
las decisiones, asi como de su ambiente: y tambin el desarrollo de prototipos.
En esta etapa el analista hace todo lo posible por identificar qu informacin
requiere el usuario para desempear sus tareas. Puede ver, cmo varios de los
mtodos para establecer las necesidades de informacin,
lo obligan a
relacionarse directamente con los usuarios. Esta etapa sirve para elaborar la
imagen que el analista tiene de la organizacin y de sus objetivos. En ocasiones,
se llegan a concluir slo las primeras dos etapas del ciclo de desarrollo de los
sistemas.
El analista es e! especialista que emprende esta clase de estudios.
3) Anlisis de las necesidades del sistema.
La siguiente etapa que ejecuta el analista de sistemas consiste en analizar las
necesidades propias del sistema. Una vez ms, existen herramientas y tcnicas
especiales que facilitan al analista la realizacin de las determinaciones
requeridas. Estas incluyen el uso de los diagramas de flujo de datos (DFD)que
cuentan con una tcnica estructurada para representar en forma grfica la entrada
de datos de la empresa, los procesos y la salida de la informacin. A partir del
diagrama de flujo de datos se desarrolla un diccionario de datos que contiene
todos los elementos que utiliza el sistema, as como sus especificaciones,
si
son alfanumricos, descripcin, clave primaria, entre otros.
Durante esta fase. el analista de sistemas tambin analiza las decisiones
estructuradas por realizar, que son decisiones donde las condiciones,
condiciones alternativas, acciones y reglas de accin podrn determinarse.
Existen tres mtodos para el anlisis de las decisiones estructuradas:
el
lenguaje estructurado (en nuestro caso el espaol), las tablas de decisin y los
rboles de decisin.
No todas las decisiones en las empresas
se
encuentran estructuradas; no
obstante,
es importante que las comprenda e! analista de sistemas. Las
decisiones semiestructuradas (decisiones que se toman bajo nesgo) con
frecuencia se apoyan en los Sistemas de Toma de Decisiones. Cuando analiza
las decisiones semiestructuradas. el analista las examina de acuerdo con el
grado de complejidad del problema y con el nmero de criterios considerados al
llevar a cabo las decisiones.
96

El anlisis de decisiones de criterio mltiple (aquellas decisiones donde

numerosos factores tienen que equilibrarse) tambin es parte de esta etapa.
Se disponen de muchas tcnicas para e' anlisis de decisiones de criterio mltiple;
incluyendo entre otras, e! proceso de intercambio y la aplicacin de mtodos de
ponderado.
A esta altura del ciclo de desarrollo del sistema, el analista prepara una propuesta
del sistema que resume todo lo que ha encontrado, presenta un anlisis costo /
beneficio de las alternativas
y
plantea
las recomendaciones (si es que
existen) de lo que deber realizarse. Si la direccin acepta alguna de las
recomendaciones, el analista proceder de acuerdo con ella.
4)
Diseo
del sistema recomendado.
En esta etapa del ciclo de desarrollo de los sistemas, el analista de sistemas usa
la informacin que recolect con anterioridad y elabora el diseo lgico del
sistema de informacin. El analista disea procedimientos precisos de captura
de datos, con el fin de que los datos que se introducen al sistema sean los
correctos. Ei analista tambin disea accesos
efectivos al sistema de
informacin, mediante el uso de las tcnicas de diseo de formularios y de
pantallas.
Una parte del diseo lgico del sistema de informacin es el diseo de la interfaz
con el usuario. La interfaz conecta al usuario con el sistema, y evidentemente, es
de suma importancia. Seran ejemplos de interfaces para el usuario: el uso del
teclado para introducir preguntas o respuestas, el uso de mens en la pantalla,
con las opciones que tiene el usuario, el uso de dispositivos como el ratn (mouse)
y muchos otros.
La etapa del diseo tambin incluye e! diseo de los archivos o la base de datos
que almacenar aquellos datos requeridos por quien toma las decisiones en la
organizacin. Una base de datos bien organizada es fundamental para cualquier
sistema de informacin. En esta etapa, el analista disea la salida (en pantalla o
impresa) hacia el usuario, de acuerdo con sus necesidades de informacin.
5) Desarrollo y documentacin del software

En esta etapa del ciclo de desarrollo de los sistemas, el analista trabaja con los
programadores
para desarrollar todo el software original que sea necesario.
Dentro de las tcnicas estructuradas para el diseo y documentacin de! software
se tienen: el mtodo HIPO, los diagramas de flujo. ios diagramas Nassi97

Schneiderman, ios diagramas Warnier-Orr y el pseudocdigo. Aqu es donde, el

analista de sistemas transmite
al
programador
los requerimientos de
programacin.
Durante esta fase, el analista tambin colabora con los usuarios para desarrollar
la documentacin indispensable
del
software, incluyendo los manuales
de procedimientos. La documentacin le dir al usuario como operar el software, y
as tambin, qu hacer en caso de presentarse algn problema.
6) Pruebas v mantenimiento del sistema.

El sistema de informacin debe probarse antes de utilizarlo. E! costo es menor si
se detectan los problemas antes ci la entrega del sistema.
El programador
realiza algunas pruebas por su cuenta, otras se llevan a cabo en colaboracin con
el analista de sistemas. En un principio, se hace una serie de pruebas, con
datos tipo, para identificar las posibles fallas del sistema: ms adelante, se
utilizarn los datos reales.
El mantenimiento del sistema y de su documentacin empiezan justamente en
esta etapa: y despus, esta funcin se realizar de forma rutinaria a lo largo de
toda la vida del sistema. Las actividades de mantenimiento integran una buena
parte de la rutina
del programador, que para las empresas llegan a implicar importantes sumas
de dinero. Sin embargo, el costo del mantenimiento disminuye de manera
importante cuando
el
analista
aplica procedimientos sistemticos en el
desarrollo de los sistemas.
7) Implantacin y evaluacin de sistema.

En esta ltima etapa del desarrollo del sistema, el analista ayuda a implantar el
sistema de informacin. Esto incluye el adiestramiento que el usuario requerir.
Si bien, parte de esta capacitacin la dan las casas comerciales, la supervisin
del adiestramiento
es
una responsabilidad del analista de sistemas.
Ms an, el analista necesita planear la suave transicin que trae consigo un
cambio de sistemas.
98

Aunque la evaluacin del sistema se plantea como parte integrante de la ltima

etapa del ciclo de desarrollo de los sistemas; realmente, la evaluacin toma parte
en cada una de las etapas.
Uno de los criterios fundamentales que debe
satisfacerse, es que el futuro usuario utilice el sistema desarrollado.
LECCION 24: APLICACIN DE SDLC:
El ciclo de desarrollo de aplicaciones sigue siendo uno de los puntos de ms

complejidad en el entorno TI, una preocupacin constante por parte de los
desarrolladores que requiere de un desgaste muy alto en recursos, dinero y
estrs. La solucin pasa por estandarizar el proceso de desarrollo:
Definir los criterios de calidad en relacin a las necesidades. Como

siempre, hay que intentar ser pragmtico, definir algo medible y del cual
podremos obtener un feedback en tiempo real.
Publicar las mtricas de calidad de desarrollo. La transparencia es clave
para ganar la confianza del negocio y demostrar el valor aportado.
Revisar los objetivos de los diferentes equipos y proveedores para incluir
criterios claros y medibles de calidad.
Pasar ms tiempo en definir correctamente los requerimientos. Todos
tenemos en mente proyectos que han arrancado sobre una definicin de
requerimientos insuficiente.
Definir y estandarizar planes de prueba ms inteligentes para probar menos
y mejor.
Utilizar una plataforma integrada que consolide la informacin de demanda,
costes, recursos, calidad y as simplificar y flexibilizar el proceso.
PRUEBAS Y CALIDAD: La planificacin de prototipos, pruebas y tests para el

aseguramiento de la calidad es tambin un tema muy tratado en la ingeniera del
Software y en el proceso cclico de diseo de aplicaciones seguras.
Para que un proyecto software tenga xito, es necesario que el resultado cuente
con la calidad esperada por el cliente o los usuarios. As pues, la calidad del
proyecto deber poderse definir en trminos de prestaciones, respuestas
esperadas a determinadas acciones, o accesibilidad del producto en diferentes
99

condiciones para poder probarla posteriormente mediante unos tests de calidad

especficos.
Deber ser posible realizar un plan de pruebas o de aseguramiento de la calidad
que clasifique las actividades relacionadas con la calidad del producto segn su
importancia, y que defina con qu frecuencia y qu resultados se deberan obtener
de cada una para pasar a la siguiente o para cumplir los requisitos para esa
release en particular.
El proceso de aseguramiento de la calidad no trata nicamente de que el producto
pase todos los tests establecidos, sino que implicar en muchos casos aspectos
como:
El uso de hojas de estilo aprobadas por los usuarios.

La confeccin y repaso de checklists sobre funcionalidades.
La revisin peridica del producto con los usuarios
Las herramientas que pondremos a disposicin de los usuarios para
comunicar los errores o sugerencias.
El uso de herramientas de anlisis para medir la respuesta del proyecto a
determinadas situaciones, o para simular un uso normal del mismo
Los modelos tradicionales de ciclo de vida del software incluan la fase de pruebas
como un proceso que haba que llevar a cabo una vez finalizado el desarrollo.
Esto se ha probado que resulta altamente contraproducente, no slo por el coste
de arreglar fallos o deficiencias una vez terminado el desarrollo, sino por la
naturaleza evolutiva de muchos proyectos (sobre todo en entornos de software
libre), en los que la fase de desarrollo no termina nunca estrictamente hablando.
As pues, se tiende a incorporar las pruebas (o los mecanismos para llevarlas a
cabo de modo automatizado) en el desarrollo desde el primer momento.
Tecnologas como las pruebas unitarias o modelos como el pair-programming o el
peer-testing nos ayudarn a mantener una disciplina en el desarrollo y a aumentar
la calidad del resultado del proyecto.
32
SEGURIDAD EN LA APLICACIN DE SDLC: Los principios bsicos de la

seguridad de un sistema son los siguientes:
Confidencialidad: los recursos (o funcionalidades sobre ellos) son accesibles slo
para los usuarios (o procesos) autorizados.
32
AYCART, David. Ingeniera del software en entornos de SL. P 24-27. UOC
100

Integridad: los recursos pueden ser modificables slo por los usuarios
autorizados.
Disponibilidad: los recursos accesibles estn disponibles.
Muy frecuentemente, la seguridad de un proyecto ir ms all del mismo,
afectando al sistema en el que ste se va a implantar, y por lo tanto deberemos
asegurar que su implantacin deja al sistema final en un estado seguro.
Es por esta razn por lo que, en la fase de diseo del proyecto, se debe tener en
cuenta la seguridad del mismo, primero de forma general mediante un anlisis de
riesgos y de actividades destinadas a mitigarlos, y ms adelante mediante la
ampliacin de los casos de uso segn los principios bsicos de la seguridad
comentados anteriormente
El anlisis de riesgos consistir, de forma muy resumida, en las siguientes
actividades:
Recopilacin de los recursos que deben ser protegidos. La informacin, todo un
sistema, un slo dispositivo, etc.
Clasificacin de los actores del proyecto. Cules son sus casos de uso y qu roles
representan.
Recopilacin de requisitos legales y de negocio. Certificaciones que hay que
cumplir, restricciones de encriptacin por exportacin a determinados pases o
bien reglas de negocio ms especficas como la aceptacin o no de la repudiacin
por parte de los usuarios.
Con la informacin recopilada, deberamos ser capaces de construir una tabla en
la que, para cada riesgo, estimramos el coste que tiene por incidente, y a partir
de una estimacin de incidentes por ao, nos permitiera decidir sobre la estrategia
que hay que implantar (aceptar el riesgo tal como es y definir un plan de
contingencia en caso de producirse, o bien mitigarlo mediante desarrollos
adicionales, otras herramientas o cambios en el diseo que lo permitan).
LECCION 25: OTRAS VULNERABILIDADES QUE AFECTAN LOS SDLC
La seguridad en aplicaciones web no solo reside en las capas superiores del

modelo OSI, como hemos visto en las lecciones anteriores. Tampoco en el nico
entorno de aplicacin que se despliegue, ejecute o administre en (navegadores,
101

servidores, clientes). Iniciamos ac una temtica de seguridad que afecta

directamente a las aplicaciones web y que independiente de la forma como se le
haya aplicado los ciclos de desarrollo seguro (SDLC), van a estar afectadas y que
es de relevancia tratarlas. Una de ellas son las denegaciones de servicio y que a
continuacin se plasma ms como la solucin a detectarlas y mitigarlas que a
definirlas y conceptualizarlas.
Son muchas las estrategias y herramientas que enmarcan estudios completos con
miras a detectar, prevenir y contrarrestar ataques de Denegacin de Servicio. Los
mtodos ms comunes hacen uso del filtrado de paquetes, como una solucin
viable y eficaz a este problema.
Hay otra estrategia que es la modificacin de la pila TCP/IP en los sistemas
operativos. Mientras que los ataques SYN no puede ser totalmente prevenibles, el
ajuste de la pila TCP / IP ayudar a reducir el impacto de ataques SYN al tiempo
que permite el trfico de clientes legtimos con sus respectivos paquetes.
Actualmente los sistemas operativos integran mecanismos de proteccin como las
galletas o SYN SynAttackProtect como barrera para contrarrestar estas
amenazas.
Las investigaciones que se encuentran frente a esta situacin, son de diversa
ndole y tratan estas estrategias de manera particular. Estudios interesantes han
llevado a tratar las caractersticas del protocolo TCP y modificarlas con el fin de
cambiar el comportamiento de la pila TCP / IP. Pero esto puede tener
consecuencias graves cuando se trata de comunicarse con otros sistemas de
diferente topologa, MTU, filtrado, etc.
Finalmente, cada resultado de una investigacin, encadena otro que propone un
complemento o mejora para resolver el problema, y cada autor le da camino a su
investigacin de acuerdo a la necesidad urgente o escenario propio de cada
situacin.
El escenario de los ataques de denegacin de servicio (DoS) a aplicaciones web,
nos ubica en la capa de transporte del modelo OSI.
25.1 VULNERABILIDADES DE LA CAPA DE TRANSPORTE:33
La capa de transporte transmite informacin TCP o UDP sobre datagramas IP. En
esta capa podamos encontrar problemas de autenticacin, de integridad y de
33
JOANCOMARTI, Jordi Herrera. Aspectos Avanzados de seguridad en redes. Seg edicin. Barcelona Espaa
2005. 62p
102

confidencialidad. Algunos de los ataques ms conocidos en esta capa son las

denegaciones de servicio debidas a protocolos de transporte.
En cuanto a los mecanismos de seguridad incorporados en el diseo del protocolo
de TCP (como las negociaciones involucradas en el establecimiento de una sesin
TCP), existe una serie de ataques que aprovechan ciertas deficiencias en su
diseo. Una de las vulnerabilidades ms graves contra estos mecanismos de
control puede comportar la posibilidad de interceptacin de sesiones TCP
establecidas, con el objetivo de secuestrarlas y dirigirlas a otros equipos con fines
deshonestos.
Estos ataques de secuestro se aprovechan de la poca exigencia en el protocolo de
intercambio de TCP respecto a la autenticacin de los equipos involucrados en
una sesin. As, si un usuario hostil puede observar los intercambios de
informacin utilizados durante el inicio de la sesin y es capaz de interceptar con
xito una conexin en marcha con todos los parmetros de autenticacin
configurados adecuadamente, podr secuestrar la sesin.
25.2 ORIGEN DE LAS VULNERABILIDADES: Las vulnerabilidades pretenden
describir las debilidades y los mtodos ms comunes que se utilizan para
perpetrar ataques a la seguridad de la familia de protocolos TCP/IP
(confidencialidad, integridad y disponibilidad de la informacin).
Amenazas
Consecuencias
INTEGRIDAD
Datos modificados
Informacin perdida
Caballo de Troya
Maquina penetrada
Memoria cambiada
Vulnerabilidad a otras amenazas
Mensajes modificados
Informacin degradada, daada

CONFIDENCIALIDAD
Mensajes escuchados en la red
Perdida de privacidad
Datos robados de servidores
Revela contraseas etc.
Anlisis de trafico
Identifica patrones de acceso
Detecta configuracin de la red
Facilita otros ataques

DENIAL OF SERVICE
103

Procesos matados
Molestias
Inundacin con paquetes
Interferencia con trabajo
Llenado de discos
Denegacin a servicios
Aislamiento de maquinas (DNS)
Aislamiento de la red
AUTENTIFICACION
Identidades falsas
Acciones atribuidas al usuario
Datos falsos
Dao al nombre institucional
Tabla3. Tipos de Amenazas

Fuente: <El Autor>
La tabla (3) muestra en resumen el tipo de amenazas y las consecuencias que le

producen al sistema. Las amenazas estn clasificadas en los cuatro aspectos
bsicos y esenciales que afectan la seguridad: La integridad, la Confidencialidad,
las denegaciones de servicio (de las que se encarga este trabajo) y las de
Autenticacin
25.3 HERRAMIENTAS DE MONITOREO:
Son muchas las estrategias y herramientas de monitoreo que existen para ser
aplicadas a entornos de comunicaciones y redes tipo Ethernet. La mayora de
ellas funcionan sobre plataformas de cdigo abierto lo que les ofrece grandes
posibilidades de expansin y de parametrizacion de acuerdo a las necesidades del
Administrador de red.
Nagios: 34La monitorizacin cualitativa de los servicios se realiza mediante el

sistema Nagios siendo este un sistema potente que permite seguir el estado de
mltiples servicios de red en mltiples servidores y avisar a personas o grupos de
personas responsables de los mismos. En Nagios se permiten escaladas de
avisos en funcin del tiempo de parada y otros parmetros, mltiples mtodos de
aviso (correo electrnico, SMS...) y presentacin grfica muy prctica del estado
actual y del histrico de estados.
Nessus: La herramienta Nessus permite escanear vulnerabilidades cuando se
trata de transferencia de datos y ejecucin de servicios en diferentes sistemas
operativos. Genera informes que permiten ejecutar las acciones correctivas
34
Herramientas de Gestin Nagios, Nessus [web en lnea]. Disponible desde Internet en:
<http://www.csi.map.es/csi/tecnimap/tecnimap_2006/01T_PDF/monitorizacion.pdf>
104

adecuadas (parcheo, reconfiguracin de servicios, adicin de reglas de

cortafuegos). Su arquitectura cliente servidor consiste en nessusd, el daemon
Nessus, que realiza el escaneo en el sistema objetivo, y nessus, el cliente (basado
en consola o grfico) que muestra el avance y reporte de los escaneos. Desde
consola nessus puede ser programado para hacer escaneos programados con
cron (administrador de procesos en segundo plano).
25.4 SISTEMA DE DETECCION DE INTRUSOS:

Un IDS o Sistema de Deteccin de Intrusiones es una herramienta de seguridad
que intenta detectar o monitorizar los eventos ocurridos en un determinado
sistema informtico o red informtica en busca de intentos de comprometer la
seguridad de dicho sistema. Aportan a la seguridad de una red la capacidad de
prevencin y de alerta anticipada ante cualquier actividad sospechosa. No estn
diseados para detener un ataque, aunque s pueden generar ciertos tipos de
respuesta ante stos. Vigilan el trfico de nuestra red, examinan los paquetes
analizndolos en busca de datos sospechosos y detectan las primeras fases de
cualquier ataque como pueden ser el anlisis de la red, barrido de puertos, etc.35
25.5 TIPOS DE IDS:

HIDS (Host IDS): Protege contra un nico Servidor, PC o host. Monitorizan gran
cantidad de eventos, analizando actividades con una gran precisin, determinando
de esta manera qu procesos y usuarios se involucran en una determinada
accin. Recaban informacin del sistema como ficheros, logs, recursos, etc, para
su posterior anlisis en busca de posibles incidencias. Todo ello en modo local,
dentro del propio sistema. Fueron los primeros IDS en desarrollar por la industria
de la seguridad informtica.
NIDS (Net IDS): Protege un sistema basado en red. Actan sobre una red
capturando y analizando paquetes de red, es decir, son sniffers del trfico de red.
Luego analizan los paquetes capturados, buscando patrones que supongan algn
tipo de ataque.
Bien ubicados, pueden analizar grandes redes y su impacto en el trfico suele ser
pequeo. Actan mediante la utilizacin de un dispositivo de red configurado en
modo promiscuo (analizan, ven todos los paquetes que circulan por un segmento
35
Sistema de deteccin de Intrusos y Snort. Disponible desde Internet en:

<http://seguridadyredes.nireblog.com/post/2007/12/28/sistemas-de-deteccion-de-intrusos-y-snort-i>
105

de red aunque estos nos vayan dirigidos a un determinado equipo). Analizan el

trfico de red, normalmente, en tiempo real. No slo trabajan a nivel TCP/IP,
tambin lo pueden hacer a nivel de aplicacin.
Otros tipos son los hbridos. Por el tipo de respuesta se pueden clasificar en:
Pasivos: Son aquellos IDS que notifican a la autoridad competente o
administrador de la red mediante el sistema que sea, alerta, etc. Pero no acta
sobre el ataque o atacante.
Activos: Generan algn tipo de respuesta sobre el sistema atacante o fuente de
ataque como cerrar la conexin o enviar algn tipo de respuesta predefinida en
nuestra configuracin.
Snort: Snort es un IDS o Sistema de deteccin de intrusiones basado en red
(NIDS). Implementa un motor de deteccin de ataques y barrido de puertos que
permite registrar, alertar y responder ante cualquier anomala previamente definida
como patrones que corresponden a ataques, barridos, intentos aprovechar alguna
vulnerabilidad, anlisis de protocolos, etc conocidos. Todo esto en tiempo real.
Snort est disponible bajo licencia GPL, gratuito y funciona bajo plataformas
Windows y UNIX/Linux. Es uno de los ms usados y dispone de una gran cantidad
de filtros o patrones ya predefinidos, as como actualizaciones constantes ante
casos de ataques, barridos o vulnerabilidades que vayan siendo detectadas a
travs de los distintos boletines de seguridad. 36
Este IDS implementa un lenguaje de creacin de reglas flexibles, potente y
sencilla. Durante su instalacin ya provee de cientos de filtros o reglas para
backdoor, ddos, finger, ftp, ataques web, CGI, escaneos Nmap. Puede funcionar
como sniffer (se puede ver en consola y en tiempo real qu ocurre en la red, todo
el trfico), registro de paquetes (permite guardar en un archivo los logs para su
posterior anlisis, un anlisis offline) o como un IDS normal (en este caso NIDS).
La caracterstica ms apreciada de Snort, adems de su funcionalidad, es su
subsistema flexible de firmas de ataques. Snort tiene una base de datos de
ataques que se est actualizando constantemente y a la cual se puede aadir o
actualizar a travs de la Internet. Los usuarios pueden crear 'firmas' basadas en
las caractersticas de los nuevos ataques de red y enviarlas a la lista de correo de
firmas de Snort, para que as todos los usuarios de Snort se puedan beneficiar y
crear una comunidad con las caractersticas de los proyectos de entorno de
desarrollo libre.
36
Disponible en Internet. < http://www.snort.org/> Con acceso Junio 28 de 2012
106

25.6 HERRAMIENTAS DE GESTION:

JFFNMS: 37 Es un software desarrollado por Javier Szyszlican, en el ao 2002,
para monitoreo de dispositivos, que integra varias utilidades que interrogan y
capturan los datos de los dispositivos. Los programas utilizados por JFFNMS para
el monitoreo, son los siguientes:
POLLER: Acta como manager del protocolo SNMP interrogando a los agentes
instalados en los dispositivos a monitorear.
SNMPTRAPD: Recibe los traps desde los dispositivos monitoreados. Los traps
son eventos o alarmas que los dispositivos envan sin necesidad de ser
consultados.
SYSLOG: Servicio que recoge la informacin de auditora (mensajes logs) de los
dispositivos. No forma parte del protocolo SNMP. Se basa en los registros de
auditora de los sistemas UNIX.
Tambin utiliza programas como nmap, fping y otros para probar conectividad,
puertos abiertos y otros parmetros de red. En tal sentido, JFFNMS es un sistema
integrador para el monitoreo. Adems de estos programas fundamentales que
realizan la consulta y captura de los datos, JFFNMS requiere de una base de
datos robusta para almacenarlos (PostgreSQL MySQL), un Servidor Web para
presentarlos (Apache), el intrprete PHP bajo el cual se ejecutar JFFNMS,
utilidades y programas para generar grficos (RRDtool, Graphviz, etc.) .JFFNMS
se distribuye bajo la licencia GPL. 38
Nmap: (Network Mapper). Esta herramienta implementa la gran mayora de
tcnicas conocidas para exploracin de puertos y permite descubrir informacin de
los servicios y sistemas encontrados. Nmap tambin implementa un gran nmero
de tcnicas de reconocimiento de huellas identificativas.
Generalmente, Nmap es utilizado internamente por otras aplicaciones como, por
ejemplo, escner de vulnerabilidades, herramientas de deteccin de sistemas
activos, servicios web que ofrecen exploracin de puertos, etc.
Fping: 39La utilidad ping comprueba el estado de la conexin con uno o varios
equipos remotos por medio de los paquetes de solicitud de eco y de respuesta de
eco (ambos definidos en el protocolo de red ICMP) para determinar si un sistema
37
Disponible en Internet. <http://wiki.canaima.softwarelibre.gob.ve/wiki/index.php/Servidor_Jffnms>

Disponible en Internet <http://www.es.gnu.org/modules/content/index.php?id=8>
39
Disponible en Internet. <http://fping.sourceforge.net/>
38
107

IP especfico es accesible en una red. Es til para diagnosticar los errores en

redes o enrutadores IP.
Fping es una utilidad que realiza un ping original pero con mltiples funciones
extras, proporcionndote as mucha ms informacin y detalles.
RRDtool: RRDtool es el estndar de la industria OpenSource para el registro de
datos de alto rendimiento con un sistema de representacin grfica de datos de
series en una lnea de tiempo. Es til para escribir shell scripts de seguimiento
personalizado o crear aplicaciones usando lenguajes como Perl, Python, Ruby,
TCL o enlaces de PHP. 40RRDtool es el acrnimo de Round Robin Database tool.
Trabaja con una base de datos que maneja planificacin segn Round-Robin. Esta
tcnica trabaja con una cantidad de datos fija, definida en el momento de crear la
base de datos, y un puntero al elemento actual. La base de datos como si fuese
un crculo, sobrescribiendo los datos almacenados con anterioridad una vez
alcanzada la capacidad mxima de la misma. Esta capacidad mxima depender
de la cantidad de informacin que se quiera conservar como historial.
Su finalidad principal es el tratamiento de datos temporales y datos seriales como
temperaturas, transferencias en redes, cargas del procesador, etc. Algunos
proyectos que utilizan RRDtool son: Cacti, Ganglia, JFFNMS, Lighttpd, MRTG,
Munin, Smokeping, Zenoss.
40
Disponible en internet. <http://oss.oetiker.ch/rrdtool/>
108

CAPITULO 6: ATAQUES DE DENEGACION DE SERVICIO (DDoS) A

APLICACIONES WEB
LECCION 26: DENEGACION DE SERVICIO (DoS) / (DDoS)
Es importante diferenciar dos tipos de ataques de denegacin del servicio si se

tiene en cuenta que uno en los que se va a centrar este proyecto, puede actuar
teniendo un nico origen o varios dependiendo la tcnica usada para ejecutarlo:
Ataques de denegacin de servicio simples (Deny Of Service). Este tipo

de ataques se caracterizan por tener un nico origen desde el cual se
realiza la denegacin del servicio.
Ataques de denegacin de servicio distribuido (Distributed DOS o
DDOS). En este tipo de ataques se utilizan varias fuentes coordinadas que
pueden realizar un ataque progresivo, rotatorio o total.
Se define la denegacin de servicio (Deny Of Service, DOS) como la imposibilidad

de acceso a un recurso o servicio por parte de un usuario legtimo. De esta forma
se puede definir un ataque de denegacin de servicio (DOS Attack) como: 41La
apropiacin exclusiva de un recurso o servicio con la intencin de evitar cualquier
acceso de terceros. Tambin se incluyen en esta definicin los ataques destinados
a colapsar un recurso o sistema con la intencin de destruir el servicio o recurso.
Siendo ms concreto y enfocando los ataques a redes IP como el que se pretende
llevar a cabo en el desarrollo del proyecto, se encuentra una definicin con
argumentos explicativos concretos que definen los ataques de denegacin del
servicio como 42la consecucin total o parcial (temporal o totalmente) del cese en
la prestacin de servicio de un ordenador conectado a Internet.
41
Search Software Quality. [Web en lnea]. Disponible desde Internet en:

<http://searchsoftwarequality.techtarget.com/sDefinition/0,,sid92_gci213591,00.html>
42
CERT Advisory CA-1999-17 Denial-of-Service Tools. [Web en lnea]. Disponible desde Internet en:
<http://www.cert.org/advisories/CA-1999-17.html>
109

Figura 25. Escenario de un Ataque de Denegacin de servicio (DoS)

Fuente: <El Autor> Adaptado < MIRKOVIC.J. D-WARD Source-End Defense Against Distributed
Denial-of-Service Attacks.2003. p 38.>
En la Figura 25, se explica una denegacin del servicio tpica. Que se produce
cuando la vctima (V) recibe un malicioso flujo de paquetes obligndola a evitar
recibir algn recurso o servicio de los clientes legtimos C1, y C2. Una
caracterstica de estos ataques es que los atacantes rara vez utilizan sus propias
mquinas para llevar a cabo los ataques por lo que la mquina A se convierte en
un agente o participante involuntario
26.1 DENEGACIN DE SERVICIO DISTRIBUIDO: DDOS
Se han definido los ataques de denegacin de servicio distribuido (DDOS) como

43
un ataque de denegacin de servicio (DOS) dnde existen mltiples focos
distribuidos y sincronizados que focalizan su ataque en un mismo destino
43
[Web en lnea].Disponible desde Internet en:

<http://searchsecurity.techtarget.com/sDefinition/0,,sid14_gci557336,00.html>
110

Figura 26. Escenario de un Ataque de Denegacin de servicio Distribudo (DDoS)

Fuente: <El Autor> Adaptado < MIRKOVIC.J. D-WARD Source-End Defense Against Distributed
Denial-of-Service Attacks.2003. p 40.>
La Figura 26, muestra una negociacin distribuida simple en el que varias

mquinas (A,B) atacantes detienen un servicio al enviar paquetes de datos con
flujos maliciosos a la vctima (V) negando el servicio a los clientes legtimos C1 y
C2.
26.2 FUENTES DE ORIGEN DE LOS ATAQUES DOS / DDOS

Los ataques de denegacin de servicio suelen tener varios orgenes, lo que
complica la posibilidad de mantener un control efectivo sobre todos los recursos o
servicios ofrecidos. Una deteccin tempanara con un sistema de alertas como el
que se ha propuesto en este proyecto podran minimizar el riesgo. No obstante,
los distintos orgenes o fuentes pueden provenir principalmente de dos fuentes:
44
Usuarios legtimos o internos: Este grupo se subdivide en aquellos usuarios

poco cuidadosos que colapsan el sistema o servicio inconscientemente (por
ejemplo la persona que llena el disco duro del sistema bajando archivos de
msica), usuarios malintencionados (aquellos que aprovechan su acceso para
causar problemas de forma premeditada) y usuarios ladrones que utilizan el
acceso de un usuario legtimo (ya sea robndolo del usuario legtimo o
aprovechndose de la confianza de este).
44
VERDEJO. G. Seguridad en Redes IP. Universitat Autnoma de Barcelona. Barcelona Sep. 2003. p,36
111

Agentes externos: Este grupo hace referencia a los no usuarios del sistema. De
esta forma se consigue acceso al recurso o servicio sin necesidad de ser un
usuario legtimo (un sistema que no controle la autenticacin de usuarios, un
sistema que presente un bug conocido...). En este grupo usualmente se falsea la
direccin de origen (faked/spoofed IP) con el propsito de evitar el origen real del
ataque.
Antes de diferenciar algunos ataques y principalmente el que se va a tratar en esta
tesis, es conveniente identificar como actan o las fases previas a un ataque.
26.3 PLATAFORMAS AFECTADAS:
El enfoque que abarca estos contenidos acadmicos para el curso, comprende
escenarios en los que se presenten ataques de servicio en redes IP. La
trascendencia de estos ataques est dada por su independencia de plataformas
en las que pueden perpetrarse y hacer efectivos estos ataques.
26.4 CARACTERZACION DE LOS ATAQUES DOS:
Dependiendo de la tcnica usada o las caractersticas del ataque, se debe
proyectar su defensa o estrategia de proteccin. Es por ello importante
identificarlas para proyectar su anlisis en busca de proponer una mejor solucin
como se indica a continuacin:
26.4.1 Uso de IP Source Spoofing: En la que los atacantes utilizan la
suplantacin o falseo de una direccin IP durante el ataque emitiendo informacin
falsa desde el mismo origen del ataque ocultando informacin de la cabecera de
los paquetes IP. Una de las caractersticas de este ataque es que las mquinas
Agente o las que envan el ataque, son difciles de rastrear, incluso con la
informacin que capturan y la direccin oculta de donde se realiza el ataque, se
pueden realizar ataques futuros.
La otra caracterstica que tiene esta falsificacin de direcciones IP, es la que le
permite a los atacantes hacer una reflexin del ataque que consiste que las
solicitudes a un determinado servicio que realiza el atacante en nombre de la
vctima, genera muchas respuestas de un tamao pequeo. A medida que realice
ms solicitudes, estas obtendrn ms respuestas que son recibidas por la vctima.
Puede extender su ataque enviando solicitudes a servidores pblicos que otorgan
mayor nmero de respuestas.
112

Un gran nmero de mquinas agente: Ac se complica el ataque, por que

incluso si un sistema de deteccin de intrusos (IDS) detecta las peticiones y el
origen de las mismas, por el gran volumen de atacantes y la diversidad de
paquetes enviados, pueden evitar que las repuestas lleguen al sistema de
deteccin y tomar mucho tiempo en procesarse dando oportunidad a usar la
reflexin explicada anteriormente para retomar el ataque.
26.4.2 Similitud de trfico legtimo: Cualquier tipo de trfico puede ser utilizado
para ejecutar un ataque de denegacin de servicio. Algunos tipos de trfico
requieren un mayor volumen de paquetes para que tengan mayor xito que otros.
El trfico legtimo fcilmente puede ser confundido con el trfico malicioso.
Un sistema de defensa estara basado en la obtencin de un volumen de datos
estadsticos para su anlisis de la semntica o estructura de las transacciones
habituales y compararlas con las que se tengan duda. Es un principio bsico de
muchos sistemas de deteccin de intrusos (IDS).
La seguridad en Internet es altamente Independiente: En donde las vctimas
son tambin altamente dependientes de la seguridad de otros subsistemas a los
que estn aadidos o de los que tomen los servicios. Este aspecto se tiene en
cuenta sobre todo en redes de gran cobertura y tamao.
Control de internet Distribuido: La gestin de internet es distribuida y cada red
ejecuta sus polticas de seguridad y manejo de informacin de acuerdo a las
establecidas por sus dueos. No hay manera de hacer cumplir un mecanismo
particular de seguridad y se torna complejo el estudio del trfico de red que
atraviesan diferentes redes para optar por la mejor estrategia.
Los recursos de Internet son limitados: Cada entidad de internet, ya sea un
host, red, equipo activo; dispone de recursos limitados que generalmente son
consumidos en su totalidad por los usuarios e incluso sobrepasados. De all que
todo intento de ataque de denegacin de servicio (DoS) tendr xito siempre y
cuando no hay un mecanismo de proteccin previo.
Existen ms aspectos de diseo en la red, que afectan la probabilidad o no de que
suceda un ataque y ms an inciden en el tipo de ataque que se puede realizar.
Estos aspectos son analizados en el desarrollo del proyecto y se convierten en
variables a tener en cuenta para el diseo de un mecanismo de proteccin.
113

LECCION 27: FASES PREVIAS A LA REALIZACION DEL ATAQUE:
Para poder realizar el ataque a la red local, o a una aplicacin web o a una URL
especfica, se identificaron unas etapas previas o fases que se realizan para poder
perpetrar un ataque (DoS) de nivel de seguridad a una red TCP/IP que permitan
identificar estrategias con miras a determinar un sistema de alarmas que
minimicen el riesgo y que lo identifiquen de forma especfica y concreta.
27.1 ACTIVIDADES PREVIAS AL ATAQUE (DOS):
El objetivo se apoya con gran relevancia en la correcta interpretacin y anlisis del

comportamiento de los datos en las conversaciones establecidas usando el
protocolo TCP/IP y los servicios implementados por el protocolo IP y su unidad de
datos bsica que es el datagrama, cuyo tamao mximo es de 65535 bytes (64K).
La Figura 27 muestra la estructura de un datagrama IP V 4.0 en el que se resalta
el campo TTL (Time to Live) que determina el tiempo de vida del datagrama antes
de ser rechazado por alguna causa en el mecanismo de comunicacin que adopta
el protocolo. Limita el tiempo que un datagrama puede pasar en la red. TTL se
decrementa en una unidad cada vez que pasa por un encaminador si todo va bien,
o en una unidad por segundo en el encaminador si hay congestin. Al llegar a cero
el datagrama es descartado.
Este campo que se inicializa en el ordenador de origen a un valor (mximo
2^8=256) y se va decrementando en una unidad cada vez que atraviesa un router.
De esta forma, si se produce un bucle y/o no alcanza su destino en un mximo de
255 saltos, es descartado. En este caso se enva un datagrama ICMP de error al
ordenador de origen para avisar de su prdida.
La ubicacin en la figura del campo TTL antecede a la identificacin del tipo de
protocolo que interviene en la comunicacin.
114

Figura 27. Estructura de un datagrama IP V 4.0

Fuente: <El Autor>
27.2 TOPOLOGA O DISTRIBUCIN FSICA:

Los ataques (DoS), tambin basan sus tcnicas inicialmente capturando
informacin relacionada con la topologa de red o distribucin fsica identificando el
tipo de sistema entre el atacante y las victimas.
La comunicacin est implementada sobre el protocolo IP (Internet Protocol)
siendo la pieza fundamental en la que se sustenta el sistema TCP/IP y por tanto
todo el funcionamiento de Internet. Su especificacin est recogida en [RFC791].
45
El protocolo IP est dado para facilitar un sistema sin conexin (connectionless)

y no fiable (unreliable) de entrega de datagramas entre dos ordenadores
cualesquiera conectados a Internet. Adems, no mantiene ningn tipo de
informacin referente al estado de las conexiones. Cada datagrama es
encaminado de forma independiente, lo que le convierte en un protocolo sin
conexin.
Debido a estas particulares caractersticas, puede pasar que se pierdan
datagramas y/o que estos no lleguen en orden. De esta manera, cualquier
fiabilidad que se necesite, deber ser realizada por las capas superiores (TCP).
Se parte tambin de un anlisis bsico de la estructura de un datagrama IP, que

est dividida en bloques de 32 bits (4 bytes). El datagrama IP se transmite
45
Ibid, p. 13
115

enviando primero el bit 0, luego el bit 1, 2, 3... Y as sucesivamente hasta finalizar

el datagrama. Este orden se denomina network byte order. Para el estudio que se
lleva a cabo en la deteccin de ataques DoS, es muy importante conocer este
orden de transmisin de la informacin, puesto que los diferentes ordenadores
tienen diferentes sistemas de almacenamiento de bits en memoria.
Para poder capturar esta informacin referente a la topologa de red o distribucin
fsica identificando el tipo de sistema entre el atacante y las victimas, los ataques
DoS manipulan el campo TTL de la cabecera IP de un paquete para determinar la
forma que los saltos uno a uno se dan y por los que un determinado paquete
avanza por la red TCP/IP. El campo TTL acta como un contador de saltos,
vindose reducido en una unidad al ser reenviado por cada dispositivo de
encaminamiento.
Especficamente este campo TTL tiempo de vida (Time To Live), es un campo
de 8 bits que indica el tiempo mximo que el datagrama ser vlido y podr ser
transmitido por la red. Esto permite un mecanismo de control para evitar
datagramas que circulen eternamente por la red (por ejemplo en el caso de
bucles).
27.3 FUNCIN DE ICMP EN LOS ATAQUES DOS.
Un anlisis inicial muestra la importancia de este protocolo y su papel cuando se
trata de extraer informacin de una conversacin TCP con miras a ser atacada o a
denegar algn servicio.
El protocolo ICMP (Internet Control Message Protocol) es un protocolo simple que
va encapsulado en datagramas IP y que tiene por funcin el control del flujo de la
comunicacin as como la comunicacin de errores [RFC792]. En la Figura 28 se
muestra la estructura de un mensaje ICMP. Los mensajes de error de este
protocolo los genera y procesa TCP/IP y no el usuario. Dentro del datagrama IP se
muestra la ubicacin de la cabecera ICMP de 8 bytes.
Figura 28. Estructura de un mensaje ICMP

Fuente: <El Autor>
116

ICMP tambin permite obtener informacin como la franja horaria del sistema
destino o la mscara de red. La simple ejecucin del comando ping contra la
direccin IP asociada a un nombre de dominio ofrece al atacante informacin de
gran utilidad. Para empezar, esta informacin le permitir determinar la existencia
de uno o ms equipos conectados a la red de este dominio.
Una explicacin sencilla de como se identifican equipos conectados la da un
servicio de entrega basado en el mejor intento (best effort) que adopta IP. Significa
que cuando se detecta un error en la transmisin o funcionamiento irregular ya sea
por tiempo de entrega de paquetes, tamaos, tipos de servicios, direcciones
origen o destino, se contempla un sistema muy simple de tratamiento de errores.
Este mecanismo de control de errores viene regulado por el protocolo ICMP
(Internet Control Message Protocol).
Generalmente la vctima (equipo, host o cliente), descarta los datagramas y
enviara un mensaje de error ICMP al ordenador de origen sin encargarse de la
retransmisin del datagrama, lo que no implica fiabilidad. La cabecera del
protocolo ICMP tiene un tamao de 8 bytes que contiene varios campos que
permiten la identificacin del mensaje. En la Figura 29 se muestran estos campos
que dan informacin del Tipo de Mensaje, un cdigo de identificacin y la
ubicacin del campo de 16 bits chkeksum expuesta en el texto del [RFC793] que
documenta acerca del clculo del campo del checksum para TCP.
Figura 29. Cabecera de un datagrama ICMP

Fuente: <El Autor>
El Tipo (Type) indica el carcter del mensaje enviado, ya que el protocolo permite
especificar una gran variedad de errores o mensajes de control de flujo de las
comunicaciones
La tabla 4 muestra el tipo de mensajes que el protocolo ICMP emite y los cdigos
de error utilizados para su identificacin. Estos cdigos estn ordenados en la
117

columna izquierda en orden jerrquico clasificados en Mensajes informativos y

Cdigos de error.
Mensajes informativos
0
3
4
5
8
11
12
13
14
15
16
17
Echo Reply (respuesta de eco)

Destination Unreacheable (destino inaccesible)
Source Quench (disminucin del trfico desde el origen)
Redirect (redireccionar - cambio de ruta)
Echo (solicitud de eco)
Time Exceeded (tiempo excedido para un datagrama)
Parameter Problem (problema de parmetros
Timestamp (solicitud de marca de tiempo)
Timestamp Reply (respuesta de marca de tiempo)
Information Request (solicitud de informacin) - obsoletoInformation Reply (respuesta de informacin) - obsoletoAddressmask (solicitud de mscara de direccin)
18
Addressmask Reply (respuesta de mscara de direccin
Cdigos de error
0
1
2
3
4
5
6
no se puede llegar a la red

no se puede llegar al host o aplicacin de destino
el destino no dispone del protocolo solicitado
no se puede llegar al puerto destino o la aplicacin destino no est libre
se necesita aplicar fragmentacin, pero el flag correspondiente indica lo contrario
la ruta de origen no es correcta
no se conoce la red destino
no se conoce el host destino
8
9
10
11
12
el host origen est aislado

la comunicacin con la red destino est prohibida por razones administrativas
la comunicacin con el host destino est prohibida por razones administrativas
no se puede llegar a la red destino debido al Tipo de servicio
no se puede llegar al host destino debido al Tipo de servicio
Tabla4. Mensajes y cdigos del protocolo ICMP

Fuente: <El Autor>
Poder identificar los errores en el campo de Cdigo (Code) que indica el cdigo de
error dentro del tipo de error indicado en el campo tipo agrupando los mensajes
en tipos y dentro de cada tipo especificando el cdigo concreto al que se refiere,
ayudan a determinar alertas sobre los fallos en la red o posibles ataques.
118

El Checksum simplemente permite verificar la integridad del mensaje enviado, lo

que permite detectar posibles errores en el envo, transporte o recepcin del
mensaje de control ICMP.
El campo de Operacin (Operation) depende directamente del contenido de los
campos de tipo y cdigo, permitiendo la inclusin de una informacin extra referida
al cdigo de error.
27.4 DESCUBRIMIENTO DE USUARIOS:
Obtencin de usuarios vlidos. Otra informacin relevante en un sistema es el
nombre de los usuarios que tienen acceso a los equipos. Mediante el uso de un
servicio sobre el protocolo TCP en el puerto 79, denominado finger [RFC1288],
se porta como un protocolo que proporciona informacin de los usuarios de una
mquina en el momento de acceder a algn tipo de servicio.
27.5 INFORMACIN DEL DOMINIO:

Se debe contemplar escenarios reales en los que intervengan redes
heterogneas. Un escenario tpico es cuando una organizacin tiene
implementado Dominios, que ofrecen informacin acerca de las subredes que
estn detrs de el y que despliegan informacin cando se hacen las consultas de
nombre de dominio (DNS).
El sistema DNS funciona principalmente en base al protocolo UDP. Los
requerimientos se realizan a travs del puerto 53. Se referencia el anlisis del
protocolo UDP como un protocolo simple y orientado a datagrama. Su definicin
se recoge en [RFC7680].
El sistema est estructurado en forma de rbol. Cada nodo del rbol est
compuesto por un grupo de servidores que se encargan de resolver un conjunto
de dominios (zona de autoridad). Un servidor puede delegar en otro (u otros) la
autoridad sobre alguna de sus sub-zonas (esto es, algn subdominio de la zona
sobre la que l tiene autoridad)
Son aspectos computacionales que se deben tener en cuenta en el diseo del
modelo ya que sea que se comporten como agentes externos o no, influyen en el
diseo. Si los servidores que ofrecen la informacin de los Dominos no estn
configurados debidamente, seguramente que tanto los tiempos, estrategias o
tcnicas que usan los ataque de denegacin del servicio, varan
119

LECCION 28: FINGERPRINTING
La seguridad en aplicaciones web, debe llevar a los profesionales que traten esta
temtica, poder identificar ataques DoS en redes Ethernet. Se trata entonces de
obtener informacin de un sistema concreto y de alguna vulnerabilidad especfica.
Esto se hace obteniendo su huella identificativa respecto de la pila TCP/IP de los
equipos atacados. Esta tcnica es la que se conoce como Fingerprinting y la
informacin que puede brindar esta tcnica dentro de las muchas opciones que
tiene de descubrir datos de la vctima es la de permitir descubrir de forma muy
fiable el sistema operativo que se ejecuta en la maquina analizada.
Un anlisis previo de esta Pila TCP/IP permite ver como es de vulnerable esta
implementacin:
28.1TRANSMISIN EN EL PROTOCOLO DE CONTROL.

Cuando TCP se encuentra entre IP y la capa de aplicacin, el Protocolo de
Control de Transmisin (TCP) garantiza una comunicacin fiable orientada a
conexin para las estaciones y para los servicios que estas implementan. TCP
garantiza que los datagramas se entregan en orden, sin que haya errores, y sin
duplicacin. Los servicios se proporcionan utilizando mecanismos de control de
flujo tales como el de Ventana deslizante (Three-way Handshake) y la
adaptacin de Tcnicas de retransmisin
Figura 30. Topologa de una red genrica

Fuente: <Schuba. C, Krsul. I y Kuhn. M. Analysys of a Denial Service Attack on TCP, p 16.>
Three-way Handshake: Para entender el proceso de establecimiento de conexin

en tres vas se ha tomado una topologa de una red genrica como la que se
muestra en la figura (30). Similar al escenario que el proyecto pretende comprobar
en la deteccin de ataques de denegacin de servicio.
120

Antes de poder transmitir datos entre un host de origen S y un host de destino D,

TCP tiene que establecer una conexin entre S y D como se ve en la figura (6). El
establecimiento de esta conexin recibe el nombre de conexin en tres vas
como se representa en la figura (31).
Figura 31. Mecanismo de tres vias

Fuente: <Schuba. C, Krsul. I y Kuhn. M. Analysys of a Denial Service Attack on TCP, p 16.>
El mecanismo es el siguiente:
46
0. El host receptor, que en el caso de ms comn ser un servidor, espera

pasivamente una conexin ejecutando las primitivas LISTEN y ACCEPT.
1. En primer lugar, el host que desea iniciar la conexin ejecuta una primitiva
CONNECT especificando la direccin IP y el puerto con el que se desea conectar,
el tamao mximo del segmento que est dispuesto a aceptar y opcionalmente
otros datos, como alguna contrasea de usuario. Entonces la primitiva CONNCET
hace una apertura activa, enviando al otro host un paquete que tiene el bit SYN
(ver formato de un segmento TCP ms abajo) activado, indicndole tambin el
nmero de secuencia inicial "x" que usar para enviar sus mensajes.
46
Protocolo de acuerdo a tres vas. Disponible desde Internet en:
<http://neo.lcc.uma.es/evirtual/cdd/tutorial/transporte/twhandshake.html>
121

2. El segundo paso contina con el host receptor que recibe el segmento revisa si
hay algn proceso activo que haya ejecutado un LISTEN en el puerto solicitado,
es decir, preparado para recibir datos por ese puerto. Si lo hay, el proceso a la
escucha recibe el segmento TCP entrante, registra el nmero de secuencia "x" y,
si desea abrir la conexin, responde con un acuse de recibo "x + 1" con el bit SYN
activado e incluye su propio nmero de secuencia inicial "y", dejando entonces
abierta la conexin por su extremo. El nmero de acuse de recibo "x + 1" significa
que el host ha recibido todos los octetos hasta e incluyendo "x", y espera "x + 1" a
continuacin. Si no desa establecer la conexin, enva un contestacin con el bit
RST activado, para que el host en el otro extremo lo sepa.
3. El primer host recibe el segmento y enva su confirmacin, momento a partir del

cual puede enviar datos al otro extremo, abriendo entonces la conexin por su
extremo.
4. La mquina receptora recibe la confirmacin y entiende que el otro extremo ha

abierto ya su conexin, por lo que a partir de ese momento tambin puede ella
enviar datos. Con esto, la conexin ha quedado abierta en ambos sentidos.
28.2 EXPLORACIN DE PUERTOS:

El escaneo o exploracin de puertos permite determinar las caractersticas de una
red o sistema remoto, 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, cmo
estn organizados los equipos, que sistemas operativos ejecutan y cual es le
propsito de cada uno.
Hay diferentes formas de explotar las vulnerabilidades de TCP/IP en los que los
ataques de Denegacin de Servicio hacen uso de diferentes tcnicas para realizar
esta exploracin de puertos TCP. Entre las ms conocidas, se destacan las
siguientes:
TCP connect scan. Mediante el establecimiento de una conexin TCP

completa (completando los tres pasos del establecimiento de la conexin) la
exploracin puede ir analizando todos los puertos posibles. Si la conexin
se realiza correctamente, se anotara el puerto como abierto (realizando una
suposicin de su servicio asociado segn el nmero de puerto).
122

TCP SYN scan. Enviando nicamente paquetes de inicio de conexin

(SYN) por cada uno de los puertos que se quieren analizar se puede
determinar si estos estn abiertos o no. Recibir como respuesta un
paquete RST-ACK significa que no existe ningn servicio que escuche por
este puerto. Por el contrario, si se recibe un paquete SYN-ACK, podemos
afirmar la existencia de un servicio asociado a dicho puerto TCP. En este
caso, se enviara un paquete RST-ACK para no establecer conexin y no
ser registrados por el sistema objetivo, a diferencia del caso anterior (TCP
connect scan).
Existen otras vulnerabilidades que se pueden explotar pero que son
dependientes de la implementacin de la pila TCP/IP. Por Ejemplo:
TCP FIN scan. Al enviar un paquete FIN a un puerto, deberamos recibir un

paquete de reset (RST) s dicho puerto esta cerrado. Esta tcnica se aplica
principalmente sobre implementaciones de pilas TCP/IP de sistemas Unix.
TCP Xmas Tree scan. Esta tcnica es muy similar a la anterior, y tambin
se obtiene como resultado un paquete de reset si el puerto est cerrado. En
este caso se envan paquetes FIN, URG y PUSH.
TCP Null scan. En el caso de poner a cero todos los indicadores de la

cabecera TCP, la exploracin debera recibir como resultado un paquete de
reset en los puertos no activos.
.
28.2.1 Exploracin de puertos UDP: Para poder detectar si existe un sistema de
filtrado o cortafuegos, los sistemas de Deteccin de intrusos (IDS) utilizan el
protocolo UDP para mandar paquetes UDP con 0 bytes en el campo datos, si el
puerto est cerrado se debe recibir un ICMP Port Unreachable. Si el puerto est
abierto, no se recibe ninguna respuesta. Si se detectan muchas puertas abiertas,
puede haber un dispositivo de filtrado (firewall) en el medio. Para verificar esto, se
enva un paquete UDP al puerto cero, si no se recibe una respuesta ICMP Port
Unreachable, entonces hay un dispositivo de filtrado de trfico.
Para un anlisis de vulnerabilidades en aplicaciones web que detecte ataques de
denegacin de servicio (DoS) en el caso de usar paquetes UDP para la
exploracin de puertos, hay que tener en cuenta que a diferencia de las
exploraciones TCP, se trata de un proceso mas lento puesto que la recepcin de
123

los paquetes enviados se consigue mediante el vencimiento de temporizadores

(timeouts).
28.2.2 Escaneo basado en el protocolo ICMP: La identificacin de respuestas

ICMP permite obtener huellas identificativas cuando se le da un mal uso a este
protocolo. Muchas de las caractersticas que tienen las respuestas ICMP no son
propias de los sistemas operativos. Algunos si respondern y otros no. Incluso y
as la experiencia en la implementacin de este protocolo dice que se pude
deshabilitar este servicio de deteccin de errores en los sistemas de comunicacin
a travs del mismo sistema operativo
Por lo anterior, el anlisis de respuestas ofrecidas mediante el trfico ICMP como
las del ICMP echo, ICMP timestap, ICMP information; se dar en la medida del
desarrollo del proyecto y el anlisis del ataque.
Bsicamente la interpretacin de estas respuestas ofrecidas son:
ICMP echo: comnmente llamado Ping. Se le utiliza para saber cules
son los dispositivos que se encuentran activos en una subred. Esto se
hace de forma masiva para detectar todos los host.
Los IDS tambin
detectan este tipo de dilogos.
ICMP broadcast: Se hace un nico ping a la direccin de broadcast y se
logra que todos los equipos contesten. Depende del sistema operativo la
reaccin a este tipo de
cosas. Los sistemas Windows actuales no
responden a estas solicitudes.
ICMP Timestamp: Se enva un paquete ICMP Timestamp y si el sistema
objetivo est activo, responde, nuevamente depende la implementacin del
sistema operativo si se responde o no a estos paquetes.
Otros mtodos tienen que ver con el uso indirecto de ICMP haciendo que un
equipo conteste con paquetes de este tipo cuando se introducen errores en los
paquetes IP:
IP bad header field: Se introducen errores en los campos de la

cabecera IP, esto hace que si un equipo descarta el paquete debido a
estos errores entonces notifica con un ICMP parameter problem. No
todas las implementanciones responden a los mismos errores. Esto
sirve, por ejemplo, para identificar los fabricantes de los routers.
124

Los firewall y los IDS deberan tener en cuenta este tipo de trfico, y manejarlo
con cuidado, ya que si un firewall simplemente no deja volver paquete ICMP
parameter problem, entonces un atacante puede detectar la existencia del mismo.
IP non-valid field values: Se ingresan valores incorrectos en los

campos, en respuesta a esto se debera recibir un ICMP Destination
Unreacheable. Por ejemplo, se podra indicar que en el campo datos
hay un paquete de un protocolo no existente. Si un firewall filtra los
paquetes ICMP de este tipo, entonces parecer que existen una serie
de protocolos abiertos que no existen.
28.3 FRAGMENTACIN IP.

47
La unidad mxima de transferencia (Maximum Transfer Unit - MTU) es un

trmino de redes de computadoras que expresa el tamao en bytes de la unidad
de datos ms grande que puede enviarse usando un Protocolo de Internet.
Este tamao tambin puede variar de una red a otra dependiendo el medio fsico
empleado para su transmisin. La MTU por defecto de un datagrama IP para una
red de tipo Ethernet es de 1500 bytes. Si un datagrama IP es mayor a este tamao
y necesita pasar por este tipo de red, es necesario fragmentarlo; labor que la
realiza el router o encaminador que dirige la red. Su RFC corresponde al [RFC
1191]
Esta fragmentacin puede ser usada por un atacante para hacer mal uso de eta
propiedad del protocolo IP para provocar ataques de Denegacin de Servicio
(DoS) a causa de una mala implementacin de la pila TCP/IP as como para
esconder y facilitar la fase de recogida de informacin, bsqueda de huellas
identificativas y exploracin de puertos.
Tambin esta manipulacin de la MTU permite a los atacantes cuando realizan
ataques de denegacin de servicio distribuido (DDoS), poder pasar desapercibidos
e introducir en la red paquetes para la exploracin de servicios.
Es importante tener en cuenta esta propiedad del protocolo IP de fragmentar sus
datagramas, ya que si se va a generar un mecanismos que prevea y detecte
ataques DoS, poder implementar el reensamblado de paquetes ya que hoy en da
muchos de los sistemas de deteccin de intrusos (IDS), no lo hacen y por ello no
detectan este tipo de vulnerabilidades.
47
Unidad mxima de transferencia. Disponible en Internet

<http://es.wikipedia.org/wiki/Unidad_m%C3%A1xima_de_transferencia>
125

La figura (32) se observa la configuracin de un datagrama IP no fragmentado que

contiene una cabecera UP que generalmente es de un tamao de 20 bytes con
informacin necesaria para poder dirigir el datagrama IP hacia su destino
(direccin IP de origen y destino o de encaminamiento). Los 1480 bytes de datos
restantes encapsulados corresponden pueden ser d eun protocolo TCP, UDP o
ICMP.
Figura 32. Datagrama IP No fragmentado

Fuente: <El Autor.>Adaptado<Joancomarti . J, Alfaro. J y Tornil . X. Aspectos avanzados de seguridad en
redes. P. 27
Para el siguiente ejemplo en un sistema tipo UNIX se identifica una MTU de 1500
bytes por defecto:
root@bt:~# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:a0:d1:9b:b4:56
inet addr:10.1.1.10 Bcast:10.1.1.255 Mask:255.255.255.0
inet6 addr: fe80::2a0:d1ff:fe9b:b456/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:32429 errors:0 dropped:0 overruns:0 frame:0
TX packets:42772 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:13248489 (13.2 MB) TX bytes:11158515 (11.1 MB)
Interrupt:16
root@bt:~#
La forma de modificar el tamao de la MTU se evidencia en los siguientes

comandos de UNIX para una red Ethernet con un adaptador de red eth0.
root@bt:~# ifconfig eth0 mtu 1000
root@bt:~# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:a0:d1:9b:b4:56
inet addr:10.1.1.10 Bcast:10.1.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1000 Metric:1
RX packets:32874 errors:0 dropped:0 overruns:0 frame:0
TX packets:43243 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:13306127 (13.3 MB) TX bytes:11213127 (11.2 MB)
Interrupt:16
root@bt:~#
126

Continuando el anlisis con una MTU bsica o tpica de 1500 bytes, en una
peticin de echo request del protocolo ICMP (ping) con un envo de tres paquetes
como se muestra a continuacin y con un datagrama de 4028 bytes, se puede
identificar como el protocolo ICMP separa los 8 bytes correspondiente a la
cabecera ICMP:
root@bt:~# ping -c 3 -s 4020 10.1.1.11
PING 10.1.1.11 (10.1.1.11) 4020(4048) bytes of data.
4028 bytes from 10.1.1.11: icmp_seq=1 ttl=128 time=4.73 ms
--- 10.1.1.11 ping statistics --3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 1.281/2.436/4.735/1.625 ms
root@bt:~#
La fragmentacin del datagrama de 4028 bytes se dividir en fragmentos de 1550

bytes o menos para el envo. En la Figura 33 se observa la descomposicin del
datagrama en tres partes. Cada fragmento seguir conteniendo una cabecera IP
de 20 bytes y una cabecera ICMP (peticin echo ICMP) de 8 bytes. Se ha
diferenciado con color los fragmentos de 1500 bytes y el fragmento restante de
1068 bytes.
Figura 33. Datagrama IP de 4028 fragmentado con MTU de 1500 bytes

Fuente: El autor
127

Un anlisis del re ensamblado se evidencia con el analizador de protocolos

Wireshark como se muestra en la Figura 34 y 35. Se identifica una cabecera de 20
bytes y los tres frames: (Dos de 1480 y uno de 1068 butes). Esta informacin la ha
arrojado un analizador de protocolos. Se identifica claramente la direccin IP
origen 10.1.1.2 (source) y la direccin IP destino 10.1.1.11 (Destination)
confirmando el re ensamblado IP en tres (03) Frames.
Figura 34. Reensamblado de frames en Wireshark.

Fuente: El autor
Figura 35. Fragmentacin y Reensamblado de 4028 bytes con una MTU de 1500 bytes. Analizado
en Wireshark
Fuente: El autor
128

La comunicacin TCP y su re ensamblado se confirma en la negociacin de tres

vas en el diagrama Flow Graph Figura (36). Los paquetes IP e ICMP son re
ensamblados en orden jerrquico desde su origen la direccin IP 10.1.1.2 al 57
destino la direccin IP 10.1.1.11 . Este re ensamblado se realiza en dieciocho (18)
envos que corresponden a 6 mensajes por cada fragmento. Al ser tres (03)
fragmentos se completan los 18 envos
Figura 36. Fragmentacin Reensamblado TCP. Diagrama Flow Graph

Fuente: El autor
LECCION 29: TIPOS DE ATAQUES:
Los ataques que a continuacin se describen afectan directamente la

disponibilidad de aplicaciones web.
29.1 ATAQUE TCP/SYN Flooding:
Aprovechndose de la debilidad del protocolo TCP en las primeras
implementaciones de las pilas TCP, los ataques a trabajar se basan en no poder
completar intencionalmente el protocolo de intercambio TCP. Se ha seleccionado
este tipo de ataque para su anlisis y deteccin de alarmas ya que es uno de los
ms implementados con diferentes formas de actuar. No tiene lmite de envo de
129

paquetes por lo que el rendimiento en la red se baja de inmediato y

considerablemente hasta llegar a denegar el servicio.
El ataque TCP/SYN Flooding se basa en una inundacin masiva de la red
mediante datagramas IP y por consiguiente lleva a no completar intencionalmente
el protocolo de intercambio TCP para inundar la cola de espera. La vctima se
queda esperando por establecer un servicio pues el atacante no responde con
ACK los SYN/ACK de la vctima, Esto ocurre hasta saturar los recursos de
memoria y as consigue la denegacin de servicios de la vctima. En la Figura 37
se observa en rojo la ruta del ataque. Las vctimas pueden ser todos los hosts e
incluso el router. El ataque es lanzado desde un sistema BackTrack con direccin
IP 10.1.1.10/24 que se encara de generar el trfico malicioso.
Figura37. Escenario para un ataque DoS TCP/SYN Flooding

Fuente: <El Autor.>
La denegacin de servicios se da por que el sistema est a la espera de que baje

el umbral que generalmente es 1 minuto para aceptar mas conexiones, cada
conexin generada por un SYN, tienen un temporizador de 1 minuto, cuando se
130

excede el lmite de tiempo o umbral, se libera la memoria que mantiene el estado

de la conexin y la cuenta de la cola de servicios se disminuye en 1. El atacante
debe usar un IP falso para que no le hagan seguimiento a las conexiones.
La interpretacin del ataque se presenta en la tabla (5) en donde se indican los
flujos de origen y destino en el ataque.
Diagrama del ataque TCP/SYN Flooding

ORIGEN
DESTINO
IP=1.2.3.4 SYN
IP=10.1.1.11
IP=1.2.3.4 SYN/ACK
IP=10.1.1.11
Nunca responde con ACK
El IP=10.1.1.11guarda en la cola la peticin

de conexin por 1 minuto
Se repite la secuencia de requerimiento
El IP=10.1.1.11se satura por tanto

requerimiento encolado y ocurre el DoS
Cualquier IP cliente pide servicio al servidor El IP=10.1.1.11 no puede atender

requerimientos pues est en medio de un
ataque DoS. Solamente cuando cese el
ataque automticamente se atienden los
requerimientos de los clientes
Tabla5. Diagrama del ataque TCP/SYN Flooding
Fuente: <El Autor>
Procedimiento: La instruccin del ataque es as:

# hping2 10..1.11 -rand-source S -destport 80 -faster --debug w 2048
La explicacin de esta instruccin est dada en la tabla (6)
Descripcin de los parmetros:

PARAMETRO
DESCRIPCION
10.1.1.11
IP de la Victima
--rand-source
IP ficticio o spoofed, se genera aleatorio, la

idea es que no exista en la red, al no existir
este no responde y as el atacante pasa
inadvertido
--debug
Muestra cada intento

131

-S
Indica el flag S o SYN para solicitar un

servicio
--destport
Indica el servicio requerido, es clave que

este
servicio este habilitado en la victima
--faster
Hace el intento de envi de SYN lo mas

rpido que se pueda
.w 2048
La ventana de envo mximo ser de 2048
Tabla 6. Descripcin de los parmetros del ataque TCP/SYN Flooding

Fuente: <El Autor
Las opciones de envo o inundacin de peticiones que hacen de este ataque uno
de los mas perpetrados en redes Ethernet son comprobadas mediante el
incremento del envo de paquetes por cada segundo que pasa. Debe inundarse la
red con muchos paquetes por segundo para que el ataque sea efectivo. Estas
opciones se ejecutan con los siguientes comandos:
# hping2 10.30.30.45 -rand-source S -destport 80 -faster --debug w 2048
-iu1000000, para 1 paquete por segundo
-iu500000, para 2 paquetes por segundo
-iu333333, para 3 paquetes por segundo (*)
Tipo de datagramas: La inundacin de datagramas IP puede ser de diferentes
tipos:
UDP: Generar peticiones sin conexin a cualquiera de los 65535 puertos
disponibles. En muchos sistemas operativos, las peticiones masivas a puertos
especficos UDP (ECHO, WINS) causan el colapso de los servicios que lo
soportan.
ICMP: Generacin de mensajes de error o control de flujo malicioso. En este caso
el objetivo es doble, degradar el servicio de red con la inundacin de peticiones y/o
conseguir que los sistemas receptores quede inutilizados por no poder procesar
todas las peticiones que les llegan.
132

TCP: Genera peticiones de conexin con el objetivo de saturar los recursos de red
de la mquina atacada. Este protocolo es orientado a conexin, y como tal
consume recursos de memoria y CPU por cada conexin. El objetivo es el de
saturar los recursos de red disponibles de los ordenadores que reciben las
peticiones de conexin y degradar la calidad del servicio.
29.2 Ataque Broadcast IP Flooding:
Es una variante del ataque IP Flloding. Anlogamente, IP tambin tiene un sistema
de radiodifusin (broadcast) [RFC919] que permite la comunicacin simultnea
con todos los ordenadores de la misma red. En este tipo de ataque se utiliza la
direccin de identificacin de la red IP (broadcast address) como direccin de
destino del paquete IP. De esta forma, el router se ve obligado a enviar el paquete
a todos los ordenadores pertenecientes a la red, consumiendo ancho de banda y
degradando el rendimiento del servicio.
Tambin existen variantes dnde se envan peticiones de PING a varios
ordenadores falseando la direccin IP de origen y substituyndola por la direccin
de broadcast de la red a atacar. De esta forma, todas las respuestas individuales
(Figura 38) se ven amplificadas y propagadas a todos los ordenadores
pertenecientes a la red amplificndolas y propagndolas consiguiendo una alta
efectividad en el ataque.
Figura38. Ataque Broadcast IP Flooding

Fuente: <El Autor.>
133

29.3 Smurf: Este tipo de ataque se basa en falsear las direcciones de origen y
destino de una peticin ICMP de ECHO (ping). La Figura 39 muestra la topologa
del ataque que como direccin de origen utiliza la direccin IP de la mquina que
va a ser atacada. En el campo de la direccin de destino se ubica la direccin
broadcast de la red local o red que se utilizar como lanzadera para colapsar al
sistema elegido. Con esta peticin fraudulenta, se consigue que todas las
mquinas de la red contesten a la vez a una misma mquina, consumiendo el
ancho de banda disponible y saturando al ordenador elegido.
Figura39. Ataque Smurf

Fuente: <El Autor.>
La sintaxis bsica para este ataque es:

hping3 -a [IP objetivo a spoofear] --flood [IP Broadcast]
29.4 STeardrop: Este tipo de ataque aprovecha las deficiencias que presenta el
reensamblado de paquetes IP cuando son fragmentados. Por definicin del
protocolo, un paquete IP tiene un tamao mximo de 64K (65.535Bytes).
root@bt:~# ping -c 3 -s 70000 10.1.1.16
Error: packet size 70000 is too large. Maximum is 65507
root@bt:~#
134

Cada red por la que transitan los paquetes IP tiene un tamao mximo de paquete
(MTU, Maximum Transfer Unit), es por ello que se necesitan fragmentar los
paquetes IP en varios trozos que sern reconstruidos al llegar al destino.
El protocolo IP especifica unos campos en la cabecera encargados de sealar si el
paquete IP est fragmentado (forma parte de un paquete mayor) y que posicin
ocupa dentro del datagrama original. En la Figura 40 se observan los campos que
intervienen en la fragmentacin.
Figura40. Cabecera Paquete IP V 4.0.

Fuente: <El Autor.>
En el campo de banderas (flags) existe un bit denominado More (mas) que

indica que el paquete recibido es un fragmento de un datagrama mayor,
igualmente el campo de nmero de identificacin del datagrama especifica la
posicin del fragmento en el datagrama original.
El ataque teardrop utiliza esta funcionalidad para intentar confundir al sistema
operativo en la reconstruccin del datagrama original y lograr el colapso del
servicio y/o del sistema. Este ataque y sus variantes se basan en falsear los datos
de posicin y/o longitud de forma que el datagrama se sobrescriba (overlapping)
y produzca un error de sobreescritura del buffer (buffer-overrun) al tratar con
desplazamientos negativos
Usualmente el sistema operativo detecta el intento de acceso a una zona de
memoria que no corresponde al proceso ejecutado y aborta el servicio.
Dependiendo de la robustez del sistema operativo podemos perder solo el
servicio atacado o incluso llegar a colapsar todo el ordenador.
135

Otra variante de este ataque consiste en enviar cientos de fragmentos

modificados de forma que se solapen con el objetivo de saturar la pila de
protocolo IP de la mquina atacada.
29.5 Snork: El protocolo IP necesita verificar su funcionamiento. Par realizar esta
accin el sistema enva un datagrama especial al ordenador destino, que lo
reconoce y enva una respuesta al origen (ECHO
REPLY). El protocolo IP
define para estas pruebas [RFC862] un servicio para la recepcin de un
datagrama UDP al puerto 7 (ECHO). Existe un servicio proporcionado en muchos
sistemas operativos tipo UNIX denominado CHARGEN (CHARacter GENerator,
generador de caracteres) que dada una peticin responde con una secuencia
aleatoria de caracteres.
Este servicio se encuentra disponible escuchando en el puerto 19 a datagramas
UDP. En sistemas Windows NT se suele utilizar el puerto 135 (Microsoft Locator
Service) para el ataque snork. En la Figura 41 se muestra el escenario tpico del
ataque Snort que se basa en una utilizacin malintencionada de estos dos
servicios tpicos en sistemas UNIX (CHARGEN y el servicio ECHO). El ataque
consiste en cruzar ambos servicios enviando una peticin falsa al servicio
CHARGEN (que retorna una secuencia de caracteres pseudo-aleatoria) falseando
la direccin de origen dando como puerto de respuesta el puerto ECHO (que
responde a cualquier peticin) de la mquina a atacar. De esta forma, se inicia un
juego de pingpong infinito.
Figura41. Ataque DoS Snork

Fuente: <El Autor.>
136

Este ataque puede realizarse entre varios ordenadores (consumiendo ancho de

banda y degradando el rendimiento de la red) o desde un mismo ordenador (l
mismo se enva una peticin y responde) consiguiendo consumir los recursos
existentes (especialmente CPU y memoria) de la mquina atacada.
29.6 Ataque Distribuido TRINOO /TRIN00: Es una herramienta que implementa

un ataque de denegacin de servicio mediante un modelo jerrquico
maestro/esclavo (master/slave).
El ataque consiste en la instalacin de las herramientas de TRIN00 (sniffers de
red, puertas traseras o backdoors, daemons, root-kits.) en los equipos desde los
que partir el ataque. Esta instalacin las ha hecho previamente el atacante
aprovechando bugs conocidos del sistema operativo (buffer overflow) o mediante
tcnicas de sniffing con explotacin de servicios.
Posteriormente, desde este ordenador comprometido se procede al rastreo
(scanning) de otros ordenadores con vulnerabilidades conocidas en servicios
bsicos (FTP, RPC, NFS) para proceder a su infeccin. Este rastreo suele
realizarse dentro de la misma red ya que la velocidad de transmisin es ms
rpida y permite verificar ms mquinas por segundo. Por otro lado las medidas
de seguridad entre ordenadores locales suelen ser mnimas.
Con los resultados obtenidos del rastreo se genera una lista de ordenadores
vulnerables dnde se ejecutarn los programas para obtener el acceso (exploits).
Para verificar que ordenadores de la lista han podido ser captados, el ordenador
de origen suele tener un proceso demonio (daemon) que escucha el puerto TCP
1524, dnde se enviar una seal por cada ordenador infectado.
La arquitectura de este ataque se ve en la Figura 42 en un diagrama de tres
capas. Se observa cmo a partir de un nico computador el atacante podr llegara
obtener toda una red de equipos a su disposicin para realizar el ataque
distribuido.
137

Figura42. Ataque DDoS TRIN00

Fuente: <El Autor.>
La comunicacin entre las distintas capas se realiza mediante conexiones TCP

(fiables) para la parte atacante-master, y conexiones UDP (no fiables) para la
parte master-save y slave-master, en puertos especficos para cada mquina.
La comunicacin siempre se inicia con la transmisin de una contrasea. Esto
permite que ni el administrador del equipo ni el de otros atacantes puedan acceder
al control de la red de ataques de TRIN00.
Los demonios de TRIN00 situados en los equipos master y slave permiten la
ejecucin de comandos para iniciar, controlar y detener ataques de denegacin
tradicionales como ICMP Flloding, SYN Flooding, Smurf, etc. Para acceder a estos
comandos, el atacante realizar una conexin Telnet en el puerto especificado
como el que se relaciona en la Figura 43. 48
48
<HERRERA. Jordi, GARCIA, Alfaro y PERRAMON. Javier. Aspectos Avanzados de Seguridad

en Redes. UOC. Espaa. P. 42>
138

Figura43. Esquema de comunicaciones de TRIN00

Fuente: <El Autor.>
LECCION 30: HERRAMIENTAS QUE AYUDAN A PREVENIR ATAQUES (DoS):

La seleccin de las herramientas a usar (tabla 7) enmarcan un sistema de
deteccin de intrusos que a la vez realice gestin de red se compone de una serie
de herramientas software que ayudan al ingeniero a gestionar una red de datos.
Estas herramientas suelen incluir elementos y servicios que en conjunto forman un
sistema completo de gestin. La mayora de ellas ofrecen caractersticas como:
Ofrecen al usuario un interfaz grfico
Suelen ofrecer facilidades de exportacin de datos para su tratamiento

mediante bases de datos, hojas de clculo, etc.
Gestin proactiva: generacin de informes basados en web, con datos

histricos que ayudan a identificar problemas potenciales, mediante anlisis
de tendencias.
Los datos recopilados acerca de la topologa, los eventos generados y los

datos recogidos mediante SNMP se almacenan de manera inteligente.
Capacidad de tolerancia a fallos: planificacin de copias de seguridad de la

informacin de gestin ms sensible
139

HERRAMIENTAS
FUNCION
Descubrimiento automtico Un descubrimiento dinmico, proactivo, reactivo y

de la topologa de la red
programado permite una deteccin rpida y eficiente de
los cambios y las actualizaciones en la red.
Herramientas de diagnstico Este conjunto de herramientas permite que el usuario
de la red
conozca el estado de su conexin
Herramientas de seguridad
Proveen los mecanismos adecuados para que la

informacin de una organizaron o empresa sea segura, y
esto se consigue con las garantas de:
Confidencialidad: que garantiza que la informacin sea
accesible
Integridad: protege la exactitud y totalidad de la
informacin
Disponibilidad: que garantiza a los usuarios autorizados
acceso a la informacin y los recursos.
Diagnstico de problemas
Detectar, prevenir y diagnosticar problemas de
conectividad o funcionamientos con un servicio de red.
Especialmente en los niveles uno (1) y dos (2) del modelo
OSI.
Monitorizacin de la red
Monitorea grficamente servicios de red, protocolos e
interfaces.
Monitoreo de desempeo:
Disponibilidad.
Tiempos de respuesta.
Carga de cpu, espacio de disco, uso de la memoria.
Monitoreo de Seguridad
--Recoleccin de indicadores y alertas.
Anlisis y correlacin por parte del analista
Alarma al equipo de toma de decisiones
Gestin de MIBs
Navegadores de MIBs (MIB Browsers)
Compiladores de MIBs
Generadores de trfico
Calculadoras de direcciones IP
Servidores TFTP
Software de Gestin de red
Muy simple (SNMP) o muy complejo (OSI)
Requiere acceso a MIB local y a agentes y gestores
remotos.
Gestin de direcciones de Calculadoras IP
red
Software Vlans: Adminstra direcciones de red por varios
mtodos:
--Por los servicios que presta cada host.
--Por Protocolos.
--Por Puertos.
--Por direcciones fsicas Mac Adress
Analizador de protocolos
Herramientas que sirve para desarrollar y depurar
protocolos y aplicaciones de red. Permite al ordenador
capturar diversas tramas de red para analizarlas, ya sea
en tiempo real o despus de haberlas capturado. Por
analizar se entiende que el programa puede reconocer
140

que la trama capturada pertenece a un protocolo

concreto.
Finalmente le muestra al usuario la informacin
codificada.
Analizadores de niveles de El usuario puede ver todo aquello que en un momento
carga en la red.
concreto est circulando por la red que se est
analizando.
Software e presentacin
Permite al usuario monitorizar y controlar la red
Interfaz de usuario unificada
La misma en cualquier nodo
Organizan, resumen y simplifican la informacin
Representacin grfica preferible
Lenguajes de programacin
Para manipular bugs, registros de logs, creacin de
sniffers.
Tabla 7. Herramientas de gestin que ayudan a detectar ataques DoS
Fuente: <El Autor>
El anlisis est enfocado al uso de herramientas de software Libre, teniendo en

cuenta que la eficiencia de la gestin de red, y sus plataformas, se garantizan en
arquitecturas tipo UNIX por las caractersticas propias de ese sistema. Por la gran
diversidad de las mismas, solo se definen las ms efectivas o implementadas y las
que son bsicas para posteriormente ahondar en ellas, combinarlas y
complementarlas para as construir un modelo que permita la deteccin de
ataques DoS. Los sistemas de gestin y de deteccin de intrusos, se componen
de diversas herramientas, hacen uso de servicios, protocolos y tcnicas de
captura y anlisis de informacin.
FUNCION QUE
CUMPLE
DESCUBRIMIENTO
AUTOMTICO DE
LA TOPOLOGA DE
LA RED
HERRAMIENTAS DE
MONITOREO DE
RED
NOMBRE
DESCRIPCION
Nmap: programa de cdigo

abierto que sirve para efectuar
rastreo de puertos .
Fuente: http://nmap.org/
Ettercap:
Es
un
interceptor/sniffer/registrador
para LANs con ethernet
basado
en
terminales
(terminal-based)
Fuente:
http://ettercap.sourceforge.net
NTop: Un monitor de uso de
trfico de red.
Fuente: http://www.ntop.org/
141
Descubrimiento de servidores: Identifica

computadoras en una red, por ejemplo listando
aquellas que responden ping. Identifica
puertos abiertos en una computadora objetivo.
Determina qu servicios est ejecutando la
misma.Determinar qu sistema operativo y
versin utiliza dicha computadora, (esta
tcnica
es
tambin
conocida
como
fingerprinting).
Obtiene algunas caractersticas del hardware
de red de la mquina objeto de la prueba.
Ntop muestra el uso de la red en una manera
similar a lo que hace top por los procesos. En
modo interactivo, muestra el estado de la red
en una terminal de usuario. En Modo Web,
acta como un servidor de Web, volcando en
HTML el estado de la red. Viene con un
recolector/emisor NetFlow/sFlow, una interfaz
de cliente basada en HTTP para crear
aplicaciones de monitoreo centradas en top, y

ANALIZADOR DE
PROTOCOLOS
HERRAMIENTAS DE
SEGURIDAD
Wireshark:
Fuente:
http://www.wireshark.org/
Snorth: Sistema de deteccin

de intrusiones de red de poco
peso (para el sistema), capaz
de realizar anlisis de trfico
en tiempo real y registro de
paquetes en redes con IP.
RRD para almacenar persistentemente

estadsticas de trfico
Es un analizador de protocolos de red para
Unix y Windows, Permite examinar datos de
una red viva o de un archivo de captura en
algn disco.
Utilizados para mostrar los encabezados de
los paquetes en una interfaz de red (network
interface) que concuerden con cierta expresin
de bsqueda
Fuente: http://www.snort.org/
TCPDump: Paquetes de red
basado en texto..
Fuente:
http://www.tcpdump.org/
GESTION DE MIBS
Apache
Fuente:
http://httpd.apache.org/
Servidor Web
MySQL
Fuente:
http://www.mysql.com/
Sistema de gestin de base de datos

relacional
Interprete PHP
Fuente:
http://www.php.net/
Lenguaje de programacin interpretado,
Servidor JFFNMS
Fuente:
http://www.jffnms.org/
Servidor Integrado para monitoreo y gestin de

dispositivos
Generador de grficos
RRDtool
Fuente:
http://oss.oetiker.ch/rrdtool/
GESTIN DE
DIRECCIONES DE
RED
Hping
Fuente: http://www.hping.org/
Sipcalc
ADMINISTRADOR
DE SERVICIOS
Fuente:
http://www.routemeister.net/pr
ojects/sipcalc/
Webmin
Trabaja en lnea de comandos. Orientada a

Analizar paquetes TCP/IP. La interfaz est
inspirada en el servicio ping de comandos de
Unix.
hping enva solicitudes de echo ICMP. Soporta
TCP, UDP, ICMP y RAW-IP, tiene un modo de
traceroute y la capacidad de enviar archivos
entre un canal cubierto o protegido.
Herramienta de configuracin de sistemas
accesible va web
Fuente
http://www.webmin.com/
Tabla8. Herramientas utilizadas

Fuente: <El Autor>
142

GLOSARIO DE TERMINOS:
Abuso de funcionalidad: Una tcnica de ataque que usa las caractersticas

y la funcionalidad de un sitio web para consumir, estafar o evadir el
acceso al sitio. Tambin puede tener referencia con el trmino (DoS).
Autenticacin: El proceso de verificacin de la identidad o localizacin de un
usuario, servicio o aplicacin. La autenticacin se realiza utilizando al menos
uno de tres mecanismos: "algo que tienes", "algo que s "o" algo que es. La
aplicacin puede autenticar y proporcionar diferentes servicios basados en la
ubicacin, mtodo de acceso, el tiempo de permanencia y los hbitos de uso de
la aplicacin web.
Autenticacin Bsica: Una forma simple de autenticacin del cliente
apoyado en HTTP. El cliente HTTP enva un encabezado con la solicitud al
servidor web que contiene un nombre de usuario y la contrasea codificada en
Base64.Si la combinacin de nombre de usuario / contrasea es vlida, entonces
se da el acceso al recurso solicitado.
Autorizacin: La determinacin de los recursos que un usuario, un servicio
o aplicacin tienen como permisos de acceso. Recursos accesibles que pueden
ser URL, archivos, directorios, bases de datos, servelets, caminos de ejecucin.
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 cdigo abierto para plataforma
Unix (BSD, GNU/Linux, etc.), Windows, Macintosh y otras, que implementa el
protocolo HTTP/1.1, y la nocin del sitio virtual.
ASN (Abstract Syntax Notation): Lenguaje utilizado para definir tipos de datos.
Backup File Disclosure: Divulgacin del archivo de copia de seguridad:
(Obsoleto). Actualmente se usa el trmino: "Ubicacin de archivo predecible".
Brute Force: Un proceso automatizado de prueba y error utilizado para adivinar
el "secreto" de la proteccin de un sistema. Ejemplos de estos secretos son
nombres de usuario, contraseas o claves criptogrficas. Tambin puede
asociarse a trminos como: "Autenticacin", "Autenticacin insuficiente",
143

"Password Recovery Sistema "," La dbil validacin de recuperacin de

contrasea ".
BROADCAST: Transmisin de un paquete que ser recibido por todos los
dispositivos en una red.
Buffer Overflow: Desbordamiento de Buffer: Una tcnica de explotacin que
altera el flujo de una aplicacin sobrescribiendo partes de la memoria.
Desbordamientos de bfer es una causa frecuente de un mal funcionamiento del
software. Si los datos escritos en un bfer superan su tamao, el espacio de
memoria adyacente se corromper y normalmente producen un fallo. Un atacante
puede ser capaz de utilizar esta situacin de desbordamiento y alterar el proceso
del flujo de una aplicacin. Si sobrecarga el buffer y se sobrescriben por ejemplo
los punteros en la pila de memoria, esta accin podra 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 ms all
de probar una serie de peticiones HTTP contra conocidas cadenas de CGI
Client-Side Scripting: Funcin de navegador Web que extiende la funcionalidad
e interactividad del lenguaje de marcado de hipertexto (HTML) esttico en las
pginas web. Ejemplos de lenguajes de script del lado del cliente son JavaScript,
JScript y VBScript. Vase tambin "controles ActiveX", "Java Applets ".
CGI:
Acrnimo:
(Common
Gateway
Interface):
Programacin
estndar para el software para conectar y ejecutar aplicaciones que residen
en los servidores web. Vase tambin "Aplicacin Web", "Servidor de
aplicaciones",
"Servidor Web
Controles ActiveX: Controles ActiveX son programas informticos 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 programacin. Ellos son ampliamente
utilizados por las aplicaciones web para extender su funcionalidad (por ejemplo: el
sitio Windows Update) Vase tambin "Java", "applets Java", "JavaScript", "Web
Browser ".
Content Spoofing: La suplantacin de contenido: Una tcnica de ataque
utilizada para engaar a un usuario para que acceda a contenidos falsos
creyendo que son datos legtimos.
144

Cookie: Pequea cantidad de datos enviados por el servidor web, a una web de
un cliente, que puede ser almacenada y recuperada en un momento posterior.
Tpicamente se utilizan cookies para realizar un seguimiento de un estado de los
usuarios a medida que usan, navegan o interactan con un sitio web.
Cookie Poisoning: (Obsoleto). Vea Manipulacin Cookie.
Cross-Site Scripting: (acrnimo - XSS) Una tcnica 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
interacta entre varios sitios y aplicaciones que estn haciendo eco de datos
entre s, el atacante tendr acceso a todo el contenido navegador web (cookies,
historial, versin de la aplicacin, etc). Vase tambin "Client-Side Scripting".
CSMA/CD (Carrier Sentido acceso mltiple / Deteccin de Colisin) es el protocolo
usado en Ethernet en red para garantizar que slo un nodo de red se transmite en
el cable de red en cualquier momento.
CONFIDENCIALIDAD: Que la informacin solo sea vista por los lentes
involucrados en la comunicacin y que un tercer no pueda ingresar.
CONTROL DE ACCESO Y AUTORIZACIN: el proceso de determinar los
recursos y servicios que puede usar una entidad.
CORTAFUEGOS: Elemento de prevencin que realizara un control de acceso
para proteger una red de los equipos del exterior (potencialmente hostiles).
DENEGACIN DE SERVICIO (DoS): ataque que hace una apropiacin exclusiva
de un recurso o servicio con la intencin de evitar cualquier acceso a terceras
partes. En ingls, deny of service.
Debug Commands: Los comandos de depuracin: Son caractersticas de
depuracin de aplicaciones o comandos que ayudan a identificar los errores de
programacin durante el proceso de desarrollo de software.
Directory Traversal:
Una tcnica utilizada para explotar sitios web al
acceder a los archivos y los comandos ms all del directorio raz de los
documentos que forman la estructura del sitio. La mayora de los sitios web deben
restringir el acceso de usuarios a una parte especfica del sistema de archivos
que normalmente se denomina el directorio raz de documentos o de raz CGI
directorio.
Estos
directorios
contienen
los
archivos
ejecutables
destinados al uso pblico. En la mayora de los casos, un usuario no debera
poder acceder a los archivos ms all de este punto.
145

DESBORDAMIENTO DE BUFFER: posibilidad de corromper la pila de ejecucin

para modificar el valor de retorno de una llamada a funcin y provocar la ejecucin
de cdigo arbitrario.
DISPONIBILIDAD: Los servicios y la informacin deben, en todo momento, estar
disponibles.
DNS: Servicio de Nombres de Dominio.
DoS: (de las siglas en ingls Denial of Service), Ataque de Denegacin de servicio
DDoS: (de las siglas en ingls Distribuited Denial of Service), Ataque de
Denegacin de servicio Distribuido
Encoding Attacks: Los ataques de codificacin: una tcnica que ayuda a la
explotacin de un ataque de cambiar el formato de los datos proporcionados por
el usuario para omitir la comprobacin de aplicacin de filtros. Vase tambin "
Null Injection".
Examen de directorios: (Obsoleto) Vase "Indexacin de Directorio".
Enumeracin de Directorio: (Obsoleto) Consulte "Ubicacin de archivo
predecible"
Expiracin de sesin insuficiente: Cuando un sitio web permite a un
atacante reutilizar credenciales de sesiones viejas o anteriores para
autorizacin y poder tener ingreso.
Form Field Manipulation: Manipulacin de campos en formularios: La alteracin
o modificacin de formularios HTML. Los valores del campo de entrada que se
ingresan mediante HTTP, sirven para explotar los problemas de seguridad en una
aplicacin web. Vase tambin "Cookie
ESCNER DE VULNERABILIDADES: aplicacin que permite comprobar si un
sistema es vulnerable a un conjunto de deficiencias de seguridad.
EXPLOIT: aplicacin, generalmente escrita en C o ensamblador, que fuerza las
condiciones necesarias para aprovecharse de un error de programacin que
permite vulnerar su seguridad.
EXPLORACION DE PUERTOS: tcnica utilizada para identificar los servicios que
ofrece un sistema.
146

EXPLOTACIN 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 tcnica de explotacin que altera el flujo de una
aplicacin mediante operaciones de biblioteca de formato de cadenas para
acceder a otra instancia o momento de la aplicacin.
FRAGMENTACIN IP: proceso de divisin de un datagrama IP en fragmentos de
menor longitud.
HERRAMIENTA DE MONITOREO JFFNMS: Es un sistema de gestin y
monitorizacin 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 extensin adecuada a dicho
elemento JFFNSM.
HIDS: Sistemas de deteccin de intrusos de Ordenador
HUELLA IDENTIFICATIVA: informacin muy precisa que permite identificar un
sistema o una red en concreto. En ingls, fingerprinting.
ICMP: Internet Control Message Protocol.
IANA: Internet Assigned Numbers Authority
Indexacin de Directorio: Una caracterstica comn a los servidores web ms
populares, que expone el contenido de un directorio cuando no est presente la
pgina de ndice. Vase tambin "Ubicacin del archivo predecible".
Insuficiente Autenticacin: cuando un sitio web permite a un atacante
acceder a contenido sensible o a sus funcionalidades sin verificar su
identidad. Vase tambin "Autenticacin".
Insuficiente Autorizacin: Cuando un sitio web permite a un atacante
acceder a contenido sensible o a sus funcionalidades que deberan requerir
mayores restricciones de acceso y control. Vase tambin "Autorizacin".
147

IDS (Intrusion Detection System): Sistema de deteccin de Intrusos. Es una

herramienta que permite monitorear el comportamiento y el uso que se le da a los
recursos en una mquina y detectar si alguien est haciendo algo indebido.
IEEE: Tecnologa desarrollada por Apple Computer en 1986 que permite transmitir
informacin a alta velocidad. Fue adoptado como estndar en 1995 y es similar al
puerto USB.
IEEE 802.3 proporciona una LAN estndar desarrollada originalmente por Xerox y
ampliada. Define dos categoras: banda base (especfica una seal digital) y
banda ancha (especifica una seal analgica). IEEE define nicamente una
especificacin para la categora de banda ancha. Sin embargo, la restriccin de la
mxima 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 interconexin 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
programacin
popular
desarrollado
por
Sun
Microsystems (tm). Vase tambin "ActiveX controls", "Navegador Web",
"JavaScript", "Client-Side Scripting".
Java Applets: Un applet es un programa escrito en un lenguaje de programacin
como Java que puede ser incluido en una pgina web. Cuando un
navegador web tiene habilitado java, y la pgina contiene applets , el
cdigo es ejecutado por la mquina virtual de Java (JVM). Vase tambin "Web
Browser "," Java "," ActiveX "," JavaScript "," Client-Side Scripting ".
JavaScript: Lenguaje de scripting del lado cliente utilizado por el navegador web,
para crear contenido dinmico pgina web. Vase tambin "ActiveX", "Java
Applets "," Client-Side Scripting ".
LDAP Inyeccin: Una tcnica para la explotacin de un sitio web mediante la
alteracin de backend sentencias LDAP a travs de la manipulacin de entrada
de la aplicacin. Al igual que en la metodologa de inyeccin SQL. Vase tambin
"Parmetro Manipulacin "," Manipulacin de campos de formulario.
148

MAC: Media Access Control

Manipulacin Cookie: La alteracin o modificacin de los valores de las cookies
del navegador web del cliente, para explotar aspectos de seguridad dentro de una
aplicacin web. Los atacantes normalmente manipulan los valores de los cookies
para autenticarse y realizar fraudes a la aplicacin web. Este es un tpico ejemplo
de establecer por defecto la configuracin predeterminada de los navegadores .
Vase tambin "Cookie".
Manipulacin de Nombre de Archivo: Una tcnica de ataque usada para
explotar sitios web mediante la manipulacin de los nombres de archivo de URL
para provocar errores de aplicacin, descubrir el contenido oculto, o visualizar el
cdigo fuente de una aplicacin. Vase tambin "Ubicacin del archivo
predecible".
MODEM ADSL: Modula las seales enviadas desde la red local para que puedan
transmitirse por la lnea ADSL y demodula las seales recibidas por sta para que
los equipos de la LAN puedan interpretarlos. De hecho, existen configuraciones
formadas por un mdem ADSL y un router que hacen la misma funcin que un
router ADSL.
MTU: Maximum Transfer Unit
MySQL: Es un sistema de gestin 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 deteccin de intrusos de Red.
NMAP: Programa de cdigo abierto que abierto que sirve para efectuar rastreo de
puertos TCP y UDP. Se usa para evaluar la seguridad de sistemas informticos
as como para descubrir servicios o servidores en una red informtica.
NMS (Network Management Station): estacin 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 nmeros 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 estndar de comunicacin para dichas tareas.
OWASP:(The Open Web Application Security Project).
149

PDU (Protocol Data Unit): define la estructura de la informacin que va a ser

enviada por la red.
PHP: Es Un lenguaje de programacin interpretado, diseado originalmente para
la creacin de pginas web dinmicas. Es usado principalmente en interpretacin
del lado del servidor (serverside scripting) pero actualmente puede ser utilizado
desde una interfaz de lnea de comandos o en la creacin 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 travs de una lnea telefnica con un
servicio ADSL.
Revelacin de Informacin: 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 travs de
HTTP, que tiene la capacidad de ejecutar aplicaciones web dinmicas. Tambin
se conoce como middleware.
RRDTOOL: Herramienta que trabaja con una base de datos que maneja
planificacin segn Round-Robin. Esta tcnica 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
configuracin de dispositivos de red desde una estacin de trabajo.
SMI (Structure of Management Information): define agrupaciones, nombres,
tipos de datos permitidos y la sintaxis para escribir MIBs.
SYN: Bit de control dentro del segmentoTCP.
SYN FLOODING: Ataque de denegacin de servicio que se basa en no
complementar intencionadamente el protocolo de intercambio de TCP.
TCP: Transmission Control Protocol.
150

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 envo de mensajes SNMPv3.
Ubicacin de Archivo Predecible: Una tcnica 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 automticamente a los los nombres y ubicaciones
de los archivos. Los lugares pueden incluir directorios, archivos de configuracin
de copia de seguridad archivos, archivos temporales, etc
Validacin de proceso insuficiente: cuando un sitio web permite a un
atacante para eludir o evadir el control de flujo previsto de un
aplicacin.
VACM (View-based Access Control Model): modelo de control de acceso que
permite administrar quien tiene acceso a qu informacin 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 cdigo abierto,
incluyendo analizadores de protocolos, monitores de red, sistemas de deteccin
de intrusos de red.
151

ANEXOS
ANEXO 1:
OWASP Top 10. Traducido al espaol: Documento pdf de 22p.
Copyright 2003 2010 Fundacin

OWASP
Este documento es publicado bajo la licencia Creative Commons Attribution ShareAlike 3.0. Para
cualquier reutilizacin o distribucin, usted debe dejar en claro a otros los trminos de la licencia
sobre este trabajo.
ANEXO 2: Informe que compara las licencias de desarrollo, la tecnologa y las

fuentes de los diferentes escneres.
ANEXO 3: Informes comparativo de la deteccin de vulnerabilidades de los
distintos escneres probados:
ANEXO 4: Informe que compara las caractersticas complementarias de deteccin
de vulnerabilidad en los buscadores probados:
ANEXO 5: Informe donde se comparan las caractersticas de usabilidad, cobertura
y estabilidad de los buscadores probados:
152

FUENTES DOCUMENTALES
LUIS GMEZ FERNNDEZ Y ANA ANDRS LVAREZ . Gua de aplicacin de la Norma UNEISO/IEC 27001 sobre seguridad en sistemas de informacin para pymes. 2. edicin
Autores: AENOR (Asociacin Espaola de Normalizacin y Certificacin), 2012 Todos los
derechos reservados. AENOR. ISBN: 978-84-8143-7 - Impreso en Espaa Edita:
AENOR Maqueta y diseo 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 Arqus Soldevila y Eduard Marco Galindo. Editorial
UOC Primera edicin en lengua castellana: noviembre 2008. Espaa: 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 crticos sobre seguridad de software:

fallas de programacin y cmo corregirlas. Pg: 305. Editorial: McGraw-Hill Professional
Publishing Ubicacin: Mxico. Fecha de publicacin: 12/2010. Idioma: es pISBN:
9789701058985
DAZ, GABRIEL MUR, FRANCISCO SANCRISTBAL, ELIO. Seguridad en las comunicaciones y

en la informacin. Pginas: 473. Editorial: UNED - Universidad Nacional de Educacin a
Distancia. Ubicacin: Espaa. Fecha de publicacin: 2004. Idioma: es
Nmero de clasificacin 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
153

CARVAJAL, A. Introduccin a las tcnicas de ataque e investigacin Forense,

Un enfoque pragmtico. Colombia, Agosto de 2007, seg Ed, p. 245
CRUZ, A y TORRES, P. Sistema para Generar Grficas a Partir de Logs

Tcpdump usando Hadoop. Escuela Superior Politcnica 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
154

L Material12-ModuloSeguridaddeAplicacionesWebUNAD PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

L Material12-ModuloSeguridaddeAplicacionesWebUNAD PDF

Uploaded by

Copyright:

Available Formats

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD

Escuela de Ciencias Bsicas Tecnologa e Ingeniera

SEGURIDAD EN APLICACIONES WEB

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD

ASPECTOS DE PROPIEDAD INTELECTUAL Y

GUA DIDCTICA Autor: Carlos Alberto Amaya Tarazona

CURSO SEGURIDAD EN APLICACIONES WEB

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD

Leccin 1: INTRODUCCION AL PROTOCOLO HTTP

1.1 Caractersticas y Funcionamiento

Leccin 2: VULNERABILIDADES EN APLICACIONES WEB

2.1 Como trabajan las aplicaciones web

Leccin 3: HERRAMIENTAS PARA LA DETECCIN DE VULNERABILIDADES 35

4.1 Auditora y control de vulnerabilidades

Leccin 5: SISTEMA DE LOGS

5.1 Formato del fichero de LOG

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD

5.2 Anlisis del fichero de LOG

CAPITULO 2: PROTOCOLOS DE SEGURIDAD PARA APLICACIONES WEB 49

6.1 Metodologas de anlisis de seguridad web

Leccin 7: ESCALACION DE PRIVILEGIOS EN APLICACIONES WEB

Leccin 8: AUTENTICACION Y AUTORIZACION

Leccin 9: EJECUCION DE INSTRUCCIONES DE ACCESO

9.1 Codificacin y las validaciones de Entrada / Salida

Leccin 10: CONFIGURACION SEGURA DE SERVIDORES

10.1 Organizacin del servidor Web

CAPITULO3: DESARROLLO SEGURO DE APLICACIONES

Leccin 11: CONCEPTOS GENERALES PARA EL DESARROLLO SEGURO

11.1 Normas bsicas de seguridad

Leccin 12: CONTROLES DE AUTORIZACION DE OBJETOS

12.1 Listas de control de acceso (ACL)

Leccin 13: CONSIDERACIONES DE SEGURIDAD EN WEB SERVICES

13.1 Exposicin de datos

Leccin 14: VALIDACION DE ENTRADAS

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD

Leccin 15: SQL INJECTION

UNIDAD 2: ANALISIS Y DISEO SEGURO DE APLICACIONES WEB

Leccin 16: SECUENCIAS DE COMANDOS EN SITIOS CRUZADOS (XSS)

16.1 Tipos de vulnerabilidades XSS

Leccin 17: PERDIDA DE AUTENTICACION Y GESTION DE SESIONES

Leccin 18: REFERENCIA DIRECTA INSEGURA A OBJETOS

Leccin 19: ALMACENAMIENTO CRIPTOGRAFICO INSEGURO

Leccin 20: RESTRICCIONES DE ACCESO A URL

CAPITULO 5: CICLO DE VIDA DE DESARROLLO SEGURO DEL SOFTWARE (SDLC)

Leccin 22: Fases de SDLC

22.1 Seguridad en la fase de anlisis

Leccin 23: SDLC-IT

Leccin 24: APLICACIN DE SDLC

Leccin 25: OTRAS VULNERABILIDADES QUE AFECTAN SDLC

25.1 Vulnerabilidades de la capa de transporte

CAPITULO 6: ATAQUES DE DENEGACION DE SERVICIO (DDoS) APLICACIONES

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD

26.1 Denegacin De Servicio Distribuido: DDoS

Leccin 27: FASES PREVIAS A LA REALIZACION DEL ATAQUE

27.1 Actividades previas al ataque (DoS)

Leccin 28: FINGERPRINTING

28.1 Transmisin en el protocolo de control

Leccin 29: TIPOS DE ATAQUES

29.1 ATAQUE TCP/SYN Flooding:

Leccin 30: HERRAMIENTAS QUE AYUDAN A PREVENIR ATAQUES DoS

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD

Tabla 1: Cdigos de estado en HTTP

Figura 1: Niveles superiores de OSI. Origen de vulnerabilidades en sitios