Cambiar los valores del formulario del cliente de Windows en tiempo de ejecución

En primer lugar, responda directamente a su pregunta específica: eche un vistazo a DDE , esto puede causar el formulario VB Para cambiar casi cualquier cosa en tiempo de ejecución.

Sin embargo, tengo una mejor respuesta para ti:
Lo más probable es que la aplicación cliente de VB no esté utilizando un protocolo cifrado (como SSL): puede interceptar las comunicaciones de la red y modificarlas por cable. O simplemente cree sus propios mensajes y envíelos al servidor usted mismo. Es un poco incómodo, pero no demasiado difícil. O simplemente use algo como OllyDbg para capturar los datos antes que vayan a los cables. (Por cierto, de todos modos, incluso si cifran el canal, debería poder evitarlo, ya que está cifrado en su cliente. Es un poco más complicado, pero no lo es tanto. Y si opta por OllyDbg, el cifrado del canal es irrelevante.)
De esta manera, será posible realizar su inyección SQL, y ni siquiera será demasiado difícil.

Ahora, tengo una respuesta aún mejor para ti, ni te preocupes por la inyección SQL.
Es muy probable que, dada la arquitectura simplista que era común en las aplicaciones VB6, su aplicación cliente se comunique directamente con la base de datos. (En la posibilidad de que haya una aplicación de servidor intermedio, esta parte no te ayudará). Si ese es el caso, eso significa que en algún lugar de la aplicación cliente (posiblemente codificada), hay credenciales para acceder directamente a la base de datos. (Si no puedes encontrarlos, cógelos usando las técnicas anteriores).
Una vez que tenga estas credenciales, solo vaya directamente a la base de datos, use la herramienta de administración del proveedor de la base de datos y continúe con su tarea. La aplicación no necesita estar en tu camino en absoluto.
No solo puede hacer lo que quiera con los datos y las tablas, sino que no habrá forma de rastrearlo. De hecho, es muy poco probable que sea posible demostrar que alguien hizo algo malo ... (bueno, excepto por los datos que faltan ...)

La preocupación por una aplicación compilada de Windows que se comunica directamente con la base de datos es un poco diferente a la de una aplicación web. Como señala en su segundo párrafo, el control de acceso es el verdadero problema aquí. ¿Por qué molestarse en manipular el programa cliente o la memoria si puede hablar directamente con la base de datos? Al revisar / auditar este tipo de aplicación, me aseguraría de que los siguientes elementos se encuentren en la lista de verificación que esté utilizando; todo esto también es una preocupación para las aplicaciones web, pero estos elementos serían de particular interés para una aplicación que se comunique directamente con el DB:

1. ¿Hay un registro de auditoría de quién inició sesión (y cuándo), cuándo y desde dónde y qué cambios hicieron? Esto es crucial, especialmente cuando hay problemas potenciales con el control de acceso (que, nuevamente, como se señala es el problema real). Este tipo de auditoría no ha sido históricamente una fortaleza para la mayoría de los servidores de bases de datos no empresariales, pero la mayoría de los RDBMS han incluido disparadores como una característica por algún tiempo, que se puede aprovechar para crear pistas de auditoría sin necesidad de ningún código adicional en la aplicación. Los activadores y los procedimientos almacenados se pueden usar incluso para adaptar la auditoría a las aplicaciones heredadas que no se crearon teniendo en cuenta esto, pero esto debe hacerse con cuidado, ya que algunas aplicaciones antiguas, como las que usan DAO para el acceso a datos, como usted menciona VB6 - se puede atascar por disparadores de varias maneras, como devolver el ID de inserción del registro de auditoría generado por el disparador en lugar de la fila creada que disparó el disparador.

2. ¿La comunicación con la base de datos está encriptada? Para una aplicación interna, un certificado autofirmado o uno de una CA local a menudo estaría bien, obviamente para aplicaciones públicas o de alto riesgo se preferiría un certificado de una autoridad confiable, y los certificados de cliente y el servidor podrían considerarse también. Es bastante fácil saber si hay algún tipo de cifrado con Wireshark, que entre otras cosas le permitirá ver no solo los datos reales devueltos, sino también todas y cada una de las declaraciones SELECT, INSERT, UPDATE y DELETE utilizadas por la aplicación si la conexión no está encriptada.

3. ¿Las contraseñas de los usuarios están almacenadas en la base de datos? Si es así, ¿están en texto plano, picado y salado? En mi humilde opinión, lo ideal es que la aplicación no almacene ni administre contraseñas en absoluto, sino que se autentique contra LDAP, Active Directory o algún otro sistema de autenticación / administración de usuarios que no implique almacenar contraseñas en el mismo uso y abuso de la base de datos. Sin embargo, si están almacenados en la base de datos, blah blah blah realmente solo usa bcrypt . :) También puede ver algunos intentos de los desarrolladores de ingresar contraseñas o claves en el programa cliente para solucionar este problema (es decir, ocultar algunos o todos los detalles de autenticación al usuario para intentar impedir que se conecten a la base de datos fuera de la base de datos). aplicación), pero esto generalmente se entiende como una idea muy mala.

4. Por último, un buen enfoque del problema de control de acceso en esta instancia (sin recurrir a una solución de proxy o middleware) es negar el permiso de los usuarios a las tablas por completo, y solo permite el permiso para procedimientos almacenados que aceptan parámetros y devuelven , crea, o modifica las filas apropiadas. Es cierto que esto hace que el desarrollo sea más complicado, y aún se puede abusar de él (todavía querrá asegurarse de que todo lo que el usuario ingresa directamente en la aplicación esté parametrizado / saneado), pero si el usuario tiene permiso completo sobre las tablas directamente, esto es la menor de sus preocupaciones: no necesitan aprovechar su aplicación para obtener acceso o permiso para causar estragos (ya que necesitarían aprovechar una aplicación web en una vulnerabilidad de inyección de SQL) porque pueden hacerlo directamente.

En cuanto a si un menú desplegable debe ser desinfectado de la misma manera que un cuadro de texto (después de todo, era la esencia de la pregunta original), diría que si no está empleando otras medidas como la los de arriba, es como preguntarle si debe cerrar la ventana del piso de arriba cuando la puerta de entrada está completamente abierta y cada usuario tiene una llave de la puerta.