This site uses cookies own and third. If you continue to browse consider to accept the use of cookies. OK More Info.

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - WHK

Pages: [1] 2 3 ... 8
1
You are not allowed to view links. Register or Login

Esto sucede principalmente debido a que SAP utiliza de manera nativa una versión vulnerable de Log4J, específicamente aquella que es vulnerable a la ejecución de código remoto debido al mal manejo del interpretador JDNI (CVE-2021-44228 o Log4Shell).

* CVE-2021-44228 de severidad crítica, con una puntuación CVSS3 de 10. Esta se debe a un fallo en las características de configuración JDNI, el cual no valida los parámetros de entrada de los mensajes o parámetros de los logs. Esto permitiría a un atacante acceder a permisos de configuración y control de los logs con el objetivo de realizar ejecución remota de código (RCE) en el sistema afectado.

* CVE-2022-24396 de severidad crítica, con una puntuación CVSS3 de 9.3. Esta vulnerabilidad se debe a un fallo en el componente de diagnóstico que permitiría a un atacante autenticado con mínimos privilegios realizar un escalamiento de privilegios u obtener información sensible.

* CVE-2022-26101 de severidad alta, con una puntuación CVSS3 de 8.2. Esta vulnerabilidad se debe a una falla en un componente desconocido el cual no valida los datos de entrada del usuario. Esto permitiría a un atacante enviar peticiones maliciosas con el objetivo de ejecutar código JavaScript (XSS).

No confundir que la vulnerabilidad Log4Shell (CVE-2021-44228) sea relativamente antigua, esto no quiere decir que algunos software aun hagan uso de el como es en el caso de SAP, en otras palabras, SAP cuenta con la vulnerabilidad reciente de que incluye este componente vulnerable.

Este riesgo es preocupante debido a que un atacante que logre acceder al servicio de SAP sin la necesidad de autenticarse podría ejecutar comandos dentro del servidor donde se encuentre esta solucón.

Pero, ¿esto quiere decir que si se encuentra dentro de una red local el riesgo disminuye?: la respuesta es si pero no lo suficiente. A lo largo de los años se han habido presedentes de ataques realizados por personal interno en diferentes compañías grandes y pequeñas en Chile y tampoco son casos aislados, este tipo de incidencias ocurren con mayor frecuencia de lo pensado.

Los desastres no curren sin más, son el resultado de una serie de sucedos que conllevan a una incidencia de proporciones mayores que pueden afectar no solamente a la contabilidad de una compañía sino también a posibles problemas legales y de pérdida de imagen corporativa.

Técnicamente hablando un atacante podría realizar una solicitud HTTP al servidor de SAP y enviar un paquete malicioso con código de ejecución, permitiendo al atacante, por ejemplo conectar a la base de datos y modificar información como credenciales de acceso o datos de contabilidad, también podría descargar software malicioso de tipo Troyano y tomar control del servidor o infectar la infraestructura con malware de tipo Ransomware.

Primero que nada esta vulnerabilidad ha sido solucionada hace muy poco, asi que la recomendación es muy clara, se debe actualizar el Software vulnerable lo antes posible para evitar una incidencia mayor.

La actualización de un Sistema no solamente cuenta con cambios a nivel de experiencia de usuario sino también de seguridad, por eso se recomienda mantener los sistemas y aplicaciones siempre actualizados.

Como segunda medida, como esta vulnerabilidad puede ser aprovechada de manera remota, se recomienda realizar un análisis de sistema o forense a la brevedad para determinar sin en la actualidad existió algún ataque que haya podido afectar a los datos confidenciales de los correos almacenados, si este fuese el caso se recomienda activar un procedimiento de seguridad para el cambio de credenciales de manera masiva de los sistemas de la compañía.

Fuente: You are not allowed to view links. Register or Login

2
El único problema es que bugcrowd tiene una pésima moderación, muy dificilmente dan una vulnerabilidad como válida, a pesar de que el vendor asuma el problema. Si estuviera en hackerone sería otra historia.

3
You are not allowed to view links. Register or Login

Se publicó un problema de seguridad crítico en Mozilla Firefox 97.0.2 el cual permite la ejecución de código remoto, esto quiere decir que con tan solo visitar un sitio WEB malicioso, un atacante podría ejecutar comandos en el Sistema Operativo ya que esta vulnerabilidad también impacta en el mecanismo de seguridad de Sandboxing que protege al navegador frente a la ejecución de código.

Un usuario podría exponer todos sus datos de usuario tales como contraseñas, sesiones guardadas y datos de otras aplicaciones instaladas en el Sistema Operativo.

Mozilla ha categorizado dos vulnerabilidades asociadas con los siguientes nombres:

* CVE-2022-26485: Use-after-free in XSLT parameter processing
* CVE-2022-26486: Use-after-free in WebGPU IPC Framework

Esta vulnerabilidad aun se encuentra en entrega del puntaje CVSS, pero de todas maneras se ha confirmado la ejecución remota de código, por lo cual cabe esperar que su puntaje sea muy alto, muy cerca de 9.0 o 10.0.

Esta vulnerabilidad tiene dos impactos directos, uno se refiere a que es posible ejecutar comandos del lado del equipo del usuario y el otro es la posibilidad de escapar de la Sandbox de Mozilla Firefox, pero ¿a que se refiere?.

Ejecución de código: Use-after-free es un tipo de vulnerabilidad categorizado por la CWE que consiste en la reutilización de un puntero en memoria después de haber sido limpiada, este problema puede llevar a un atacante a inyectar bytes en memoria dentro del Sistema Operativo e indicar la ejecución de algún comando como por ejemplo el Bash del Sistema en Linux, Powershell en Windows y similares. Esto podría causar por ejemplo que un atacante indique al navegador WEB de Mozilla Firefox que descargue un ejecutable malicioso y lo ejecute sin previo aviso o consentimiento del usuario.

Evasión de la sandbox: Para evitar este tipo de problemas todo navegador WEB moderno cuenta con un mecanismo de protección de Sandboxing el cual consiste en la aislación (siolación) tanto de la memoria como del proceso, en otras palabras, cada pestaña se ejecuta en un Worker diferente, de esta manera una vulnerabilidad dentro de un proceso dificilmente podría escalar a ejecutar algo dentro del mismo Sistema Operativo, pero este mecanismo de seguridad también fue evadido. Hay que recordar que los mecanismos de Sandboxing son únicamente sistemas mitigantes que intentan evitar problemas de seguridad pero no corrigen los problemas de raiz, por lo cual es muy normal ver en distintas ocasiones como estas sandboxing son evadidas en distintos navegadores WEB.

La conclusión es que un atacante podría crear un sitio WEB malicioso o simplemente hackear alguno ya existene e ingresar y código que al ser visitado podría hacer que el usuario se infecte con un malware, por ejemplo, un Ransomware o Troyano, el cual permite al atacante tomar control y manipular el equipo de la víctima y hacer robo de información como contraseñas y datos de tarjetas bancarias.

Fuente: You are not allowed to view links. Register or Login

4
You are not allowed to view links. Register or Login

Se publicó un problema de seguridad crítico en Microsoft Exchange 2019 el cual permite la ejecución de código remoto, esto quiere decir que un atacante desde internet tiene la posibilidad de acceder a la información interna del servicio de correos, modificar o eliminar información, también podría ejecutar comandos sin autorización dentro del Sistema Operativo.

Desde Microsoft indican que ya existe una prueba de concepto que permite explotar esta vulnerabilidad, por lo cual pueden existir atacantes que ya lo estén aprovechando en servidores vulnerables.

El título de la vulnerabilidad indica que es posible la ejecución de código, pero ¿cómo es esto posible?: Realmente no es un problema de desbordamiento de memoria o un puntero mal gestionado, sino mas bien de elevación de privilegios debido a un problema en el control de la autorización de ciertas funcionalidades que permiten a un usuario sin privilegios tener un rol máximo permitiendo así realizar cambios sobre la consola de configuración de Microsoft Exchange y ejecutar comandos de manera directa sobre el Sistema Operativo que lo aloja.

Por lo cual ¿que podría hacer un atacante con esto?: Básicamente acceder a cualquier información alojada en el servidor ya que debemos recordar que Microsoft Exchange tiene la pésima práctica de seguridad de utilizar un usuario con privilegios elevados dentro del Sistema Operativo (NT AUTHORITYSYSTEM), en ves de ejecutarse con algún usuario restringido únicamente para Microsoft Exchange. Esto permite que un atacante no solo pueda acceder a los datos alojados sino también intentar acceder a otros servidores dentro de la misma red impactando así a la infraestructura de la compañía.

Debemos recordar también que en muchas ocaciones se envían contraseñas y documentos confidenciales por correo electrónico y todos estos datos pueden serse afectados, más aun cuando estas contraseñas son reutilizadas en otros sistemas, los cuales permitan a un atacante tomar control de toda la infraestructura de la compañía como por ejemplo, el Active Directory.


Recomendaciones a los usuarios

Primero que nada esta vulnerabilidad ha sido solucionada hace muy poco, asi que la recomendación es muy clara, se debe actualizar el Software vulnerable lo antes posible para evitar una incidencia mayor.

La actualización de un Sistema no solamente cuenta con cambios a nivel de experiencia de usuario sino también de seguridad, por eso se recomienda mantener los sistemas y aplicaciones siempre actualizados.

Como segunda medida, como esta vulnerabilidad puede ser aprovechada de manera remota, se recomienda realizar un análisis de sistema o forense a la brevedad para determinar sin en la actualidad existió algún ataque que haya podido afectar a los datos confidenciales de los correos almacenados, si este fuese el caso se recomienda activar un procedimiento de seguridad para el cambio de credenciales de manera masiva de los sistemas de la compañía.

Como última recomendación, se debe recordar que el correo electrónico no es un canal 100% seguro, por lo cual se debe evitar el envío de credenciales o información crítica a traves de este medio, pero en caso contrario se recomienda eliminar estos correos al momento de recibirlos y realizar un limpiado periódico de los posibles mensajes que pudiesen ser perjudiciales en una filtración de datos.

Fuente: You are not allowed to view links. Register or Login

5
Hola, cual es el error o problema que genera? tienes el mensaje de error? o se queda en blanco?, por lo general el mismo arranque de linux te dice cual es el problema y con ese identificador se puede buscar la posible solución. Hasta ahora no he sabido que linux tiene problemas con los procesadores amd, por lo contrario, en muchas comunidades linux recomiendan usar cpu amd en ves de intel por temas de compatibilidad.

6
Dudas y pedidos generales / Re: Páginas de paga
« on: November 02, 2021, 07:44:33 pm »
Hola, no se entiende bien, pero ¿que datos te refieres?, datos de la base de datos?, del código fuente?, de archivos?, de que lugar?. El sitio es tuyo? o quieres vulnerar un sitio que no es tuyo y robarle su información?

7
Dudas y pedidos generales / Re: HTML con css y js
« on: November 01, 2021, 05:51:38 pm »
Muy facil, agrega un padding al body de la altura igual al buscador y pon el buscador con tu position fixed al inicio de la página, esto hará que la pagina web no pueda subir mas allá que el mismo buscador.

Saludos.

8
Otros lenguajes / Consultoría - Cómo solucionar un XSS
« on: November 01, 2021, 05:29:54 pm »
Bienvenidos Underc0ders!. 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 ocaciones 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 ( You are not allowed to view links. Register or Login ) y la CWE ( You are not allowed to view links. Register or Login ) 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 You are not allowed to view links. Register or Login ) 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 ( You are not allowed to view links. Register or Login ) y no 79 ( You are not allowed to view links. Register or Login ), 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.

Entonces, ¿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 ( You are not allowed to view links. Register or Login ) 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í:

Code: You are not allowed to view links. Register or Login
"Palabra acá"
¿Que sucede si el valor de esta palabra contiene una comilla doble?

Code: You are not allowed to view links. Register or Login
"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á

Code: You are not allowed to view links. Register or Login
"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:

Code: You are not allowed to view links. Register or Login
"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! ( You are not allowed to view links. Register or Login ).

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:

Code: You are not allowed to view links. Register or Login
<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:

Code: You are not allowed to view links. Register or Login
"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: You are not allowed to view links. Register or Login , 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:

Code: You are not allowed to view links. Register or Login
<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 ( You are not allowed to view links. Register or Login ), 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:

Quote
A 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 ocaciones, 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.

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.

9
QA (Quality Assurance) / Re: Pruebas automatizadas con Postman
« on: November 01, 2021, 04:26:48 pm »
Para las pruebas automatizadas utilizo los mismos módulos de pruebas incluidas en las mismas aplicaciones y si no las tengo las fabrico en base al swagger o la documentación.

Muchas personas usan postman para documentar y testear las apis en diferentes ambientes y está bien, pero creo que para el trabajo de un proyecto estas pruebas deberían ir en el área de pruebas. Node, Java y similares ya tienen módulos para hacer este tipo de pruebas, por ejemplo Android Studio ya lo integra de manera nativa.

10
Dudas y pedidos generales / Re: Ayuda JSP
« on: October 31, 2021, 03:14:26 pm »
Realmente ya casi nadie programa directamente en jsp+servlet+jsf, son tecnologías que ya están casi obsoletas (hablando por la combinación completa).

Si vas a dedicarte a programar en java te recomiendo que comiences con el framework Spring Boot + Thymeleaf. En youtube hay un canal que me gusta mucho que se llama "Spring gurú" y hay muchisima información al respecto. Si tienes alguna duda la puedes ir haciendo en el mismo foro.

Una pregunta, ¿ya tienes conocimientos previos en programación?, porque utilizar Spring requiere del manejo de algunos conceptos que no son básicos, como separación de capas, perisstencia, modelamiento DTO, security y demás. De todas maneras en jsp+servlet tendrías que llegar a lo mismo pero de manera mas manual, en cambio el framework ya te ayuda mucho a estructurar y automatizar.

Saludos.

11
GNU/Linux / Re: Postea tu escritorio Linux
« on: October 31, 2021, 03:08:29 pm »

12
Zona Webmaster / [software] Módulo de Jinja2 para Apache Server
« on: July 02, 2021, 01:36:55 am »
You are not allowed to view links. Register or Login

Hola, muy buenas noches a todos, les traigo un proyecto que acabo de finalizar, se trata de un módulo escrito puramente en c para Apache Server que permite interpretar plantillas para Jinja2.

Los que no sepan que es Jinja2, es un sistema de templates ampliamente utilizado en proyectos sobre Python como por ejemplo, Django y Flask. La gran ventaja es que ya no necesitas utilizar ningún framework o hacer deploy de ningún servicio de python para publicar tus plantillas, gracias a este módulo las plantillas se cargan y se interpretan en memoria a bajo nivel sin utilizar ningún proyecto en python.

El proyecto se encuentra en este lugar: You are not allowed to view links. Register or Login

El proyecto es una mezcla de módulo para apache junto a la utilización de la API para C de Python, por lo cual el performance podría llegar a ser mucho mejor que la de php. Una ves instalado puedes crear plantillas utilizando archivos con extensión .j2 y olvidarte de utilizar Wordpress u otros sistemas CMS de alto coste en hardware, por ejemplo, un sitio meramente informativo con un puñado de módulos de slides y editores pesados te puede costar mas de 2GB de memoria RAM y la alta disponibilidad disminuye considerablemente, por otro lado, crear un sitio WEB únicamente utilizando archivos HTML te dará problemas como por ejemplo la redundancia de código ya que tendrás que escribir la cabecera, el footer, los menús, en cada archivo y se pierde escalabilidad ya que hacer una pequeña modificación en el diseño podría significar tener que modificar muchos archivos, pero con el módulo de Jinja2 es el intermedio entre versatilidad y eficiencia ya que creas archivos estáticos y a la ves con comportamiento dinámico ya que puedes hacer includes o realizar una única plantilla para todos tus demás archivos escritos puramente en HTML.

Acá les dejo un repositorio de ejemplo de un sitio WEB que utiliza este módulo: You are not allowed to view links. Register or Login

Su uso es totalmente libre, se aceptan sugerencias, la documentación aun no está 100% finalizada, aun debo documentar los módulos de python disponibles desde Jinja2, formato de extensiones, rutas de layouts, etc, pero si tienen alguna duda me la pueden ir haciendo en este mismo post. El módulo es 100% estable, probado, testeado y puesto en producción en alguno de mis servidores, comenzaré a migrar algunos sitios que tengo a puro html dinámico con este módulo.

Saludos.

13
Dudas y pedidos generales / Re: Al validar no me funciona el POST
« on: July 01, 2021, 02:51:00 pm »
Hola, reemplaza "$form.submit();" por "e.currentTarget.submit();" y nos cuentas.

Saludos.

14
Hola, que tal esto? You are not allowed to view links. Register or Login

Saludos.

15
Python / Re:Herramienta UrlScanner
« on: August 25, 2020, 03:28:32 am »
Hola, veo que utilizas muchisimas peticiones, deberías utilizar multithreading para acortar los tiempos de ejecución.

Saludos.

16
Python / Re:Geolocalizacion por IP
« on: August 25, 2020, 03:20:58 am »
Hola, estuve dandole un vistazo a tu módulo, deja darte algunos consejos:

Vi que tu proyecto requiere bs4, si quieres que tu proyecto lo instale de manera automática desde pip, debes crear un archivo llamado requirements.txt con el nombre del módulo y la versión, por ejemplo:

Code: You are not allowed to view links. Register or Login
beautifulsoup4==4.9.1
Por otro lado, ten bastante cuidado, esa librería no es muy facil de instalar, a demás de contar con la instalación desde pip también debes contar con las librerías de headers para su compilación, en algunos sistemas da bastantes dolores de cabeza.

También me pude fijar que haces uso de la función "raw_input" pro esta no existe, a demás, intentaste utilizar el coloreado para bash, pero eso no funcionará en terminales de windows, recuerda que python funciona en múltiples sistemas operativos y el usuairo sólo verá caracteres extraños. Si un usuario cancela el script, no hay razón para decirle que lo ha cancelado.

Mejor te recomiendo utilizar expresión regular:

Code: (python) You are not allowed to view links. Register or Login
#!/usr/bin/env python3
# -*- coding: utf-8 -*-

import requests
import re


class Controller():
 
    def __init__(self):

        # Header
        print('-> Programado Por Parker')

        ip = input('IP o enter para saber su localización: ').strip()
       
        print('Realizando la solicitud ...')

        response = requests.get('https://es.geoipview.com/?q=%s&x=0&y=0' % format(ip))
        if(response.status_code == 200):

            items = {
                'host'      : r'del\s+Host:.+?class="host">(.*?)<',
                'ip'        : r'de\s+IP:.+?class="show2">(.*?)<',
                'country'   : r'País:.+?<td>(.*?)<',
                'region'    : r'Región:.+?<td>(.*?)<',
                'city'      : r'Ciudad:.+?class="show2">(.*?)<',
                'postal'    : r'Postal:.+?<td>(.*?)<',
                'latitude'  : r'Latitud:.+?<td>(.*?)<',
                'longitude' : r'Longitud:.+?<td>(.*?)<'
            }

            print('-' * 27)
            for item in items:
                matches = re.search(items[item], response.text, re.I | re.M)
                print(
                    '%s : %s' % (
                        item.title().ljust(9), # Key name
                        matches.group(1).replace('&nbsp;', ' ').strip() if matches else '-'
                    )
                )

        else:
            print('Error de respuesta (%s).' % str(response.status_code))


if __name__ == "__main__":
    try:
        Controller()

    except KeyboardInterrupt:
        pass

    except Exception as e:
        raise e

Code: You are not allowed to view links. Register or Login
$ python3 test.py
-> Programado Por Parker
IP o enter para saber su localización: 64.233.186.138
Realizando la solicitud ...
---------------------------
Host      :
Ip        : 64.233.186.138
Country   : USA / US
Region    : CA
City      :
Postal    :
Latitude  : 34.054401397705
Longitude : -118.2440032959

Saludos.

17
Python / Re:Cliente muy simple para HackerTarget (MiniPentestTool)
« on: August 24, 2020, 02:00:30 pm »
Mira, lo reduje un poco y eliminé el bs4 porque realmente no lo necesita ya que la api utiliza texto plano y no html:

You are not allowed to view links. Register or Login

Code: (python) You are not allowed to view links. Register or Login
#!/usr/bin/env python3
# -*- coding: utf-8 -*-

import banner, requests


class HackerTargetIntegration():

    def __init__(self):

        banner.banner()

        methods = [
            'mtr',
            'nping',
            'dnslookup',
            'reversedns',
            'hostsearch',
            'findshareddns',
            'zonetransfer',
            'whois',
            'geoip',
            'reverseiplookup',
            'nmap',
            'subnetcalc',
            'httpheaders',
            'pagelinks'
        ]

        while(True):

            id = 0
            for method in methods:
                print('%d -> %s' % (id, method))
                id += 1

            method = input('>> ').strip()
            if(method and (int(method) <= len(methods))):
                self.req(methods[int(method)])
            else:
                print('El método no existe. Intente nuevamente.')


    def req(self, method):

        target = input('IP/Dominio objetivo: ')
        response = requests.get('https://api.hackertarget.com/%s/?q=%s' % (method, target))
        print(('-' * 20) + '\n' + response.text + '\n' + ('-' * 20) + '\n')



if __name__ == '__main__':

    try:
        HackerTargetIntegration()
   
    except KeyboardInterrupt as e:
        pass

    except Exception as e:
        raise e

A demás te voy a comentar algo para que lo apliques en tus futuros proyectos. Si te fijas, tu hiciste una separación distinta a la mia, tu hiciste una clase donde cada función se encarga de una tarea distinta (repetitiva pero distinta), esto te permitía ser utilizado por otras clases, pero yo en mi caso eliminé esa arquitectura por un código mas simple tomando en cuenta de que solo el usuario interactua con esa clase y no otros módulos o scripts. Tu concepto y el mio son dos conceptos totalmente diferentes y eso se debe a la separación por capas.

En tu caso, si querías hacer una clase modular tenías que haber separado la lógica de la clase con el script que lo ejecuta, en otras palabras, tu clase que hace todo el trabajo se llama capa de servicio y tu script principal tu controlador. Como vi que tu script completo era un controlador entonces lo resumí como controlador y no como módulo.

Si quieres puedes volver a crear las funciones y que estas funciones llamen a una única función encargada de hacer las solicitudes y luego la guardas como módulo y desde tu script principal que es el controlador haces la solicitud del input y llamas a la función de la clase por cada método disponible, y este listado de métodos debes obtenerlo desde el mismo array de la clase de servicio. Esto quiere decir: Que tendrás que crear una función por cada método a demás de tener una lista de métodos permitidos, de esta manera el controlador sabrá cuales métodos existen y evitarás tener que usar refracción para obtener el listado de funciones (algo inseguro y de no muy buena práctica) o mantener la función req con el método de manera dinámca más el listado de métodos permitidos. En este caso tendrás que hacer una validación antes de llamar al sitio web para preveer que el método no sea algo que el servcio web no soporte, crear excepciones tipo MethodNotFoundException, etc.

Saludos.

18
Python / Re:Cliente muy simple para HackerTarget (MiniPentestTool)
« on: August 24, 2020, 01:42:53 pm »
Hola, podrías reemplazar todas tus funciones de la clase con una sola más genérica, por ejemplo:

Code: You are not allowed to view links. Register or Login
def req(self, service):
        target = input("Target IP/Domain: ")
        r = requests.get("https://api.hackertarget.com/%s/?q=%s" % (service, target))
        soup = BeautifulSoup(r.text, 'lxml')
        funcion = soup.find_all('body')
        print(funcion[0].text)

Saludos.

19
Talves te interese leer este post:

You are not allowed to view links. Register or Login

Saludos.

20
Hola, claro, para eso necesitas encontrar tu propio 0Day porque actualmente todas las vulnerabilidades de facebook están corregidas.

Saludos.

Pages: [1] 2 3 ... 8