Menú

Mostrar Mensajes

Esta sección te permite ver todos los mensajes escritos por este usuario. Ten en cuenta que sólo puedes ver los mensajes escritos en zonas a las que tienes acceso en este momento.

Mostrar Mensajes Menú

Mensajes - WHK

#1
Hacking / Consultoría - Cómo solucionar un XSS
7 Noviembre 2021, 17:46 PM
Hola, para dedicarse a la seguridad de manera profesional no solamente basta con saber encontrar un XSS sino también es necesario saber porque se produce y como darle una solución, ya que en muchas ocasiones nos toca hablar con el dueño de la aplicación WEB y nos pide consejos y estos no pueden estar fundados en la ignorancia. Por eso quiero comentarles como aconsejar a alguien sobre como solucionar un XSS y como darle su importancia.


Estructura

Cuando encuentras un XSS es importante saber que el dueño de la aplicación no es el experto en seguridad sino tu mismo, por lo cual el dueño puede que entienda menos de la mitad de lo que le digas, por eso es importante ser muy claro y estructurado al momento de detallar un XSS:

  • Resumen del hallazgo
  • Cómo replicar el problema (PoC) (ojo, no te están pidiendo mostrar un alert, sino replicar un impacto real)
  • Porqué es un riesgo de seguridad (impacto)
  • Cuales son las mejores recomendciones

Generalmente en el resumen del hallazgo debes incluir el tipo de vulnerabilidad, normalmente categorizado junto al nivel de riesgo y esto lo puedes obtener a traves de diferentes estándares tales como la CVSS ( https://nvd.nist.gov/vuln-metrics/cvss ) y la CWE ( https://nvd.nist.gov/vuln/categories ) ya que será tu palabra contra el dueño de la aplicación, por lo cual siempre es buena idea apegarse a los estándares.


Recomendaciones

Acá va el problema: el cliente tiene un sitio WEB que cuenta con una vulnerabilidad de tipo XSS Reflejado ( CWE 80 https://cwe.mitre.org/data/definitions/80.html ) y el cliente necesita una recomendación. He escuchado a muchas personas recomendar lo siguiente de manera equivocada:

  • Impedir el ingreso de caracteres especiales en los campos
  • Filtrar los caracteres especiales evitando que en el input se ingresen etiquetas HTML
  • Crear una regla en el WAF para evitar los XSS

Pero, ¿Porqué están errados?: Para comenzar, impedir o filtrar el ingreso de caracteres especiales en los campos es una recomendación demasiado genérica y va a depender del tamaño y de la arquitectura de la aplicación. Como podemos observar, el CWE es 80 ( https://cwe.mitre.org/data/definitions/80.html ) y no 79 ( https://cwe.mitre.org/data/definitions/79.html ), hay una gran diferencia ya que el CWE-79 indica que es un problema de caracteres de entrada y el CWE-80 indica que es un problema de salida.

Cuando ingresas contenido HTML en un campo y este se refleja en el código fuente resolutante de la respuesta del sitio WEB (response) entonces tenemos un problema de datos de salida y no de entrada, pero ¿porqué no filtrar los caracteres en la entrada para evitar tener problemas en los datos de salida?: porque no todas las aplicaciones funcionan igual y esto dependerá de su arquitectura, por ejemplo: Supongamos que nuestro sistema tiene una versión WEB y una version movil, si filtro los caracteres especiales en la entrada de datos para convertirlos en entidades HTML para que se guarde en la base de datos entonces cuando la aplicación móvil vaya a solicitar estos datos vendrán con escapes HTML pero las aplicaciones móviles nativas no usan HTML asi que se verán caracteres extraños basura en el contenido. No todo lo que esté en una base de datos significa que se desplegará en una aplicación WEB o móvil o de escritorio, sea nativa o híbrida, por esto es muy importante tener en mente el siguiente concepto:

Ningún dato de entrada debe ser filtrado a menos que sea un filtro de datos por concepto de definición de capa de negocio y datos, o sea, si mi valor a ingresar debe ser siempre un número positivo entonces eso si se puede filtrar, si el nombre debe tener una longitud máxima entonces esto debe ser controlado y filtrado, pero si no hay nada que impida que alguien ingrese un caracter especial en una caja de descripción entonces para que filtrar, por lo contrario, un buen desarrollo debe poder funcionar de manera segura con cualquier tipo de caracter especial, por ejemplo, este foro permite caracteres especiales para el nombre de usuario o la caja del contenido del post y no quiere decir que se deban eliminar todos los caracteres especiales para hacerlo mas seguro.

Si eres un profesional y encontraste un buen XSS pero aconsejas filtrar los campos de entrada te puede hacer quedar como ignorante en el campo del desarrollo de la solución y puede que pierdan la confianza en ti y sin que te lo digan.

¿Porqué no es bueno recomendar que se solucione del lado del WAF creando reglas que impidan los XSS?: Porque un WAF es solamente un agente mitigante pero no un solucionador de problemas, puede que para alguien sea mas dificil llegar al XSS pero el agujero de seguridad con el riesgo aun van a seguir existiendo, los riesgos se reducen pero no se eliminan, por lo cual no se considera una solución sino una mitigación y esto es parte de dos planes de trabajo: La mitigación al corto plazo y la solución al mediano/largo plazo.


¿Cual es la mejor recomendación?

Crear un plan de mitigación al corto plazo sonde se mitigue a traves de diferentes agentes dependiendo los que tenga el dueño de la aplicación WEB (Web Application Firewall), por ejemplo, el WAF para mitigar los ataques WEB, un Firewall para evitar la llegada de paquetes maliciosos a la infraestructura, evitar pivoting y esas cosas.

Crear un plan de solución al mediano/largo plazo que incluya corrección de código fuente del lado del desarrollo y acá entra algo de conocimiento de Arquitectura aplicativa:

En el caso de ser una aplicatión WEB monolítica ( https://es.wikipedia.org/wiki/Aplicaci%C3%B3n_monol%C3%ADtica ) se debe recomendar crear un escapado de datos de salida en el punto vulnerable y ojo, existen varias maneras de hacerlo según sea el caso ya que va a depender en que lugar del código resultante se realiza la impresión de la variable vulnerable con el XSS, pero antes de explicar esto es necesario entender otra cosa: ¿Qué es una secuencia de escape de caracteres?.

Pues bien, digamos que tenemos un String entre comillas dobles así:

"Palabra acá"

¿Que sucede si el valor de esta palabra contiene una comilla doble?

"Palabra " acá"

Pues, lo que sucede es que se rompe la cadena de texto ya que las comillas dobles declaran el valor, todo lo que esté dentro es parte del texto, pero cuando le pones una comilla doble lo estás interrumpiendo indicando que se está cerrando la declaración, o sea, que la palabra ya ha terminado, entonces, que sucede con el texto restante, en este caso podrías hacer dos textos o inyectar algo entremedio, por ejemplo usando la frase: Palabra" + algo + "acá

"Palabra" + algo + "acá"

Y bueno, se produce una inyección de código malicioso entre una declaración de tipo texto. Esto mismo sucede en muchos lugares, como verán, no estoy hablando de un lenguaje de programación en particular ya que cada lenguaje utiliza su propia sintaxis y su propia manera de escapar los caracteres.

Entonces, para evitar que suceda una inyección se creó algo universal llamado "Secuencia de escape de caracteres" los cuales se añaden al caracter especial para que este forme parte de la cadena de texto y no que lo rompa, por ejemplo, en javascript es el backslash "\", por ejemplo:

"Palabra \" acá"

Esto le indica al motor interpretador de javascript que el caracter que sigue después del backslash será parte del texto en ves de interpretarse como un quiebre del string. En batch el caracter de escape es el "^" y el "%%", en bash es el backslash, en SQL es el backslash, en javascript es el backslash y en HTML es la Entidad HTML! ( https://dev.w3.org/html5/html-author/charref ).

Asi que, en nuestro XSS pueden haber dos situaciones muy comunes, que el código esté imprimiendose dentro de una etiqueta javascript o dentro del mismo HTML y en cambos casos se necesitarán usar diferentes tipos de secuencia de escape, por ejemplo:

<script>var x = '$valor_escapado';</script>

Donde $valor_escapado será igual al texto de salida escapado, esto quiere decir que cada caracter especial podrá ser reemplazado por valores de escape unicode o hexadecimal (definido por el estandar de javascript ES6), por ejemplo:

"Palabra \x22 ac\xc3\xa1"

Pero, ¿con que función se escapa?: Eso dependerá del lenguaje de programación o del framework que estés utilizando, cada lenguaje o framework tiene distintas maneras de aplicar este filtrado y de ahi la importancia de entender de desarrollo de software, comprender lo que estás analizando, mas allá de ver un simple XSS.

Ahora vamos con el código HTML, su secuencia de escape está definido por el estandar mismo de la W3C: https://dev.w3.org/html5/html-author/charref , por lo cual enocntramos las siguientes equivalencias:



Valor/Entidad que lo reemplaza
<&lt;
>&gt;
'&apos;
"&quot;

Entonces, si el problema estuviera en código HTML debería ser escapado de la siguiente manera:

<input type="text" value="Palabra &quot; acá" />

Hay personas que aplican un filtro html para todo el código, pero esto no escapa contenido javascript, por ejemplo, en javascrpt puedes inyectar código con un backslash, pero HTML no tiene un escape para backslash porque para HTML ese caracter no es peligroso pero para javascript si, lo mismo sucede cuando intentas romper una secuencia con un salto de línea, por otro lado un tag html en javascript no le pasa nada pero a HTML si. Asi que, cada lenguaje en cada trozo de código debe llevar su propia secuencia de escape de caracteres o podrás terminar abriendo una vulnerabilidad donde antes no lo había.

Pero, en aplicaciones con separación de capas (no monolíoticas) hay que indicar que esto se debe hacer del lado del código que expone la información, o sea la capa de presentación ( https://es.wikipedia.org/wiki/Programaci%C3%B3n_por_capas ), y ojo, no se les vaya a ocurrir decirle a alguien que debe escapar absolutamente todo, ya que va a depender de muchas cosas, por ejemplo, un servicio REST que expone datos a traves de código Json tiene su propia secuencia de escape de caracteres y esto generalmente se maneja de manera automática dependiendo del lenguaje y framework de programación.

Asi que, ahora si estamos medianamente listos para dar una buena recomendación:

CitarA modo de solución al mediano/largo plazo se recomienda aplicar la secuencia de escape de caracteres utilizando el estandar de Entidades HTML declarado por W3C en capa de presentación, únicamente sobre el parámetro afectado.

Como verán, la recomendación es corta, pero va al grano y con todo el tecnicismo que necesita el dueño de la aplicación, es muy diferente a decir "hay que filtrar los datos de entrada" y ya.

A modo de conocimiento general, en algunas ocasiones, a demás de recomendar solucionar el XSS también se le recomienda sobre migrar de tecnología a una mas segura, por ejemplo, si el desarrollo WEB no utiliza un framework, sino que está hecho a mano con archivos php o jsp tirados en el servidor, entonces se le dice que al largo plazo va a ser mejor migrar a un framework de desarrollo mas seguro como Codeigniter, Laravel o Spring boot ya que estos frameworks manejan de manera automática los problemas de tipo inyección como los XSS o Inyección SQL debido a que nunca programas código a mano, sino que te apoyas en clases y templates, donde las consultas SQL ya no se realizan directamente sino que usas clases y el framework traduce esas clases a consultas SQL parametrizadas y ya no programas variables directamente sobre HTML sino que programas sobre un sistema de plantillas que traduce tu código a código escapado de manera automática como es el caso de Jinja para Django de Python, Thymeleaf para Spring Boot de Java y Razor para MVC de .NET.

Como ya habrán notado, esto no solo aplica para los XSS sino para cualquier tipo de vulnerabilidad de tipo inyección, esto incluye Inyecciones SQL e Inyección de Comandos, Inyección XML, Inyección LDAP y similares.


Recomendaciones adicionales

Cuando el dueño de una aplicación pregunta como solucionar un problema, por lo general no se lo pregunta a la persona de al lado, sino que se lo pregunta al que encontró el problema y estará esperando a que entiendas como ayudarlo pero si no sabes en que lenguaje está hecho o no tienes los fundamentos básicos de desarrollo entonces va a ser dificil dar una recomendación certera, incluso puede que estés dando una recomendación erronea y que en el futuro tengan problemas aun mas graves y les hagas perder el tiempo, me ha tocado ver esos casos y no es muy agradable decirle a una persona que lo que hizo a modo de corrección realmente no sirve y que va a tener que volver a programar sus soluciones.


Espero les pueda ayudar un poco a ampliar el vocabulario se seguridad informática. Saludos.
#2
Scripting / Re: Python
18 Octubre 2021, 23:49 PM
Hola Keops_F, recuerda que en este lugar se enseña y ayuda pero no se hacen tareas. Saludos.
#3
.NET (C#, VB.NET, ASP) / Re: CURL / HTTP REQUEST
18 Octubre 2021, 23:44 PM
Creo que hay una confusión o no logro entender todo el contexto. ¿Necesitas traducir tu sitio web o necesitas crear alguna aplicación que haga traducciones o que cosa?.

Para programar algo debes usar un lenguaje de programación y cada lenguaje tiene su función para hacer llamadas http y según el lenguaje es de que manera podrás utilizar el mensaje retornado por la api del servidor.

Si pruebas esto:

curl -v https://api-free.deepl.com/v2/translate \
   -d auth_key=589f13c6-e0b0-4b74-88bd-ca2ea8669048:fx \
   -d "text=Hello, world!"  \
   -d "target_lang=DE"

Verás que retorna esto:

< HTTP/2 403
< server: nginx
< date: Mon, 18 Oct 2021 21:45:37 GMT
< content-length: 0
< access-control-allow-origin: *


Un error 403 significa "acceso denegado" y probablemente suceda porque el auth_key no es válido.
#4
Imagina si un profesor lo reprueba en un examen, se va a ir a su casa y va a dejar de estudiar para siempre :-/
#7
root@x:~#  curl --silent --path-as-is --insecure "127.0.0.1/cgi-bin/.%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd"
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
</p>
<hr>
<address>Apache/2.4.41 (Ubuntu) Server at 127.0.0.1 Port 80</address>
</body></html>


Creo que no es replicable en ciertas circunstancias, talves deba tener habilitado cgi para eso.
#8
Si, alguien dió de baja manualmente los registros NS que soportan los DNS principales de whatsapp que son x.ns.whatsapp.net y extrañamente whatsapp.net usa como servicio NS a whatsapp.net xD asi que si se cae no podrá resolverse a si mismo y provoca este tipo de problemas. Actualmente el registro NS de whatsapp.net consultado a a.ns.whatsapp.net aparece un registro vacío, asi que alguien lo eliminó manualmente.
#9
Buscas algo asi?

dirname(((isset($_SERVER['HTTPS']) and ($_SERVER['HTTPS'] === true)) ? 'https' : 'http').'://'.$_SERVER['HTTP_HOST'].$_SERVER['SCRIPT_NAME']).'/'

También está el $_SERVER['PHP_SELF'] pero tiene XSS.

Por otro lado en ves de pegar las variables en el template mejor llamaría a una función que construya la ruta según opciones, por ejemplo:


<?php
function url($path '/') {
    return (((isset(
$_SERVER['HTTPS']) and ($_SERVER['HTTPS'] === true)) ? 'https' 'http').'://'.$_SERVER['HTTP_HOST'].$path;
}
?>


<a href="<?php=url('/test')?>">Test</a>


En el camino te encontrarás con mcuhos problemas, por ejemplo algunos filtrados para evitar el xss, saber si vas a tener lógica dentro de tus plantillas o no, etc. Lo que te recomiendo mejor es que uses un framework que ya tenga todo eso incluido como codeigniter.

Saludos.
#10
Dudas Generales / Re: Programar bot
21 Septiembre 2021, 19:50 PM
Vamos, has puesto el pie en el acelerador de a poco, primero querias saber como enviar un correo de manera automatizada, despues cada 10 segundos y ahora masivamente, despues vas a preguntar como hacer un bomber mail de spam?

Las técnicas de envío de correos masivos son muy complejas, hay empresas completas dedicadas solamente al envío de phishing ético masivo, campañas y cosas por el estilo, y poder llegar a la bandeja de entrada es todo un reto. No solo debes saber como enviar masivamente un correo, sino que también debes saber como el correo deba llegar a bandeja de entrada, deberás pasar el filtro de firmas dkim, registros dmark, registros dns inversos, ips de confianza, filtros nativos de cada proveedor de correos, sistemas de sandboxing, etc, talves logres enviar 100 correos en un minuto a una persona pero probablemente le llegen los dos primeros y el resto se vaya a spam o simplemente el servidor smtp te banee.

Si quieres hacer marketing existe el servicio de mailchimp, si quieres hacer phishing ético debes usar plataformas ya hechas para esos fines (pero son de pago y necesitarás contratos con las partes a quien deseas enviar el phishing), los cuales usan servidores de replicas con colas de trabajo y todo lo demás para gestionar las colas de envío secuenciales.

Saludos.