Pruebas de seguridad: guía rápida

Las pruebas de seguridad son muy importantes para mantener el sistema protegido de actividades maliciosas en la web.

¿Qué son las pruebas de seguridad?

Las pruebas de seguridad son una técnica de prueba para determinar si un sistema de información protege los datos y mantiene la funcionalidad según lo previsto. Las pruebas de seguridad no garantizan la seguridad completa del sistema, pero es importante incluir las pruebas de seguridad como parte del proceso de prueba.

Las pruebas de seguridad toman las siguientes seis medidas para proporcionar un entorno seguro:

• Confidentiality - Protege contra la divulgación de información a destinatarios no deseados.

• Integrity - Permite transferir la información deseada precisa y correcta de los remitentes a los destinatarios previstos.

• Authentication - Verifica y confirma la identidad del usuario.

• Authorization - Especifica derechos de acceso a los usuarios y recursos.

• Availability - Garantiza la disponibilidad de la información sobre los requisitos.

• Non-repudiation - Asegura que no haya negación del remitente o del receptor por haber enviado o recibido el mensaje.

Ejemplo

Detectar una falla de seguridad en una aplicación basada en web implica pasos complejos y pensamiento creativo. A veces, una simple prueba puede exponer el riesgo de seguridad más grave. Puede probar esta prueba muy básica en cualquier aplicación web:

• Inicie sesión en la aplicación web con credenciales válidas.

• Cierre la sesión de la aplicación web.

• Haga clic en el botón ATRÁS del navegador.

• Verifique si se le pide que inicie sesión nuevamente o si puede volver a la página de inicio de sesión nuevamente.

Las pruebas de seguridad pueden verse como un ataque controlado al sistema, que descubre fallas de seguridad de una manera realista. Su objetivo es evaluar el estado actual de un sistema de TI. También se conoce comopenetration test o más popularmente como ethical hacking.

La prueba de penetración se realiza en fases y aquí, en este capítulo, discutiremos el proceso completo. Se debe realizar la documentación adecuada en cada fase para que todos los pasos necesarios para reproducir el ataque estén disponibles fácilmente. La documentación también sirve como base para el informe detallado que reciben los clientes al final de una prueba de penetración.

Prueba de penetración: flujo de trabajo

La prueba de penetración incluye cuatro fases principales:

• Impresión de pie
• Scanning
• Enumeration
• Exploitation

Estos cuatro pasos se repiten varias veces, lo que va de la mano con el SDLC normal.

El software malicioso (malware) es cualquier software que otorga un control parcial o total del sistema al atacante / creador de malware.

Malwares

A continuación se enumeran varias formas de malware:

• Virus- Un virus es un programa que crea copias de sí mismo e inserta estas copias en otros programas de computadora, archivos de datos o en el sector de arranque del disco duro. Tras la replicación exitosa, los virus causan actividad dañina en los hosts infectados, como robar espacio en el disco duro o tiempo de CPU.

• Worm - Un gusano es un tipo de malware que deja una copia de sí mismo en la memoria de cada ordenador a su paso.

• Trojan - El troyano es un tipo de malware que no se replica automáticamente y que contiene código malicioso que, tras su ejecución, provoca la pérdida o el robo de datos o posibles daños al sistema.

• Adware- El adware, también conocido como freeware o pitchware, es un software informático gratuito que contiene anuncios comerciales de juegos, barras de herramientas de escritorio y utilidades. Es una aplicación basada en web y recopila datos del navegador web para orientar anuncios, especialmente ventanas emergentes.

• Spyware- El software espía es un software de infiltración que supervisa de forma anónima a los usuarios, lo que permite a un pirata informático obtener información confidencial de la computadora del usuario. El software espía explota a los usuarios y las vulnerabilidades de las aplicaciones que a menudo se adjuntan a las descargas gratuitas de software en línea oa los enlaces en los que los usuarios hacen clic.

• Rootkit - Un rootkit es un software utilizado por un pirata informático para obtener acceso de nivel de administrador a una computadora / red que se instala mediante una contraseña robada o mediante la explotación de una vulnerabilidad del sistema sin el conocimiento de la víctima.

Medidas preventivas

Se pueden tomar las siguientes medidas para evitar la presencia de malware en un sistema:

• Asegúrese de que el sistema operativo y las aplicaciones estén actualizadas con parches / actualizaciones.

• Nunca abra correos electrónicos extraños, especialmente aquellos con archivos adjuntos.

• Cuando descargue de Internet, siempre verifique lo que instala. No haga clic simplemente en Aceptar para cerrar las ventanas emergentes. Verifique el editor antes de instalar la aplicación.

• Instale software antivirus.

• Asegúrese de escanear y actualizar los programas antivirus con regularidad.

• Instale el cortafuegos.

• Habilite y utilice siempre las funciones de seguridad proporcionadas por los navegadores y las aplicaciones.

Software anti-malware

El siguiente software ayuda a eliminar los malwares de un sistema:

• Microsoft Security Essentials
• Microsoft Windows Defender
• AVG Internet Security
• Spybot - Buscar y destruir
• Avast! Home Edition para uso personal
• Panda Internet Security
• MacScan para Mac OS y Mac OS X

Comprender el protocolo es muy importante para comprender bien las pruebas de seguridad. Podrá apreciar la importancia del protocolo cuando interceptamos los paquetes de datos entre el servidor web y el cliente.

Protocolo HTTP

El Protocolo de transferencia de hipertexto (HTTP) es un protocolo a nivel de aplicación para sistemas de información hipermedia distribuidos y colaborativos. Ésta es la base para la comunicación de datos para la World Wide Web desde 1990. HTTP es un protocolo genérico y sin estado que se puede utilizar para otros fines, además de utilizar la extensión de sus métodos de solicitud, códigos de error y encabezados.

Básicamente, HTTP es un protocolo de comunicación basado en TCP / IP, que se utiliza para entregar datos como archivos HTML, archivos de imagen, resultados de consultas, etc. a través de la web. Proporciona una forma estandarizada para que las computadoras se comuniquen entre sí. La especificación HTTP especifica cómo se envían los datos solicitados por los clientes al servidor y cómo los servidores responden a estas solicitudes.

Caracteristicas basicas

Existen las siguientes tres características básicas que hacen de HTTP un protocolo simple pero poderoso:

• HTTP is connectionless- El cliente HTTP, es decir, el navegador inicia una solicitud HTTP. Después de realizar una solicitud, el cliente se desconecta del servidor y espera una respuesta. El servidor procesa la solicitud y restablece la conexión con el cliente para devolver la respuesta.

• HTTP is media independent- Cualquier tipo de datos se pueden enviar por HTTP siempre que tanto el cliente como el servidor sepan cómo manejar el contenido de los datos. Esto es necesario para que el cliente y el servidor especifiquen el tipo de contenido utilizando el tipo MIME apropiado.

• HTTP is stateless- HTTP no tiene conexión y esto es un resultado directo de que HTTP es un protocolo sin estado. El servidor y el cliente se conocen entre sí solo durante una solicitud actual. Después, ambos se olvidan el uno del otro. Debido a esta naturaleza del protocolo, ni el cliente ni el navegador pueden retener información entre diferentes solicitudes en las páginas web.

HTTP / 1.0 usa una nueva conexión para cada intercambio de solicitud / respuesta, mientras que la conexión HTTP / 1.1 se puede usar para uno o más intercambios de solicitud / respuesta.

Arquitectura

El siguiente diagrama muestra una arquitectura muy básica de una aplicación web y describe dónde reside HTTP:

El protocolo HTTP es un protocolo de solicitud / respuesta basado en la arquitectura cliente / servidor donde el navegador web, los robots y los motores de búsqueda, etc., actúan como clientes HTTP y el servidor web actúa como servidor.

• Client - El cliente HTTP envía una solicitud al servidor en forma de método de solicitud, URI y versión de protocolo, seguida de un mensaje similar a MIME que contiene modificadores de solicitud, información del cliente y posible contenido del cuerpo a través de una conexión TCP / IP.

• Server - El servidor HTTP responde con una línea de estado, que incluye la versión de protocolo del mensaje y un código de éxito o error, seguido de un mensaje similar a MIME que contiene información del servidor, metainformación de la entidad y posible contenido del cuerpo de la entidad.

HTTP - Desventajas

• HTTP no es un protocolo completamente seguro.

• HTTP usa el puerto 80 como puerto predeterminado para la comunicación.

• HTTP opera en la capa de aplicación. Necesita crear múltiples conexiones para la transferencia de datos, lo que aumenta los gastos generales de administración.

• No se requieren certificados digitales / cifrados para usar HTTP.

Detalles del protocolo Http

Para comprender el protocolo HTTP en profundidad, haga clic en cada uno de los enlaces siguientes.

• HTTP Parameters

• HTTP Messages

• HTTP Requests

• HTTP Responses

• HTTP Methods

• HTTP Status Codes

• HTTP Header Fields

• HTTP Security

HTTPS (Hypertext Transfer Protocol over Secure Socket Layer) o HTTP sobre SSL es un protocolo web desarrollado por Netscape. No es un protocolo, sino simplemente el resultado de superponer el HTTP sobre SSL / TLS (Secure Socket Layer / Transport Layer Security).

En resumen, HTTPS = HTTP + SSL

¿Cuándo se requiere HTTPS?

Cuando navegamos, normalmente enviamos y recibimos información mediante el protocolo HTTP. Entonces, esto lleva a cualquiera a escuchar a escondidas la conversación entre nuestra computadora y el servidor web. Muchas veces necesitamos intercambiar información confidencial que debe protegerse y evitar el acceso no autorizado.

Protocolo Https utilizado en los siguientes escenarios:

• Sitios web bancarios
• Pasarela de pago
• Sitios web de compras
• Todas las páginas de inicio de sesión
• Aplicaciones de correo electrónico

Trabajo básico de HTTPS

• Se requieren claves públicas y certificados firmados para el servidor en el protocolo HTTPS.

• Solicitudes de clientes para la página https: //

• Cuando se utiliza una conexión https, el servidor responde a la conexión inicial ofreciendo una lista de métodos de cifrado que admite el servidor web.

• En respuesta, el cliente selecciona un método de conexión y el cliente y el servidor intercambian certificados para autenticar sus identidades.

• Una vez hecho esto, tanto el servidor web como el cliente intercambian la información encriptada después de asegurarse de que ambos estén usando la misma clave y que la conexión esté cerrada.

• Para alojar conexiones https, un servidor debe tener un certificado de clave pública, que incorpora información de clave con una verificación de la identidad del propietario de la clave.

• Casi todos los certificados son verificados por un tercero para que los clientes tengan la seguridad de que la clave está siempre segura.

¿Qué es codificar y decodificar?

La codificación es el proceso de poner una secuencia de caracteres como letras, números y otros caracteres especiales en un formato especializado para una transmisión eficiente.

La decodificación es el proceso de convertir un formato codificado en la secuencia original de caracteres. Es completamente diferente del cifrado que solemos malinterpretar.

La codificación y decodificación se utilizan en las comunicaciones y el almacenamiento de datos. La codificación NO debe usarse para transportar información confidencial.

Codificación de URL

Las URL solo se pueden enviar a través de Internet utilizando el conjunto de caracteres ASCII y hay casos en que la URL contiene caracteres especiales además de caracteres ASCII, es necesario codificarla. Las URL no contienen espacios y se reemplazan con un signo más (+) o con% 20.

Codificación ASCII

El navegador (del lado del cliente) codificará la entrada de acuerdo con el juego de caracteres utilizado en la página web y el juego de caracteres predeterminado en HTML5 es UTF-8.

La siguiente tabla muestra el símbolo ASCII del carácter y su símbolo igual y finalmente su reemplazo que se puede usar en la URL antes de pasarlo al servidor:

ASCII	Símbolo	Reemplazo
<32		Codifique con% xx donde xx es la representación hexadecimal del carácter.
32	espacio	+ o% 20
33	!	% 21
34	"	% 22
35	#	% 23
36	PS	% 24
37	%	% 25
38	Y	% 26
39	'	% 27
40	(	% 28
41	)	% 29
42	*	*
43	+	% 2B
44	,	% 2C
45	-	-
46	.	.
47	/	% 2F
48	0	0
49	1	1
50	2	2
51	3	3
52	4	4
53	5	5
54	6	6
55	7	7
56	8	8
57	9	9
58	:	% 3A
59	;	% 3B
60	>	% 3C
61	=	% 3D
62	>	% 3E
63	?	% 3F
64	@	% 40
sesenta y cinco	UN	UN
66	segundo	segundo
67	C	C
68	re	re
69	mi	mi
70	F	F
71	GRAMO	GRAMO
72	H	H
73	yo	yo
74	J	J
75	K	K
76	L	L
77	METRO	METRO
78	norte	norte
79	O	O
80	PAGS	PAGS
81	Q	Q
82	R	R
83	S	S
84	T	T
85	U	U
86	V	V
87	W	W
88	X	X
89	Y	Y
90	Z	Z
91	[	% 5B
92	\	% 5C
93	]	% 5D
94	^	% 5E
95	_	_
96	'	% 60
97	un	un
98	segundo	segundo
99	C	C
100	re	re
101	mi	mi
102	F	F
103	gramo	gramo
104	h	h
105	yo	yo
106	j	j
107	k	k
108	l	l
109	metro	metro
110	norte	norte
111	o	o
112	pags	pags
113	q	q
114	r	r
115	s	s
116	t	t
117	tu	tu
118	v	v
119	w	w
120	X	X
121	y	y
122	z	z
123	{	% 7B
124	|	% 7C
125	}	% 7D
126	~	% 7E
127		% 7F
> 127		Codifique con% xx donde xx es la representación hexadecimal del carácter

¿Qué es la criptografía?

La criptografía es la ciencia para cifrar y descifrar datos que permite a los usuarios almacenar información confidencial o transmitirla a través de redes inseguras para que solo pueda ser leída por el destinatario previsto.

Los datos que se pueden leer y comprender sin ninguna medida especial se denominan plaintext, mientras que el método de disfrazar el texto llano para ocultar su sustancia se llama encryption.

El texto sin formato cifrado se conoce como texto cifrado y el proceso de revertir los datos cifrados a texto sin formato se conoce como decryption.

• La ciencia de analizar y romper la comunicación segura se conoce como criptoanálisis. Las personas que realizan lo mismo también se conocen como atacantes.

• La criptografía puede ser fuerte o débil y la fortaleza se mide por el tiempo y los recursos necesarios para recuperar el texto sin formato real.

• Por lo tanto, se requiere una herramienta de decodificación adecuada para descifrar los mensajes cifrados fuertes.

• Hay algunas técnicas criptográficas disponibles con las que incluso mil millones de computadoras haciendo mil millones de verificaciones por segundo, no es posible descifrar el texto.

• A medida que la potencia informática aumenta día a día, uno tiene que hacer que los algoritmos de cifrado sean muy fuertes para proteger los datos y la información crítica de los atacantes.

¿Cómo funciona el cifrado?

Un algoritmo criptográfico funciona en combinación con una clave (puede ser una palabra, un número o una frase) para encriptar el texto sin formato y el mismo texto sin formato encripta a diferentes textos cifrados con diferentes claves.

Por lo tanto, los datos cifrados dependen completamente de un par de parámetros, como la fuerza del algoritmo criptográfico y el secreto de la clave.

Técnicas de criptografía

Symmetric Encryption- La criptografía convencional, también conocida como cifrado convencional, es la técnica en la que solo se utiliza una clave tanto para el cifrado como para el descifrado. Por ejemplo, DES, algoritmos Triple DES, MARS de IBM, RC2, RC4, RC5, RC6.

Asymmetric Encryption- Es la criptografía de clave pública que utiliza un par de claves para el cifrado: una clave pública para cifrar los datos y una clave privada para el descifrado. La clave pública se publica para las personas mientras se mantiene en secreto la clave privada. Por ejemplo, RSA, Algoritmo de firma digital (DSA), Elgamal.

Hashing- Hashing es un cifrado de UNA VÍA, que crea una salida codificada que no se puede revertir o al menos no se puede revertir fácilmente. Por ejemplo, algoritmo MD5. Se utiliza para crear Certificados Digitales, Firmas Digitales, Almacenamiento de contraseñas, Verificación de comunicaciones, etc.

La Política del mismo origen (SOP) es un concepto importante en el modelo de seguridad de aplicaciones web.

¿Qué es la política de mismo origen?

Según esta política, permite la ejecución de scripts en páginas que se originan en el mismo sitio, lo que puede ser una combinación de lo siguiente:

• Domain
• Protocol
• Port

Ejemplo

La razón de este comportamiento es la seguridad. Si tiene try.com en una ventana y gmail.com en otra ventana, NO quiere que un script de try.com acceda o modifique el contenido de gmail.com o ejecute acciones en el contexto de gmail en su nombre.

A continuación se muestran páginas web del mismo origen. Como se explicó anteriormente, el mismo origen toma en consideración dominio / protocolo / puerto.

• http://website.com
• http://website.com/
• http://website.com/my/contact.html

A continuación se muestran páginas web de un origen diferente.

• http://www.site.co.uk (otro dominio)
• http://site.org (otro dominio)
• https://site.com (otro protocolo)
• http://site.com:8080 (otro puerto)

Excepciones a la política del mismo origen para IE

Internet Explorer tiene dos excepciones importantes a SOP.

• El primero está relacionado con las 'Zonas de confianza'. Si ambos dominios están en una zona de alta confianza, la política del mismo origen no se aplica por completo.

• La segunda excepción en IE está relacionada con el puerto. IE no incluye el puerto en la política del mismo origen, por lo tanto, http://website.com y http://wesite.com:4444 se consideran del mismo origen y no se aplican restricciones.

¿Qué es una cookie?

Una cookie es una pequeña pieza de información enviada por un servidor web para almacenar en un navegador web para que luego pueda ser leída por el navegador. De esta forma, el navegador recuerda cierta información personal específica. Si un pirata informático se apodera de la información de la cookie, puede provocar problemas de seguridad.

Propiedades de las Cookies

Estas son algunas propiedades importantes de las cookies:

• Suelen ser pequeños archivos de texto, con etiquetas de identificación que se almacenan en el directorio del navegador de su computadora.

• Los desarrolladores web los utilizan para ayudar a los usuarios a navegar por sus sitios web de manera eficiente y realizar determinadas funciones.

• Cuando el usuario vuelve a navegar por el mismo sitio web, los datos almacenados en la cookie se envían de vuelta al servidor web para notificar al sitio web de las actividades anteriores del usuario.

• Las cookies son inevitables para los sitios web que tienen enormes bases de datos, necesitan inicios de sesión y tienen temas personalizables.

Contenido de las cookies

La cookie contiene la siguiente información:

• El nombre del servidor desde el que se envió la cookie.
• La vida útil de la cookie.
• Un valor, generalmente un número único generado aleatoriamente.

Tipos de cookies

• Session Cookies- Estas cookies son temporales y se borran cuando el usuario cierra el navegador. Incluso si el usuario vuelve a iniciar sesión, se crea una nueva cookie para esa sesión.

• Persistent cookies- Estas cookies permanecen en la unidad de disco duro a menos que el usuario las borre o caduquen. La caducidad de la galleta depende de cuánto tiempo puedan durar.

Prueba de cookies

Estas son las formas de probar las cookies:

• Disabling Cookies- Como tester, necesitamos verificar el acceso al sitio web después de deshabilitar las cookies y verificar si las páginas funcionan correctamente. Navegar a todas las páginas del sitio web y ver si la aplicación se bloquea. También es necesario informar al usuario que se requieren cookies para utilizar el sitio.

• Corrupting Cookies- Otra prueba que se debe realizar es corromper las cookies. Para hacer lo mismo, uno tiene que encontrar la ubicación de la cookie del sitio y editarla manualmente con datos falsos / no válidos que se pueden usar para acceder a información interna del dominio que a su vez se puede usar para piratear el sitio.

• Removing Cookies - Eliminar todas las cookies del sitio web y comprobar cómo reacciona el sitio web.

• Cross-Browser Compatibility - También es importante comprobar que las cookies se escriben correctamente en todos los navegadores compatibles desde cualquier página que escriba cookies.

• Editing Cookies- Si la aplicación utiliza cookies para almacenar información de inicio de sesión, entonces, como tester, deberíamos intentar cambiar el usuario en la barra de cookies o direcciones a otro usuario válido. La edición de la cookie no debería permitirle iniciar sesión en una cuenta de usuario diferente.

Visualización y edición de cookies

Los navegadores modernos admiten la visualización / edición de las cookies informadas dentro del propio navegador. Hay complementos para mozilla / chrome con los que podemos realizar la edición con éxito.

• Editar el complemento de cookies para Firefox

• Editar este complemento de cookies para Chrome

Deben realizarse los pasos para editar una cookie:

• Descarga el complemento para Chrome desde aquí

• Edite el valor de la cookie simplemente accediendo al complemento 'editar esta cookie' de Chrome como se muestra a continuación.

Existen varias metodologías / enfoques que podemos utilizar como referencia para realizar un ataque.

Aplicación web - Metodologías PenTesting

Se pueden tener en cuenta los siguientes estándares al desarrollar un modelo de ataque.

Entre la siguiente lista, OWASP es la más activa y hay varios contribuyentes. Nos centraremos en las técnicas OWASP que cada equipo de desarrollo tiene en cuenta antes de diseñar una aplicación web.

• PTES - Estándar de ejecución de pruebas de penetración

• OSSTMM - Manual de metodología de prueba de seguridad de código abierto

• Técnicas de prueba de OWASP: protocolo abierto de seguridad de aplicaciones web

Top 10 de OWASP

El equipo del Protocolo de seguridad de aplicaciones web abiertas publicó las 10 principales vulnerabilidades que son más frecuentes en la web en los últimos años. A continuación se muestra la lista de fallas de seguridad que son más frecuentes en una aplicación basada en web.

Aplicación: práctica

Para comprender cada una de las técnicas, trabajemos con una aplicación de muestra. Realizaremos el ataque a 'WebGoat', la aplicación J2EE que se desarrolla explícitamente con fallas de seguridad con fines de aprendizaje.

Los detalles completos sobre el proyecto webgoat se pueden encontrar https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project. Para descargar la aplicación WebGoat, vaya ahttps://github.com/WebGoat/WebGoat/wiki/Installation-(WebGoat-6.0) y vaya a la sección de descargas.

Para instalar la aplicación descargada, primero asegúrese de que no tiene ninguna aplicación ejecutándose en el puerto 8080. Puede instalarse con un solo comando: java -jar WebGoat-6.0.1-war-exec.jar. Para obtener más detalles, visite Instalación de WebGoat

Después de la instalación, deberíamos poder acceder a la aplicación navegando a http://localhost:8080/WebGoat/attack y la página se mostraría como se muestra a continuación.

Podemos usar las credenciales de invitado o administrador como se muestra en la página de inicio de sesión.

Proxy web

Para interceptar el tráfico entre el cliente (navegador) y el servidor (sistema donde está alojada la aplicación Webgoat en nuestro caso), necesitamos usar un proxy web. Usaremos Burp Proxy que se puede descargar desdehttps://portswigger.net/burp/download.html

Es suficiente si descarga la versión gratuita de burp suite como se muestra a continuación.

Configuración de Burp Suite

Burp Suite es un proxy web que puede interceptar cada paquete de información enviado y recibido por el navegador y el servidor web. Esto nos ayuda a modificar los contenidos antes de que el cliente envíe la información al Web-Server.

Step 1- La aplicación se instala en el puerto 8080 y Burp se instala en el puerto 8181 como se muestra a continuación. Inicie Burp suite y realice los siguientes ajustes para que aparezca en el puerto 8181 como se muestra a continuación.

Step 2- Debemos asegurarnos de que Burp esté escuchando el puerto # 8080 donde está instalada la aplicación para que Burp suite pueda interceptar el tráfico. Esta configuración debe realizarse en la pestaña de alcance de Burp Suite como se muestra a continuación.

Step 3- Luego, configure el proxy de su navegador para escuchar el puerto 8181 (puerto Burp Suite). Por lo tanto, hemos configurado el proxy web para interceptar el tráfico entre el cliente (navegador) y el servidor (servidor web) como se muestra a continuación:

Step 4 - La instantánea de la configuración se muestra a continuación con la ayuda de un diagrama de flujo de trabajo simple como se muestra a continuación

La técnica de inyección consiste en inyectar una consulta SQL o un comando utilizando los campos de entrada de la aplicación.

Aplicación web - Inyección

Una inyección SQL exitosa puede leer, modificar datos confidenciales de la base de datos y también puede eliminar datos de una base de datos. También permite al pirata informático realizar operaciones administrativas en la base de datos, como cerrar el DBMS / eliminar bases de datos.

Comprendamos los agentes de amenazas, los vectores de ataque, la debilidad de la seguridad, el impacto técnico y los impactos comerciales de esta falla con la ayuda de un diagrama simple.

Ejemplos

La aplicación utiliza datos que no son de confianza en la construcción de la siguiente llamada SQL vulnerable:

String query = "SELECT * FROM EMP WHERE EMPID = '" + request.getParameter("id") + "'";

Las manos en

Step 1 - Navegue hasta el área de inyección SQL de la aplicación como se muestra a continuación.

Step 2- Como se indica en el ejercicio, usamos String SQL Injection para evitar la autenticación. Utilice la inyección SQL para iniciar sesión como jefe ('Neville') sin utilizar la contraseña correcta. Verifique que se pueda ver el perfil de Neville y que todas las funciones estén disponibles (incluidas Buscar, Crear y Eliminar).

Step 3 - Inyectaremos un SQL de modo que podamos omitir la contraseña enviando el parámetro como 'a' = 'a' o 1 = 1

Step 4 - Después de la explotación, podemos iniciar sesión como Neville, que es el administrador, como se muestra a continuación.

Prevención de la inyección de SQL

Hay muchas formas de evitar la inyección de SQL. Cuando los desarrolladores escriben el código, deben asegurarse de manejar los caracteres especiales en consecuencia. Hay hojas de trucos / técnicas de prevención disponibles en OWASP, que definitivamente es una guía para desarrolladores.

• Usar consultas parametrizadas
• Escapar todas las entradas proporcionadas por el usuario
• Habilite el privilegio mínimo para la base de datos para los usuarios finales

Cuando las funciones de autenticación relacionadas con la aplicación no se implementan correctamente, permite a los piratas informáticos comprometer contraseñas o ID de sesión o explotar otras fallas de implementación utilizando las credenciales de otros usuarios.

Comprendamos los agentes de amenazas, los vectores de ataque, la debilidad de la seguridad, el impacto técnico y los impactos comerciales de esta falla con la ayuda de un diagrama simple.

Ejemplo

An e-commerce application supports URL rewriting, putting session IDs in the URL −

http://example.com/sale/saleitems/jsessionid=2P0OC2JSNDLPSKHCJUN2JV/?item=laptop

Un usuario autenticado del sitio reenvía la URL a sus amigos para conocer las ventas con descuento. Envía por correo electrónico el enlace anterior sin saber que el usuario también está regalando los ID de sesión. Cuando sus amigos usan el enlace, usan su sesión y su tarjeta de crédito.

Las manos en

Step 1- Inicie sesión en Webgoat y navegue hasta la sección "Fallos en la gestión de sesiones". Evitemos la autenticación falsificando la cookie. A continuación se muestra la instantánea del escenario.

Step 2 - Cuando iniciamos sesión con las credenciales webgoat / webgoat, encontramos en Burp Suite que el ID de JSESSION es C8F3177CCAFF380441ABF71090748F2E mientras que AuthCookie = 65432ubphcfx después de una autenticación exitosa.

Step 3 - Cuando iniciamos sesión usando el aspecto / aspecto de las credenciales, encontramos en Burp Suite que el ID de JSESSION es C8F3177CCAFF380441ABF71090748F2E mientras que AuthCookie = 65432udfqtb después de la autenticación exitosa.

Step 4- Ahora tenemos que analizar los patrones de AuthCookie. La primera mitad '65432' es común para ambas autenticaciones. Por lo tanto, ahora estamos interesados ​​en analizar la última parte de los valores de authcookie, como - ubphcfx para usuario webgoat y udfqtb para usuario de aspecto, respectivamente.

Step 5- Si echamos un vistazo en profundidad a los valores de AuthCookie, la última parte tiene la misma longitud que la del nombre de usuario. Por tanto, es evidente que el nombre de usuario se utiliza con algún método de cifrado. Tras el ensayo y los errores / mecanismos de fuerza bruta, encontramos que después de invertir el nombre de usuario, webgoat; terminamos con taogbew y luego el carácter del alfabeto anterior es lo que se usa como AuthCookie. es decir, ubphcfx.

Step 6- Si le pasamos este valor a la cookie y veamos qué pasa. Al autenticarse como usuario webgoat, cambie el valor de AuthCookie para burlarse del usuario Alice encontrando la AuthCookie para el mismo realizando el paso 4 y 5.

Mecanismos de prevención

• Desarrolle controles sólidos de autenticación y administración de sesiones de manera que cumpla con todos los requisitos de autenticación y administración de sesiones definidos en el Estándar de verificación de seguridad de aplicaciones de OWASP.

• Los desarrolladores deben asegurarse de evitar fallas XSS que pueden usarse para robar ID de sesión.

Cross-site Scripting (XSS) ocurre siempre que una aplicación toma datos que no son de confianza y los envía al cliente (navegador) sin validación. Esto permite a los atacantes ejecutar scripts maliciosos en el navegador de la víctima, lo que puede resultar en el secuestro de sesiones del usuario, desfigurar sitios web o redirigir al usuario a sitios maliciosos.

Comprendamos los agentes de amenazas, los vectores de ataque, la debilidad de la seguridad, el impacto técnico y los impactos comerciales de esta falla con la ayuda de un diagrama simple.

Tipos de XSS

• Stored XSS - El XSS almacenado, también conocido como XSS persistente, se produce cuando la entrada del usuario se almacena en el servidor de destino, como una base de datos / foro de mensajes / campo de comentarios, etc. Luego, la víctima puede recuperar los datos almacenados de la aplicación web.

• Reflected XSS - El XSS reflejado, también conocido como XSS no persistente, ocurre cuando la entrada del usuario es devuelta inmediatamente por una aplicación web en un mensaje de error / resultado de búsqueda o la entrada proporcionada por el usuario como parte de la solicitud y sin almacenar permanentemente los datos proporcionados por el usuario.

• DOM Based XSS - DOM basado en XSS es una forma de XSS cuando la fuente de los datos está en el DOM, el receptor también está en el DOM y el flujo de datos nunca sale del navegador.

Ejemplo

La aplicación utiliza datos que no son de confianza en la construcción sin validación. Los caracteres especiales deben escaparse.

http://www.webpage.org/task/Rule1?query=try

El atacante modifica el parámetro de consulta en su navegador para:

http://www.webpage.org/task/Rule1?query=<h3>Hello from XSS"</h3>

Las manos en

Step 1- Inicie sesión en Webgoat y vaya a la sección de secuencias de comandos entre sitios (XSS). Ejecutemos un ataque de secuencias de comandos de sitios cruzados almacenados (XSS). A continuación se muestra la instantánea del escenario.

Step 2- Según el escenario, inicie sesión como Tom con la contraseña 'tom' como se menciona en el escenario en sí. Haga clic en 'ver perfil' y acceda al modo de edición. Dado que Tom es el atacante, inyectemos un script Java en esos cuadros de edición.

<script> 
   alert("HACKED")
</script>

Step 3 - Tan pronto como finaliza la actualización, Tom recibe un cuadro de alerta con el mensaje "pirateado", lo que significa que la aplicación es vulnerable.

Step 4 - Ahora, según el escenario, debemos iniciar sesión como jerry (HR) y verificar si jerry se ve afectado por el script inyectado.

Step 5 - Después de iniciar sesión como Jerry, seleccione 'Tom' y haga clic en 'ver perfil' como se muestra a continuación.

Mientras ve el perfil de Tom de la cuenta de Jerry, puede obtener el mismo cuadro de mensaje.

Step 6 - Este cuadro de mensaje es solo un ejemplo, pero el atacante real puede realizar mucho más que mostrar un cuadro de mensaje.

Mecanismos preventivos

• Los desarrolladores deben asegurarse de escapar de todos los datos que no sean de confianza basados ​​en el contexto HTML, como el cuerpo, el atributo, JavaScript, CSS o la URL en la que se colocan los datos.

• Para aquellas aplicaciones que necesitan caracteres especiales como entrada, deben existir mecanismos de validación sólidos antes de aceptarlos como entradas válidas.

Es probable que se produzca una referencia directa a un objeto cuando un desarrollador expone una referencia a un objeto de implementación interno, como un archivo, directorio o clave de base de datos sin ningún mecanismo de validación que permita a los atacantes manipular estas referencias para acceder a datos no autorizados.

Comprendamos los agentes de amenazas, los vectores de ataque, la debilidad de la seguridad, el impacto técnico y los impactos comerciales de esta falla con la ayuda de un diagrama simple.

Ejemplo

La aplicación utiliza datos no verificados en una llamada SQL que accede a la información de la cuenta.

String sqlquery = "SELECT * FROM useraccounts WHERE account = ?";
PreparedStatement st = connection.prepareStatement(sqlquery, ??);
st.setString( 1, request.getParameter("acct"));
ResultSet results = st.executeQuery( );

El atacante modifica el parámetro de consulta en su navegador para que apunte a Admin.

http://webapp.com/app/accountInfo?acct=admin

Las manos en

Step 1- Inicie sesión en Webgoat y navegue hasta la sección de fallas de control de acceso. El objetivo es recuperar el archivo tomcat-users.xml navegando hasta la ruta donde se encuentra. A continuación se muestra la instantánea del escenario.

Step 2 - La ruta del archivo se muestra en el campo 'el directorio actual es' - C: \ Users \ userName $ \. Extract \ webapps \ WebGoat \ Lesson_plans \ en y también sabemos que el archivo tomcat-users.xml se guarda en C: \ xampp \ tomcat \ conf

Step 3- Necesitamos recorrer todo el camino fuera del directorio actual y navegar desde C: \ Drive. Podemos realizar lo mismo interceptando el tráfico usando Burp Suite.

Step 4 - Si el intento tiene éxito, muestra el archivo tomcat-users.xml con el mensaje "Felicitaciones. Ha completado con éxito esta lección".

Mecanismos preventivos

Los desarrolladores pueden utilizar los siguientes recursos / puntos como guía para evitar referencias directas a objetos inseguros durante la propia fase de desarrollo.

• Los desarrolladores deben usar solo un usuario o sesión para referencias indirectas a objetos.

• También se recomienda verificar el acceso antes de usar una referencia de objeto directo de una fuente que no sea de confianza.

La configuración incorrecta de seguridad surge cuando la configuración de seguridad se define, implementa y mantiene como predeterminada. Una buena seguridad requiere una configuración segura definida e implementada para la aplicación, el servidor web, el servidor de base de datos y la plataforma. Es igualmente importante tener el software actualizado.

Ejemplo

Algunos ejemplos clásicos de configuración incorrecta de seguridad son los siguientes:

• Si la lista de directorios no está deshabilitada en el servidor y si el atacante descubre lo mismo, entonces el atacante puede simplemente enumerar directorios para encontrar cualquier archivo y ejecutarlo. También es posible obtener la base de código real que contiene todo su código personalizado y luego encontrar fallas graves en la aplicación.

• La configuración del servidor de aplicaciones permite que los seguimientos de la pila se devuelvan a los usuarios, lo que podría exponer fallas subyacentes. Los atacantes obtienen esa información adicional que proporcionan los mensajes de error y que es suficiente para que puedan penetrar.

• Los servidores de aplicaciones generalmente vienen con aplicaciones de muestra que no están bien protegidas. Si no se elimina del servidor de producción, se comprometerá su servidor.

Las manos en

Step 1- Inicie Webgoat y navegue a la sección de configuración insegura y tratemos de resolver ese desafío. A continuación, se proporciona una instantánea de la misma:

Step 2- Podemos probar tantas opciones como se nos ocurran. Todo lo que necesitamos para encontrar la URL del archivo de configuración y sabemos que los desarrolladores siguen una especie de convención de nomenclatura para los archivos de configuración. Puede ser cualquier cosa que se enumere a continuación. Por lo general, se realiza mediante la técnica de fuerza BRUTE.

• web.config
• config
• appname.config
• conf

Step 3 - Al probar varias opciones, encontramos que 'http://localhost:8080/WebGoat/conf' es exitoso. La siguiente página se muestra si el intento es exitoso:

Mecanismos preventivos

• Todos los entornos, como los de desarrollo, control de calidad y producción, deben configurarse de forma idéntica utilizando diferentes contraseñas utilizadas en cada entorno que no se puedan piratear fácilmente.

• Asegúrese de que se adopte una arquitectura de aplicación sólida que proporcione una separación segura y eficaz entre los componentes.

• También puede minimizar la posibilidad de este ataque mediante la ejecución de análisis automatizados y auditorías periódicamente.

Dado que las aplicaciones en línea siguen inundando Internet día a día, no todas las aplicaciones están protegidas. Muchas aplicaciones web no protegen adecuadamente los datos confidenciales del usuario, como la información de las tarjetas de crédito, la información de la cuenta bancaria o las credenciales de autenticación. Los piratas informáticos pueden terminar robando esos datos débilmente protegidos para cometer fraude con tarjetas de crédito, robo de identidad u otros delitos.

Comprendamos los agentes de amenazas, los vectores de ataque, la debilidad de la seguridad, el impacto técnico y los impactos comerciales de esta falla con la ayuda de un diagrama simple.

Ejemplo

Algunos de los ejemplos clásicos de configuración incorrecta de seguridad son los siguientes:

• Un sitio simplemente no usa SSL para todas las páginas autenticadas. Esto permite a un atacante monitorear el tráfico de la red y robar la cookie de sesión del usuario para secuestrar la sesión de los usuarios o acceder a sus datos privados.

• Una aplicación almacena los números de las tarjetas de crédito en formato cifrado en una base de datos. Una vez recuperados, se descifran, lo que permite al pirata informático realizar un ataque de inyección SQL para recuperar toda la información confidencial en un texto claro. Esto se puede evitar cifrando los números de tarjetas de crédito con una clave pública y permitiendo que las aplicaciones de back-end los descifren con la clave privada.

Las manos en

Step 1- Inicie WebGoat y navegue hasta la sección "Almacenamiento inseguro". A continuación se muestra una instantánea de la misma.

Step 2- Ingrese el nombre de usuario y la contraseña. Es hora de aprender diferentes tipos de metodologías de codificación y encriptación que discutimos anteriormente.

Mecanismos preventivos

• Se recomienda no almacenar datos confidenciales innecesariamente y debe eliminarse lo antes posible si ya no es necesario.

• Es importante asegurarse de que incorporamos algoritmos de cifrado sólidos y estándar, y que se implementa una administración de claves adecuada.

• También se puede evitar deshabilitando el autocompletado en formularios que recopilan datos confidenciales, como contraseñas, y deshabilitando el almacenamiento en caché de páginas que contienen datos confidenciales.

La mayoría de las aplicaciones web verifican los derechos de acceso a nivel de función antes de hacer que esa funcionalidad sea accesible para el usuario. Sin embargo, si no se realizan las mismas comprobaciones de control de acceso en el servidor, los piratas informáticos pueden penetrar en la aplicación sin la debida autorización.

Comprendamos los agentes de amenazas, los vectores de ataque, la debilidad de la seguridad, el impacto técnico y los impactos comerciales de esta falla con la ayuda de un diagrama simple.

Ejemplo

Aquí hay un ejemplo clásico de control de acceso de nivel de función faltante:

El hacker simplemente fuerza las URL de destino. Por lo general, el acceso de administrador requiere autenticación; sin embargo, si el acceso a la aplicación no está verificado, un usuario no autenticado puede acceder a la página de administración.

' Below URL might be accessible to an authenticated user
http://website.com/app/standarduserpage

' A NON Admin user is able to access admin page without authorization.
http://website.com/app/admin_page

Las manos en

Step 1 - Permítanos iniciar sesión como administrador de cuenta revisando primero la lista de usuarios y sus privilegios de acceso.

Step 2 - Al probar varias combinaciones podemos descubrir que Larry tiene acceso al administrador de cuentas de recursos.

Mecanismos preventivos

• El mecanismo de autenticación debe denegar todos los accesos de forma predeterminada y proporcionar acceso a roles específicos para cada función.

• En una aplicación basada en flujo de trabajo, verifique el estado de los usuarios antes de permitirles acceder a cualquier recurso.

Un ataque CSRF obliga a un usuario autenticado (víctima) a enviar una solicitud HTTP falsificada, incluida la cookie de sesión de la víctima a una aplicación web vulnerable, lo que permite al atacante obligar al navegador de la víctima a generar una solicitud de modo que la aplicación vulnerable perciba solicitudes legítimas de la víctima.

Comprendamos los agentes de amenazas, los vectores de ataque, la debilidad de la seguridad, el impacto técnico y los impactos comerciales de esta falla con la ayuda de un diagrama simple.

Ejemplo

Aquí hay un ejemplo clásico de CSRF:

Step 1 - Digamos que la aplicación vulnerable envía una solicitud de cambio de estado como texto sin cifrar.

http://bankx.com/app?action=transferFund&amount=3500&destinationAccount=4673243243

Step 2 - Ahora el hacker construye una solicitud que transfiere dinero de la cuenta de la víctima a la cuenta del atacante incrustando la solicitud en una imagen que se almacena en varios sitios bajo el control del atacante -

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

Las manos en

Step 1- Realicemos una falsificación de CSRF incrustando un script Java en una imagen. La instantánea del problema se enumera a continuación.

Step 2 - Ahora necesitamos simular la transferencia en una imagen 1x1 y hacer que la víctima haga clic en la misma.

Step 3 - Al enviar el mensaje, el mensaje se muestra como se resalta a continuación.

Step 4- Ahora, si la víctima hace clic en la siguiente URL, se ejecuta la transferencia, que se puede encontrar interceptando la acción del usuario usando burp suite. Podemos ver la transferencia al detectarla en Obtener mensaje como se muestra a continuación:

Step 5 - Ahora, al hacer clic en actualizar, se muestra la marca de finalización de la lección.

Mecanismos preventivos

• CSRF se puede evitar creando un token único en un campo oculto que se enviaría en el cuerpo de la solicitud HTTP en lugar de en una URL, que es más propensa a la exposición.

• Obligar al usuario a volver a autenticarse o demostrar que es un usuario para proteger CSRF. Por ejemplo, CAPTCHA.

Este tipo de amenaza se produce cuando los componentes, como las bibliotecas y los marcos utilizados dentro de la aplicación, casi siempre se ejecutan con todos los privilegios. Si se explota un componente vulnerable, facilita el trabajo del pirata informático para provocar una pérdida de datos grave o la toma de control del servidor.

Comprendamos los agentes de amenazas, los vectores de ataque, la debilidad de la seguridad, el impacto técnico y los impactos comerciales de esta falla con la ayuda de un diagrama simple.

Ejemplo

Los siguientes ejemplos son de uso de componentes con vulnerabilidades conocidas:

• Los atacantes pueden invocar cualquier servicio web con pleno permiso si no proporcionan un token de identidad.

• La ejecución remota de código con vulnerabilidad de inyección de lenguaje de expresión se introduce a través de Spring Framework para aplicaciones basadas en Java.

Mecanismos preventivos

• Identifique todos los componentes y las versiones que se utilizan en las aplicaciones web, no solo restringidas a bases de datos / marcos.

• Mantenga actualizados todos los componentes, como bases de datos públicas, listas de distribución de proyectos, etc.

• Agregue envoltorios de seguridad alrededor de los componentes que son vulnerables por naturaleza.

La mayoría de las aplicaciones web en Internet redireccionan y reenvían a los usuarios con frecuencia a otras páginas u otros sitios web externos. Sin embargo, sin validar la credibilidad de esas páginas, los piratas informáticos pueden redirigir a las víctimas a sitios de phishing o malware, o utilizar reenvíos para acceder a páginas no autorizadas.

Comprendamos los agentes de amenazas, los vectores de ataque, la debilidad de la seguridad, el impacto técnico y los impactos comerciales de esta falla con la ayuda de un diagrama simple.

Ejemplo

Algunos ejemplos clásicos de redirecciones y reenvíos no validados son los siguientes:

• Digamos que la aplicación tiene una página - redirect.jsp, que toma un parámetro redirectrul . El hacker agrega una URL maliciosa que redirige a los usuarios que realizan phishing / instalan malware.

http://www.mywebapp.com/redirect.jsp?redirectrul=hacker.com

• Toda la aplicación web utilizada para reenviar a los usuarios a diferentes partes del sitio. Para lograr lo mismo, algunas páginas utilizan un parámetro para indicar a dónde se debe redirigir al usuario si una operación tiene éxito. El atacante crea una URL que pasa la verificación de control de acceso de la aplicación y luego reenvía al atacante a la funcionalidad administrativa para la cual el atacante no tiene acceso.

http://www.mywebapp.com/checkstatus.jsp?fwd=appadmin.jsp

Mecanismos preventivos

• Es mejor evitar el uso de redireccionamientos y reenvíos.

• Si es inevitable, debe hacerse sin involucrar a los parámetros del usuario en la redirección del destino.

Javascript y XML asíncronos (AJAX) es una de las últimas técnicas utilizadas para desarrollar aplicaciones web con el fin de brindar una experiencia de usuario rica. Dado que es una nueva tecnología, hay muchos problemas de seguridad que aún no se han establecido y a continuación se muestran los pocos problemas de seguridad en AJAX.

• La superficie de ataque es mayor ya que hay más entradas que asegurar.

• También expone las funciones internas de las aplicaciones.

• No proteger la información y las sesiones de autenticación.

• Existe una línea muy estrecha entre el lado del cliente y el lado del servidor, por lo que existen posibilidades de cometer errores de seguridad.

Ejemplo

Aquí hay un ejemplo de seguridad AJAX:

En 2006, un gusano infectó el servicio de correo de Yahoo utilizando XSS y AJAX que aprovechó una vulnerabilidad en el manejo de eventos de carga de Yahoo Mail. Cuando se abrió un correo electrónico infectado, el gusano ejecutó su JavaScript, enviando una copia a todos los contactos de Yahoo del usuario infectado.

Las manos en

Step 1- Necesitamos intentar agregar más recompensas a su conjunto permitido de recompensas mediante la inyección de XML. A continuación se muestra la instantánea del escenario.

Step 2- Asegúrese de que interceptamos tanto la solicitud como la respuesta utilizando Burp Suite. Configuración de la misma que se muestra a continuación.

Step 3- Ingrese el número de cuenta como se indica en el escenario. Podremos obtener una lista de todas las recompensas para las que somos elegibles. Somos elegibles para 3 recompensas de 5.

Step 4- Ahora hagamos clic en 'Enviar' y veamos qué obtenemos en el XML de respuesta. Como se muestra a continuación, las tres recompensas que somos elegibles se nos pasan como XML.

Step 5 - Ahora editemos esos XML y agreguemos las otras dos recompensas también.

Step 6- Ahora todas las recompensas se mostrarán al usuario para que las seleccione. Seleccione los que agregamos y haga clic en 'Enviar'.

Step 7 - Aparece el siguiente mensaje que dice: "* Felicitaciones. Ha completado con éxito esta lección".

Mecanismos preventivos

Lado del cliente -

• Utilice .innerText en lugar de .innerHtml.
• No use eval.
• No confíe en la lógica del cliente para la seguridad.
• Evite escribir código de serialización.
• Evite crear XML de forma dinámica.
• Nunca transmita secretos al cliente.
• No realice el cifrado en el código del lado del cliente.
• No ejecute lógica que afecte a la seguridad en el lado del cliente.

Lado del servidor -

• Utilice protección CSRF.
• Evite escribir código de serialización.
• Los usuarios pueden llamar a los servicios directamente.
• Evite construir XML a mano, use el marco.
• Evite construir JSON a mano, use un marco existente.

En las aplicaciones modernas basadas en web, el uso de servicios web es inevitable y también son propensos a sufrir ataques. Dado que los servicios web solicitan la recuperación de varios sitios web, los desarrolladores deben tomar algunas medidas adicionales para evitar cualquier tipo de penetración por parte de piratas informáticos.

Las manos en

Step 1- Navegue al área de servicios web de Webgoat y vaya a Escaneo WSDL. Ahora necesitamos obtener los detalles de la tarjeta de crédito de algún otro número de cuenta. La instantánea del escenario es como se menciona a continuación.

Step 2 - Si seleccionamos el primer nombre, la llamada a la función 'getFirstName' se realiza a través de la solicitud SOAP xml.

Step 3- Al abrir el WSDL, podemos ver que existe un método para recuperar la información de la tarjeta de crédito y también 'getCreditCard'. Ahora manipulemos las entradas usando Burp suite como se muestra a continuación:

Step 4 - Ahora modifiquemos las entradas usando Burp suite como se muestra a continuación -

Step 5 - Podemos obtener la información de la tarjeta de crédito de otros usuarios.

Mecanismos preventivos

• Dado que los mensajes SOAP están basados ​​en XML, todas las credenciales pasadas deben convertirse a formato de texto. Por lo tanto, hay que tener mucho cuidado al transmitir la información confidencial que siempre debe estar encriptada.

• Proteger la integridad del mensaje mediante la implementación de mecanismos como la suma de verificación aplicada para garantizar la integridad del paquete.

• Protección de la confidencialidad de los mensajes: el cifrado asimétrico se aplica para proteger las claves de sesión simétricas, que en muchas implementaciones son válidas para una sola comunicación y se descartan posteriormente.

Un desbordamiento de búfer surge cuando un programa intenta almacenar más datos en un área de almacenamiento de datos temporal (búfer) de los que se pretendía que retengan. Dado que los búferes se crean para contener una cantidad finita de datos, la información adicional puede desbordarse en búferes adyacentes, corrompiendo así los datos válidos que contienen.

Ejemplo

A continuación se muestran ejemplos clásicos de desbordamiento de búfer. Demuestra un simple desbordamiento de búfer causado por el primer escenario en el que se basa en datos externos para controlar su comportamiento. No hay forma de limitar la cantidad de datos que el usuario ha ingresado y el comportamiento del programa depende de la cantidad de caracteres que haya introducido el usuario.

...
   char bufr[BUFSIZE]; 
   gets(bufr);
   ...

Las manos en

Step 1- Necesitamos iniciar sesión con nombre y número de habitación para tener acceso a Internet. Aquí está la instantánea del escenario.

Step 2 - También habilitaremos "Mostrar campos de formulario ocultos" en Burp Suite como se muestra a continuación -

Step 3- Ahora enviamos una entrada en el campo de nombre y número de habitación. También intentamos inyectar un número bastante grande en el campo de número de habitación.

Step 4- Los campos ocultos se muestran como se muestra a continuación. Hacemos clic en aceptar términos.

Step 5 - El ataque tiene éxito de tal manera que, como resultado del desbordamiento del búfer, comenzó a leer las ubicaciones de memoria adyacentes y se mostró al usuario como se muestra a continuación.

Step 6- Ahora permítanos iniciar sesión con los datos mostrados. Después de iniciar sesión, se muestra el siguiente mensaje:

Mecanismos preventivos

• Revisión de código
• Capacitación para desarrolladores
• Herramientas del compilador
• Desarrollando funciones seguras
• Escaneo periódico

El ataque de denegación de servicio (DoS) es un intento de los piratas informáticos de hacer que un recurso de red no esté disponible. Por lo general, interrumpe al host, temporal o indefinidamente, que está conectado a Internet. Estos ataques suelen tener como objetivo los servicios alojados en servidores web de misión crítica, como bancos, pasarelas de pago con tarjetas de crédito.

Síntomas de DoS

• Rendimiento de red inusualmente lento.
• No disponibilidad de un sitio web en particular.
• Incapacidad para acceder a cualquier sitio web.
• Incremento dramático en el número de correos electrónicos no deseados recibidos.
• Denegación a largo plazo de acceso a la web o cualquier servicio de Internet.
• Falta de disponibilidad de un sitio web en particular.

Las manos en

Step 1- Inicie WebGoat y vaya a la sección 'Denegación de servicio'. La instantánea del escenario se muestra a continuación. Necesitamos iniciar sesión varias veces allí incumpliendo el tamaño máximo del grupo de subprocesos de base de datos.

Step 2- Primero necesitamos obtener la lista de inicios de sesión válidos. Usamos SQL Injection en este caso.

Step 3 - Si el intento es exitoso, muestra todas las credenciales válidas al usuario.

Step 4- Ahora inicie sesión con cada uno de estos usuarios en al menos 3 sesiones diferentes para que el ataque DoS sea exitoso. Como sabemos que la conexión a la base de datos solo puede manejar dos subprocesos, al usar todos los inicios de sesión, se crearán tres subprocesos que harán que el ataque sea exitoso.

Mecanismos preventivos

• Realice validaciones de entrada exhaustivas.

• Evite operaciones que consuman mucho CPU.

• Es mejor separar los discos de datos de los discos del sistema.

Los desarrolladores a menudo usan o concatenan directamente entradas potencialmente vulnerables con archivos o asumen que los archivos de entrada son genuinos. Cuando los datos no se verifican correctamente, esto puede llevar a que el servidor web procese o invoque el contenido vulnerable.

Ejemplo

Algunos de los ejemplos clásicos incluyen:

• Cargue el archivo .jsp en el árbol web.
• Sube .gif para cambiar su tamaño.
• Sube archivos enormes.
• Cargue el archivo que contiene las etiquetas.
• Cargue el archivo .exe en el árbol web.

Las manos en

Step 1- Inicie WebGoat y navegue hasta la sección Ejecución de archivos maliciosos. La instantánea del escenario se da a continuación:

Step 2 - Para completar esta lección, necesitamos cargar guest.txt en la ubicación mencionada anteriormente.

Step 3- Creemos un archivo jsp de modo que el archivo guest.txt se cree al ejecutar jsp. El nombre del jsp no tiene ningún papel que desempeñar en este contexto, ya que estamos ejecutando el contenido del archivo jsp.

<HTML> 
   <% java.io.File file = new 
      java.io.File("C:\\Users\\username$\\.extract\\webapps\\WebGoat\\mfe_target\\guest.txt"); 
      file.createNewFile(); %> 
</HTML>

Step 4- Ahora cargue el archivo jsp y copie la ubicación del enlace del mismo después de cargarlo. La carga espera una imagen, pero estamos cargando un archivo jsp.

Step 5 - Al navegar al archivo jsp, no habrá ningún mensaje para el usuario.

Step 6 - Ahora actualice la sesión en la que ha subido el archivo jsp y obtendrá el mensaje que dice, "* Felicitaciones. Ha completado con éxito la lección".

Mecanismos preventivos

• Sitios web seguros mediante permisos de sitios web.
• Adopte contramedidas para la seguridad de las aplicaciones web.
• Comprender las cuentas de grupo y de usuario integradas en IIS 7.0.

Hay varias herramientas disponibles para realizar pruebas de seguridad de una aplicación. Hay pocas herramientas que pueden realizar pruebas de seguridad de un extremo a otro, mientras que algunas están dedicadas a detectar un tipo particular de falla en el sistema.

Herramientas de código abierto

Algunas herramientas de prueba de seguridad de código abierto son las siguientes:

S.No.	Nombre de la herramienta
1	Zed Attack Proxy Proporciona escáneres automatizados y otras herramientas para detectar fallas de seguridad. https://www.owasp.org
2	OWASP WebScarab Desarrollado en Java para analizar solicitudes Http y Https. https://www.owasp.org/index.php
3	OWASP Mantra Admite un marco de pruebas de seguridad multilingüe https://www.owasp.org/index.php/OWASP_Mantra_-_Security_Framework
4	Burp Proxy Herramienta para interceptar y modificar el tráfico y funciona con certificados SSL personalizados. https://www.portswigger.net/Burp/
5	Firefox Tamper Data Utilice tamperdata para ver y modificar encabezados HTTP / HTTPS y parámetros de publicación https://addons.mozilla.org/en-US
6	Firefox Web Developer Tools La extensión Web Developer agrega varias herramientas de desarrollo web al navegador. https://addons.mozilla.org/en-US/firefox
7	Cookie Editor Permite al usuario agregar, eliminar, editar, buscar, proteger y bloquear cookies https://chrome.google.com/webstore

Juegos de herramientas específicos

Las siguientes herramientas pueden ayudarnos a detectar un tipo particular de vulnerabilidad en el sistema:

S.No.	Enlace
1	DOMinator Pro − Testing for DOM XSS https://dominator.mindedsecurity.com/
2	OWASP SQLiX − SQL Injection https://www.owasp.org/index.php
3	Sqlninja − SQL Injection http://sqlninja.sourceforge.net/
4	SQLInjector − SQL Injection https://sourceforge.net/projects/safe3si/
5	sqlpowerinjector − SQL Injection http://www.sqlpowerinjector.com/
6	SSL Digger − Testing SSL https://www.mcafee.com/us/downloads/free-tools
7	THC-Hydra − Brute Force Password https://www.thc.org/thc-hydra/
8	Brutus − Brute Force Password http://www.hoobie.net/brutus/
9	Ncat − Brute Force Password https://nmap.org/ncat/
10	OllyDbg − Testing Buffer Overflow http://www.ollydbg.de/
11	Spike − Testing Buffer Overflow https://www.immunitysec.com/downloads/SPIKE2.9.tgz
12	Metasploit − Testing Buffer Overflow https://www.metasploit.com/

Herramientas comerciales de prueba de caja negra

Estas son algunas de las herramientas comerciales de prueba de caja negra que nos ayudan a detectar problemas de seguridad en las aplicaciones que desarrollamos.

S. No	Herramienta
1	NGSSQuirreL https://www.nccgroup.com/en/our-services
2	IBM AppScan https://www-01.ibm.com/software/awdtools/appscan/
3	Acunetix Web Vulnerability Scanner https://www.acunetix.com/
4	NTOSpider https://www.ntobjectives.com/products/ntospider.php
5	SOAP UI https://www.soapui.org/Security/getting-started.html
6	Netsparker https://www.mavitunasecurity.com/netsparker/
7	HP WebInspect http://www.hpenterprisesecurity.com/products

Analizadores de código fuente gratuitos

S. No	Herramienta
1	OWASP Orizon https://www.owasp.org/index.php
2	OWASP O2 https://www.owasp.org/index.php/OWASP_O2_Platform
3	SearchDiggity https://www.bishopfox.com/resources/tools
4	FXCOP https://www.owasp.org/index.php/FxCop
5	Splint http://splint.org/
6	Boon https://www.cs.berkeley.edu/~daw/boon/
7	W3af http://w3af.org/
8	FlawFinder https://www.dwheeler.com/flawfinder/
9	FindBugs http://findbugs.sourceforge.net/

Analizadores de código fuente comercial

Estos analizadores examinan, detectan e informan las debilidades en el código fuente, que son propensas a vulnerabilidades:

S. No	Herramienta
1	Parasoft C/C++ test https://www.parasoft.com/cpptest/
2	HP Fortify http://www.hpenterprisesecurity.com/products
3	Appscan http://www-01.ibm.com/software/rational/products
4	Veracode https://www.veracode.com
5	Armorize CodeSecure http://www.armorize.com/codesecure/
6	GrammaTech https://www.grammatech.com/