Mensajes

Código (python) [Seleccionar] Expandir

from PIL import Image
file = open('data').read()
pixels = tuple(eval(file))

image = Image.new('RGB', (929, 569))
image.putdata(pixels)
image.save("CTF_929x569.png")

Código [Seleccionar] Expandir

FLAG{EPIC_WIN_AL_PILPIL}

https://www.dropbox.com/s/agmiq6spbza2z76/CTF_929x569.png?dl=0

Hola.

Veo que el título dice WardGame. ¿Esto significa que todos los retos consisten en generar imágenes a partir de 1 archivo con datos?

Porque es la 1ra vez que veo sobre esto y no entiendo qué relación tiene con "red TOR" que es lo que menciona el enunciado

Hola.

Hace unos meses estuve pensando en una aplicación, la cual ofrecía un panel con diversas funcionalidades (frontend) para los clientes/usuarios de dicha aplicación. Y esta a su vez, tenía que comunicarse con una base de datos. Así que, por temas de seguridad, lo que acabe haciendo, fue una aplicación en C# (backend) que se comunicaba con la base de datos lanzando sentencias SQL contra ella, una API vaya.

Entonces, claro, mi duda está en que si podría saltarme este paso intermedio, y obviar la aplicación backend, ya que es un rollo implementarla.

Creo que es lo más común hoy en día.
Puedes aprovechar la misma API para desarrollar luego aplicaciones cliente en cualquier plataforma (web, desktop, móvil).

En lo que respecta a una aplicación móvil, aunque es posible, no es conveniente... ya que la aplicación tendría que establecer una conexión directamente a la BD y esto puede ser un proceso pesado.

Si se trata de una aplicación desktop, se puede hacer la conexión directamente como comentas. Hice esto en varias ocasiones en la universidad, pero nunca me puse a pensar seriamente en la seguridad.

Se me viene a la mente Firebase Databases y Firestore, que son servicios considerados como backend as a service.
Es posible desarrollar aplicaciones sin tener que programar un backend usando los SDK provistos por Firebase y aplicando reglas de validación (aquí hay un ejemplo de un chat que hice en 5 minutos por curiosidad tras ver todo el trabajo que ahorra).

Pero lo cierto es que, si se trata de aplicaciones que soportan operaciones importantes, lo más probable es que a final de cuentas se terminen escribiendo validaciones a nivel de servidor (usando Cloud Functions en el caso de Firebase).

Lo que se me ha ocurrido, desde que estoy en esta empresa, es que lo más común es usar procedimientos almacenados (Stored Procedures) [...].

Y he visto, que todas las aplicaciones, llaman a sus procedimientos almacenados [...] en el mismo frontend. Y sí lo hacen así supongo que será porque es seguro.

Y tiene lógica, ya que realmente tu no estás viendo la sentencia SQL que se está ejecutando, simplemente, el procedimiento almacenado te trae datos, o los inserta, pero de forma controlada.

Es decir, que un hacker, no podría borrar o alterar la base de datos a sus anchas, si no conociese los procedimientos almacenados. Y no tuviese los permisos correspondientes para cada ejecucción.

Con permisos me refiero a que si, el usuario el cual realiza la petición no tiene dentro de una tabla X (donde hay una columna que especifica su rango de permisos) la cual no tiene permisos, este no podría hacer nada.

Creo que  hoy en día se siguen 2 enfoques principales.
Muchas aplicaciones tienen la lógica principal y de forma exclusiva escrita sobre una tecnología backend.
Otras tienen gran parte de la lógica escrita a nivel de base de datos, usando Stored Procedures como comentas.
Creo que hay una tendencia de seguir lo primero para aplicaciones web, y lo 2do para aplicaciones de escritorio, aunque ciertamente sin importar la plataforma ambos caminos son viables, e incluso una mezcla de ambos.

La idea está en que dentro del mismo procedimiento almacenado, se llame a otro procedimiento almacenado, el cual haga comprobación de credenciales, de rango, etc etc (para el caso de lectura de datos sensibles, insertar, modificar, borrar o alterar la estrctura de tablas (esto último debería de hacerse desde la propia base de datos)).

[...]

- Invitado: Este solo tendria acceso a comprobar los credenciales en la tabla correspondiente. Una vez realizada la conexión se le devolveria una string de conexión como usuario. Y se le crearía una string de conexion en otra tabla la cual no tendria acceso.
- Usuario: Este tendria los permisos estandar de un usuario.
- Administrador: Si se requiriese que la propia aplicación tuviese un panel de administración, pues este seria el usuario de conexion a la base de datos.

No me mola el hecho de devolver strings de conexión. Lo que me gustaría sería, que al conectarse el usuario, se le devolviese un objeto con la conexión la cual solo podria usar desde esa propia sesión.

Qué bueno que mencionaste lo de usar una primera conexión con permisos de invitado, como requerimiento para poder establecer una 2da conexión con más permisos.

Sin ello, existiría la posibilidad (no estoy seguro del cómo, y creo que menos idea  tienen los usuarios finales, pero al ser tecnología client-side debe haber una forma; si sabes cómo, estaría genial que comentes más sobre esto) de sacar provecho a esta conexión que tiene permisos generales.

No creo que sea posible devolver un objeto como comentas. Es decir, no creo que la comunicación con una base de datos o incluso la comunicación con una API funcionen de esa manera.

Ellos devuelven información, que dependiendo del lenguaje y las bibliotecas usadas, se interpretan como objetos o como tipos de datos primitivos... pero creo que la conexión debe establecerse de todas maneras (porque implica algo que ocurre a nivel de red, y un 3ro no puede establecer una conexión por ti).
Que el objeto "conexión" se cree en la BD o en la API y se devuelva funcionando no se puede, y que se devuelva listo para usar, creo que no tiene sentido.
Para esto último, la BD o la API tendrían que conocer detalles técnicos de la aplicación cliente, a fin de devolver bits que se puedan interpretar exactamente como un objeto en el instante en que se recibe.
Pero a final de cuentas, ese objeto tendría que contener el string de conexión, por lo que sería lo mismo.

Lo siento si he aportado más dudas que respuestas jeje.
Me ha parecido una pregunta muy interesante. Veamos si alguien más se anima a compartir su opinión.

Hola.

Si queres capturar los paquetes que te llegan a vos mismo con wireshark, como tu navegador tiene la clave para descifrar el contenido https, podes simplemente exportarla del navegador e importarla a wireshark, para ver en plano el contenido, pero solo de los paquetes que te corresponden a vos.

¿De casualidad has probado Fiddler o Graylog? No estoy seguro si permiten hacer lo mismo o si uno de ellos va más allá.

Hace un tiempo tenía que desarrollar un "programa" para enviar mensajes automáticos vía Facebook usando como entrada mensajes aleatorios y una lista de IDs (usuarios Fb).

Aunque usaba la Dev Tools no conseguía comprender bien qué es lo que ocurría porque Fb tenía mucho código ofuscado y realmente veía muchas peticiones que me resultaba difícil seguirle el ritmo.

Una persona me ayudó y pudo automatizar esto (1ra vez que solicité ayuda en un marketplace por cierto).
Usó C#... pero más allá del lenguaje, lo importante es que pudo encontrar 1 token que siempre usa Fb al enviar mensajes, y los nombres de los parámetros.
Vi que esta persona usaba Fiddler. Entonces, más allá del navegador vi que analizaba el tráfico en general de su PC y usaba unos filtros para facilitar la búsqueda.

Me sorprendió un poco. No he intentado hacerlo por mí mismo... pero con la existencia de herramientas de este tipo, es probable que ya sea capaz... aunque no sé si pueda hacerlo con la misma habilidad que esta persona.

Ahora si queres hacer un ataque MITM, ya sea ARP spoofing, o cualquier otro, y querer capturar y descifrar los paquetes de otros dispositivos pertenecientes a tu red LAN, ahí no vas a poder... Hubo muchas técnicas descubiertas para romper SSL/TLS, pero son técnicas del pasado, que fueron descubiertas, usadas por un período de tiempo muy corto y luego parchado tanto en los navegadores como en los servidores.

Hace un tiempo hice un juego Android con Firebase.
Apliqué algunas reglas de validación básicas para que no sea muy sencillo "hackearlo" incluso conociendo las peticiones.
Con CloudFunctions el servidor realizaba algunas validaciones extras. No fui muy minucioso, porque total, no es que tuviera muchos usuarios jugando en esta app.

El tema es que una persona se asignó puntaje 9999999999 y hacía que la app se cierre. Tuve que cambiar el tipo de dato que guardaba el score de int a float y agregar validaciones para registringir el score máximo.
También pensé en una estructura para la BD no relacional que permitiera que el ranking se calcule únicamente sobre las "jugadas" realizadas en las últimas 48  horas.

La cosa es que una persona pudo modificar su puntaje.
Hace poco probé Charles, instalé un certificado en 1 emulador y configuré un proxy, para que capte todas las peticiones, incluyendo las que van sobre https.
Me llamó la atención el hecho de encontrar una conexión websocket abierta (con relación a Firebase), donde se podía identificar un ApiKey, el ID del proyecto y las rutas consultadas (tras revisar con detenimiento).
No supe cómo enviar 1 mensaje a través de esa conexión abierta para incrementar mi puntaje... pero imagino que debe ser posible de alguna forma.

Aunque no puedo analizar el tráfico de alguien que está en mi red (como comentas), analizar el tráfico de cualquier aplicación que uso, es algo que me deja pensando ...
Deben haber muchas aplicaciones allá afuera que se puedan manipular fácilmente por no estar correctamente validadas.
Acceder a información que supuestamente no debe ser pública, o modificar datos que se supone deben entregarse únicamente al cumplir validaciones client-side; me parece emocionante.

A todo esto, creo que la única forma de hacer un juego seguro sería replicando la misma lógica que ocurre a nivel de cliente, en el servidor. Es un trabajo inmenso, pero creo que necesario.
En la app simple que hice, al acabar de jugar, se envía información del puntaje ganado. Esto hace posible que cualquiera pueda engañar al servidor que obtuvo un puntaje inmenso, o incluso un puntaje coherente tras muchas partidas que nunca existieron.
Tendría que ser un juego completamente online para que no sea fácil de vulnerar.

Sé que no es del todo legal pero, si nos tomáramos un tiempo de analizar cada sitio que visitamos, cada aplicación que usamos, podríamos encontrar cosas que muchos no ven y sacar provecho de alguna manera, sin afectar a otros.
Mi conocimiento es casi nulo en cuanto a técnicas para vulnerar y criptografía... pero si con lo poco que sé, veo que se pueden lograr muchas cosas, no quiero imaginar todo lo que son capaces de hacer ustedes jaja.

Por otro lado está esto de las 7 capas del modelo OSI. No recuerdo muy bien los detalles de cada capa, pero lo más probable es que sólo estemos en uno o 2 niveles, verdad?
Imagino que deben existir vulnerabilidades en todos los niveles .

Puedes seguir este orden:
- Aprender conceptos sobre bases de datos relaciones
- Modelar bases de datos a modo de práctica
- Conectar aplicaciones a 1 BD (sea web o desktop)
- Aprender sobre BD no relacionales

Hace un tiempo publiqué unos tutoriales sobre estos temas.
Los conceptos siguen siendo son los mismos.

Si te interesa los puedes seguir desde aquí.

Saludos.

[...] es hora de dejar de usarlo para cualquier chorrada como seleccionar un elemento del DOM, tirar AJAX, cambiar una clase css, mostrar/ocultar elementos [...]

Exacto.

Hace unos años usaba JQuery para hacer todas estas cosas, pero ahora ya no hay necesidad de ello, porque el mismo lenguaje lo permite y de forma muy sencilla.

Si es un proyecto nuevo, generalmente busco una plantilla o un kit que cubra la parte de diseño. Si la plantilla no incluye JQuery, lo más probable es que no lo termine incluyendo.
Pero si hay alguna dependencia que lo necesita, tampoco es que busque la manera de retirar JQuery, porque creo que es un esfuerzo en vano.
Además, muchas plantillas ahora sólo incluyen el núcleo de JQuery, con lo mínimo necesario para guardar compatibilidad (si no me equivoco, a esto se refiere con standalone el compañero !drvy).

Creo que los proyectos nuevos tienen una tendencia a no usar JQuery... pero aquellos que ya existen, generalmente no están dispuestos a invertir tanto para lograr la transición. De sobreescribirse todo el frontend, seguro que optarían por algo como React, Angular o Vue, dejando de lado JQuery; pero esta decisión no es fácil de tomar, sobretodo si es un proyecto grande (donde es más probable que se decida hacer la transición progresivamente).

Hola.

Probablemente desarrollo web sea lo más comercial.

Yo tuve también mucha intención de dedicarme al desarrollo de juegos en un inicio, pero finalmente he terminado desarrollando apps web y móviles.

He hecho alguno que otro juego en estas plataformas pero como proyectos encargados y de corto plazo... nada del otro mundo.

También publiqué un par de apps en las stores a modo de hobbie, pero no he tomado aún la decisión de dedicarme a ello de lleno ya que implica muchos riesgos a nivel económico.

Lo más importante cuando empiezas es practicar ejercicios sobre algoritmos.
Puedes empezar por Python como sugiere @konniskatt.

Yo empecé con C++ y aprendí las bases de POO leyendo "Thinking in cpp".
Por aquel entonces trataba de aprender tanto inglés como C++ mismo.

El inglés te ayudará muchísimo cuando ya tengas más experiencia y estés próximo a laborar.

  Muy buena sugerencia Alberto.

15 años es mucha experiencia... creo que sólo usé C++ unos 5 meses, pero es todo un gusto que haya sido el 1er lenguaje que vi.

Muchas gracias.

Entonces distinto sería que en un proceso se inicien varios hilos e intenten acceder a lo mismo, ¿verdad?

¿Qué pasa cuando 2 procesos acceden en paralelo a la misma posición de memoria e intentan modificarla?
Me parece que habían formas para resolver estos conflictos, pero de forma resumida, ¿cuál sería una respuesta concisa en una entrevista de trabajo?

El HTTPS se encarga de cifrar el canal de comunicacion, el cual te ofrece una capa adicional de seguridad ante miradas indiscretas.

Pero OJO nada es seguro, porque igual un MITM puede capturar tu emparejamiento del servicio https y ya sabra las credenciales.

Gracias por responder.

Si alguien revisa el tráfico, y no hay presencia de HTTPS, verá el token y podrá usarlo (hasta que caduque). Pero si llegó a ver la 1ra petición (cuando no había token), ya tiene las credenciales. ¿Es correcto?

Es decir si alguien está viendo las peticiones, el hecho de usar token solo reduce la probabilidad de que vea las credenciales (por ser usadas solo en la 1ra petición). No hace nada más que eso.