TALLER 1 SEGURIDAD INFORMÁTICA

SEGURIDAD EN APLICACIONES WEB

1. ¿En qué consiste el Hacking Ético?

Es una metodología que consiste en la aplicación de los conocimientos y técnicas
de un hacker con fines defensivos y, prioritariamente, de manera legal, cuyo
objetivo es detectar vulnerabilidades de un sistema. Así mismo, un Hacker Ético
es un profesional de la seguridad informática que realiza una serie de pruebas de
seguridad a la infraestructura de comunicación de una organización usando
técnicas​ ​hacking.
El Hacking Ético consiste en realizar una serie de instrucciones (autorizadas) para
conocer el nivel de seguridad actual, evaluarlo y poder dar un reporte sobre las
causas, consecuencias y soluciones a las vulnerabilidades detectadas.
El Hacker Ético debe tener un perfil de habilidades no solo para identificar la
vulnerabilidades, también para presentar soluciones eficientes, que resuelven en
lo posible, las fallas de seguridad. El perfil de habilidades básicas de un Hacker
Ético es:
⎯ Conocimientos avanzados en programación.
⎯ Manejo y administración de diversas plataformas de Sistemas Operativos.
⎯ Conocimientos en redes (Protocolo de comunicación y configuración).
⎯ Instalación, mantenimiento y configuración de hardware.
⎯ Fiable para manejar información sensible de una empresa.

2. ¿Qué es y cómo Funciona el protocolo HTTP?

"Hypertext Transfer Protocol", es el nombre de un protocolo el cual nos permite
realizar una petición de datos y recursos, como pueden ser documentos HTML. Es
la base de cualquier intercambio de datos en la Web, y un protocolo de estructura
cliente-servidor, esto quiere decir que una petición de datos es iniciada por el
elemento que recibirá los datos (el cliente), normalmente un navegador Web. Así,
una página web completa resulta de la unión de distintos sub-documentos
recibidos, como, por ejemplo: un documento que especifique el estilo de
maquetación de la página web (CSS), el texto, las imágenes, vídeos, scripts, entre
otros.
Cuando el cliente quiere comunicarse con el servidor, tanto si es directamente con
él, o a través de un proxy intermedio, realiza los siguientes pasos:
1. Abre una conexión TCP: la conexión TCP se usará para hacer una petición, o
varias, y recibir la respuesta. El cliente puede abrir una conexión nueva, reusar
una existente, o abrir varias a la vez hacia el servidor.
2. Hacer una petición HTTP: Los mensajes HTTP (previos a HTTP/2) son legibles en
texto plano. A partir de la versión del protocolo HTTP/2, los mensajes se
encapsulan en franjas, haciendo que no sean directamente interpretables, aunque
el principio de operación es el mismo

3. Leer la respuesta enviada por el servidor.

4. Cierre o rehúso de la conexión para futuras conexiones.

3. ¿Qué es y cómo Funciona el protocolo TSL?

Transport Layer Security (TLS) (en español seguridad de la capa de transporte), es un
protocolo de cifrado que se utiliza para la transmisión de datos en Internet. El protocolo
describe un estándar general que se puede implementar en entornos específicos.
Transport Layer Security es uno de los protocolos de cifrado más utilizados. Además de
transportar datos entre un navegador y un servidor web, como es el caso de HTTPS, TLS
también se utiliza para el envío de correos electrónicos, conexiones FTP y VPN, así como
para mensajería instantánea y voz sobre IP. TLS se utiliza principalmente en áreas en las
que se trata de datos sensibles, como la banca online, el almacenamiento de datos de
clientes, las contraseñas y las comunicaciones digitales. El objetivo es asegurar la
transmisión segura de los datos y asegurar el más alto grado de integridad de los usuarios
de la comunicación.

TLS ​gestiona​ esquemáticamente cada transmisión de datos como comunicación entre el

emisor y el receptor, por ejemplo, entre el cliente y el servidor. El protocolo TLS se utiliza
en un punto específico de la arquitectura de la tecnología de la información, que también
se denomina modelo OSI o modelo de referencia TCP/IP. TLS opera en la capa de
transporte, donde se gestionan los flujos de datos de la comunicación digital. Esta capa
forma parte del sistema de transporte, que se separa de la capa de aplicación y, por tanto,
del usuario. Esto significa que los usuarios no tienen que preocuparse por las
características del sistema que se utiliza para la transmisión de datos, y también pueden
utilizar el sistema sin el conocimiento de la red.

La capa de transporte permite el cifrado de extremo a extremo, por lo que la capa de

aplicación es siempre una implementación del protocolo estándar superior TLS. HTTPS
es, por ejemplo, una aplicación de TLS. Lo mismo se aplica a POP3S, SMTPS e IMAPS,
todos los cuales permiten una transmisión segura de correo electrónico. Para otras
aplicaciones, como chats, conexiones VPN o transferencia de datos FTP, existen
protocolos adaptados que hacen que TLS sea aplicable en la práctica. TLS es un
concepto básico que puede tener muchas aplicaciones o instancias diferentes.

4. ¿En qué consiste la autenticación web?

Aprender la forma de autenticar usuarios es una parte básica del diseño web. La
autenticación permite que verifiques la identidad de un miembro y determines qué nivel de
acceso tiene en el sitio, como por ejemplo si es un miembro o un administrador. Hay
diferentes tipos de autenticación web disponibles. El elegido depende en gran medida de
qué tan confidencial es la información en el sitio web y cuánto control deseas ejercer
sobre los miembros que pueden acceder a ella.

Autenticación básica HTTP

HTTP básica es el tipo más simple de autenticación web disponible. Esta forma de
autenticación solicita al usuario que inicie sesión con su nombre de usuario y contraseña.
Sin embargo, la información se transmite utilizando codificación Base64. Esto significa
que la información enviada no es cifrada ni segura. En teoría, la información podría ser
interceptada por un tercero.

Autenticación digest HTTP

Los protocolos de autenticación Digest funcionan de manera similar a la autenticación
básica. El servidor solicita la información de identificación, que es suministrada por el
usuario en la forma de un nombre de usuario y una contraseña. El servidor, a
continuación, compara las credenciales con lo que está en archivo, y siempre y cuando
coincidan, concederá el acceso. Es un escenario de inicio de sesión sencillo.

La diferencia primaria con la autenticación de HTTP con protocolo Digest es que la

conexión se realiza de una manera segura. Esto es debido a que las contraseñas son
"digeridas" y almacenadas en la base de datos de usuario en un formulario cifrado. Nadie,
ni siquiera el administrador, puede abrir la base de datos y saber la contraseña al mirar la
secuencia cifrada. De esta manera, la integridad de la contraseña es mucho más segura,
ya que sólo puede ser leída por el servidor web.

Autenticación de cliente HTTPS

HTTPS se logra cuando el HTTP estándar es combinado con un Socket Layer Secure
(SSL). Todo lo contenido dentro del SSL opera en un circuito cerrado, sin ninguna
interferencia exterior. Esto permite que el navegador web verifique la legitimidad de cada
página que se encuentra en el sitio web mediante la lectura de el Certificado de Clave
Pública (PKC o Criptografía asimétrica) del secure socket, y comparándolo con el archivo
guardado del certificado de seguridad del sitio.

HTTPS es ampliamente utilizado en sitios web de ecommerce o en cualquier lugar en el

que se accede a información confidencial. Esta forma de autenticación proporciona un alto
estándar de seguridad, porque cada operación de intercambio de información entre el
servidor y el navegador está cifrada y se envía a través de un canal seguro.

Autenticación basada en formularios

La autenticación basada en formularios se utiliza para recoger información de los
visitantes que no tienen una necesidad elevada de seguridad. Las encuestas, los
formularios de contacto y las páginas de registro se hacen a menudo mediante la
autenticación basada en formulario. El papel primario de este protocolo de autenticación
es ver qué campos del formulario se identifican como requeridos, a continuación,
asegurarse de que esos elementos se han llenado correctamente antes de pasar el
formulario completo al destinatario.

¿Qué diferencia existe entre los esquemas STRIDE y DREAD?

El esquema STRIDE, Spoofing identity, Tampering with data,
Repudiation, Information disclosure, Denial of service, Elevation of
privilege, es un método de clasificación de amenazas. Según el
método STRIDE el sistema se descompone en componentes y se
analiza cada componente para comprobar qué amenazas le pueden
afectar. Cuando se detectan amenazas se proponen acciones para
mitigarlas. El modelo utilizado está basado en patrones, con el que se
puede identificar problemas repetibles y organizarlos en categorías.
Estas categorías facilitan la descomposición de la aplicación para un
análisis mejor. La metodología recomienda la reutilización de
información y comunicación entre las partes.
A continuación se detallan las partes de STRIDE. Comenzamos por la
suplantación de identidad. Se debe prestar atención a las situaciones
en las que se pueda llevar a cabo un robo de sesión, validaciones
erróneas, sistemas de autenticación, etcétera.
La segunda propiedad es la manipulación de datos, la cual se debe
tener en cuenta que durante la implementación se mejora tiempos de
respuesta contra seguridad en la manipulación. El filtrado y validación
de datos, tanto enviados como recibidos, de una aplicación se deben
tener muy en cuenta ya que son procesos propensos a reclutar
amenazas. Un ejemplo serían los típicos ataques web, como XSS, con
el que una no validación correcta por parte del servidor hace que la
amenaza se convierta en realidad.
La tercera propiedad es el repudio. Las aplicaciones deben intentar
garantizar el no repudio de los usuarios, por lo que un sistema de
seguimiento de acciones realizadas es útil para cumplir con esta
premisa. Las aplicaciones y sus características presentan diferentes
riesgos, por lo que las medidas de registro de actividades de los
usuarios también serán diferentes. En función del contexto de la
aplicación se necesitará un sistema de seguimiento más rígido que en
otras.
La cuarta propiedad es la revelación de información. Cualquier tipo de
información que ayude a un atacante indicando el funcionamiento de la
aplicación es un riesgo de este tipo.
La quinta propiedad es denegación de servicio. Algunas
funcionalidades de las aplicaciones dificultan la optimización de los
recursos, para estos casos se debe realizar un uso racional y evitar
que la aplicación pueda caer en una denegación de servicio. Se deben
estudiar estos casos para evitar estas amenazas.
La sexta propiedad es la elevación de privilegios. La aplicación puede
tener diferentes niveles de privilegios, en función de distintos roles o
tipos de usuarios. Hay que vigilar todas las acciones que conlleven el
uso de privilegios y deben ser filtradas a través de una capa de
autorización. La validación de privilegios debe ser robusta e impedir la
escalada de privilegios.
Mientras que ​DREAD ​entra cuando se ha identificado la lista de
amenazas se debe puntuar en función del riesgo que éstas suponen a
la aplicación. Con esto se consigue priorizar las actuaciones a llevar a
cabo con el objetivo de mitigar el riesgo.
La fórmula del riesgo es R = probabilidad de ocurrencia * Daño
potencial [ * valor]. En este caso el valor es opcional. Al menos
debemos tomar R como la probabilidad de que la amenaza ocurra y el
daño que ésta proporciona al sistema. Lo normal es utilizar una escala
del 1 al 10 para cuantificar la probabilidad, 1 es poco probable y 10 es
altamente probable. Por otro lado el daño se valora igual. Con esto
Microsoft clasifica las amenazas en 3 categorías, alta, media y baja,
donde los valores van del 1 al 100 según la fórmula.
¿Qué tipo de ataques existe en la Web y en qué consisten?
El proyecto abierto de seguridad en aplicaciones web (OWASP por sus
siglas en inglés) emite el top 10 de las vulnerabilidades más graves de
aplicaciones web. El objetivo principal es educar a las organizaciones
que hacen uso de las TICs sobre las consecuencias de las
vulnerabilidades de seguridad en aplicaciones web más importantes.
Los principales 5 ataques son:
Inyección:​ Las fallas de inyección, tales como SQL, OS, LDAP,
ocurren cuando datos no confidenciales son enviados a un intérprete
como parte de un comando o consulta, tratando de engañar al
intérprete en ejecutar comandos no intencionados o acceder a datos
no autorizados.
Secuencia de Comandos en Sitios Cruzados:​ ​Las gallas XSS
ocurren cada vez que una aplicación toma datos no confidenciales y
los envía al navegador web sin una validación y codificación
apropiada. XSS permite a los atacantes ejecutar secuencia de
comandos en el navegador de la víctima los cuales pueden secuestrar
las sesiones de usuario, destruir sitios web, dirigir al usuario hacia un
sitio malicioso.
Configuración de Seguridad Incorrecta:​ Una buena seguridad
requiere tener definidas e implementada una configuración segura
para la aplicación, marcos de trabajo, servidores de aplicación,
servidores web, base de datos y plataformas. Todas estas
configuraciones deben ser definidas, implementadas y mantenidas ya
que por lo general no son seguras por defecto.
Exposición de datos sensibles:​ ​Muchas aplicaciones web no
protegen adecuadamente datos sensibles tales como números de
tarjetas de crédito o credenciales de autenticación. Los datos sensibles
requieren de métodos de protección adicionales tales como el cifrado
de datos, así como también de precauciones especiales en un
intercambio de datos con el navegador.
Falsificación de Petición en Sitios Cruzados (CSRF):​ Un ataque
CSRF obliga al navegador de una víctima autenticada a enviar una
petición HTTP falsificado, incluyendo la sesión del usuario y cualquier
otra información de autenticación incluida automáticamente, a una
aplicación web vulnerable.
DVWA
A continuación se muestra paso a paso la configuración de la herramienta
de pruebas DVWA.
El sistema operativo usado para la práctica es ​Kali Linux:

1. Se crea un directorio llamado ​dvwa​ en /var/www/html luego se

descomprime ​DVWA-master.zip​ logrando tener la siguiente
estructura:

2. Debe crearse una base de datos llamada ​dvwa ​introduciendo los

siguientes comandos:
● /etc/init.d/mysql start
● mysql - h localhost - u root -p
● create database dvwa;
Obteniendo así:
3​. Se debe iniciar los servicios de apache.

4​.Se ingresa en el navegador de preferencia la siguiente

dirección ​http://localhost/dvwa
Se deben agregar y modificar complementos para poder ser
redireccionado a la vista del login y así poder acceder al panel
de administración de la herramienta.
Credenciales
Usuario : ​admin
Contraseña : ​password
Probando las opciones.
Vulnerability: Brute Force

En criptografía, se denomina ataque de fuerza bruta a la forma de

recuperar una clave probando todas las combinaciones posibles hasta
encontrar aquella que permite el acceso.
Dos aspectos han de ser tenidos en cuenta a la hora de realizar un
ataque por fuerza bruta:
● El alfabeto utilizado para obtener todas las posibles
combinaciones.
● La longitud de palabra (usuario/contraseña).
Este tipo de ataques, por tanto, suelen ser combinados con otro tipo
de ataque: los ataques de diccionario, consistentes en probar
combinaciones de palabras o cadenas de caracteres que habrán sido
seleccionadas previamente. Como su propio nombre indica, se basan
en la premisa de la elección como contraseñas de palabras del idioma
del usuario.
Práctica
Paso 1.
Se hará uso de la herramienta ​Burn Suite Community Edition propia
del sistema ​Kali Linux.
Paso 2.
Se configura el navegador web para que se conecte a través de un
proxy HTTP ​direccion​ 127.0.0.1 y el puerto ​8080.
Paso 3.
Se inicia la interceptación en la herramienta ​Burn Suite Community
Edition ​en el tap ​proxy ​y tap ​intercept​ en la opción ​intercept on.

Paso 4.
Establecer el diccionario que será recorrido por la herramienta para
este caso se situó en ​/var/www/html/dvwa/diccionario.
Paso 5.
Realizar la petición desde el formulario ubicado en:
http://localhost/dvwa/vulnerabilities/brute/​ y visualizar la petición GET
en:
Paso 6.
Ejecutar en la terminal el siguiente comando:

hydra -l admin /var/www/html/dvwa/diccionario 127.0.0.1 http-get-form

“/dvwa/vulnerabilities/brute/?username=admin&password=1&Login=Login:username^ÛSER^&password^PASS^&Login=Logi
n:Username and/or password incorrect.:H=Cookie: security=Low: PHPSESSID=8b923k825c2lippr37nh2tsb79” -v
Lo anterior es una muestra de cómo vulnerar la seguridad haciendo
uso de la fuerza bruta en este caso se consiguió la contraseña
después de 5 intentos lo que permitió el ingreso al panel de
administración.
Command Injection
Esta vulnerabilidad permite ejecutar comandos de consola desde la
web, pudiendo así ver, modificar y eliminar archivos y directorios del
servidor. Las posibilidades de este ataque son infinitas, siendo su
única limitación el usuario utilizado en la ejecución de los comandos
(generalmente “apache”), por lo que para realizar ciertas acciones se
dependería de los permisos que éste tenga.
Cross Site Request Forgery (CSRF)
CSRF (del inglés Cross-site request forgery o falsificación de petición
en sitios cruzados) es un tipo de exploit en el que comandos no
autorizados son transmitidos por un usuario en el cual el sitio web
confía.
Esta vulnerabilidad es conocida también por otros nombres como
XSRF, enlace hostil, ataque de un click, cabalgamiento de sesión y
ataque automático.
Las vulnerabilidades CSRF se producen cuando un sitio web permite a
un usuario autenticado realizar acciones consideradas como
“sensibles” sin comprobar que realmente es el usuario quien las está
invocando conscientemente. En su lugar, la aplicación simplemente
comprueba que la petición proviene del navegador autorizado de dicho
usuario.
De este modo, y dado que los navegadores ejecutan simultáneamente
código enviado por múltiples sitios web, existe el riesgo de que un sitio
web (sin el conocimiento del usuario) envíe una solicitud a un segundo
sitio web y éste interprete que la acción ha sido autorizada por el
propio usuario.

File Inclusion
Este tipo de vulnerabilidad está referida a la ejecución en el servidor web de
ficheros locales o externos (al propio servidor) diferentes a los esperados. Se
diferencian por tanto dos tipos de ataques diferentes:
LFI ​o ​Local File Inclusion ​, y ​RFI​ o ​Remote File Inclusion.
Lo primero es comprobar si la página es vulnerable ante este tipo de ataque
cambiando en la URL el fichero que se incluirá en la página web mediante la
función include() reemplazando el valor del parámetro page por una barra
invertida (/).

Lo anterior nos comprueba que la página es vulnerable ante este tipo

de ataque.
Lo siguiente es intentar visualizar un archivo cualquiera del sistema
como lo es /etc/passwd que es el encargado de almacenar los
usuarios en nuestro sistema operativo.
Otro caso es incluir una página web como
http://localhost/dvwa/vulnerabilities/fi/?page=http://www.google.com.co

SQL Injection
Como su propio nombre indica, esta vulnerabilidad consiste en
inyectar código SQL invasor dentro del código SQL programado
con el objetivo de alterar la funcionalidad del programa. Este tipo
de intrusión normalmente es de carácter malicioso y, por tanto,
un problema de seguridad informática. Un programa o página
web que no haya sido validado de forma correcta podrá ser
vulnerable y la seguridad del sistema(base de datos) no podrá
ser asegurada​.
Para probar la inyección ​1’ OR 1=1--’ ​obteniendo el siguiente
resultado:

Para saber la versión de mysql ​‘union all select 1,@@VERSION-- ‘

SQL Injection (Blind)

Este tipo de ataque es similar al SQL Injection que se acaba de estudiar,
con la diferencia que la página web no devuelve ningún mensaje de
error al producirse resultados incorrectos tras una consulta a la base de
datos. Esta falta de muestreo de resultados se produce por el tratamiento
total de los códigos de error, y la imposibilidad de modificar, a priori,
información alguna de la base de datos, teniendo respuesta únicamente
en caso de que la consulta sea correcta.
La falta de mensajes de error no quiere decir que no sea vulnerable una
página web. ¿Cómo se sabe que una web es vulnerable a SQL Injection
Blind? Pues basta con probar un poco más y siempre que la inyección
esté bien ejecutada se mostrará el contenido esperado.
Para probar la inyección(Blind) se intentará conocer conocer las
tablas existentes y también información de esquema de la base
de datos ​DVWA, ​para la práctica se hará uso de las
herramientas ​sqlmap ​y ​Burn Suite.
Lo primera será enviar una petición en este caso ​GET ​y capturar
la información con Burn Suite, todo esto con un proxy
previamente configurado.