Modifica dei valori del modulo client di Windows in fase di runtime

Prima di tutto, risposta diretta alla tua domanda specifica: dai un'occhiata a DDE , questo può causare il modulo VB cambiare quasi tutto in fase di esecuzione.

Tuttavia, ho una risposta migliore per te:
Le probabilità sono che l'app client VB non stia utilizzando un protocollo crittografato (come SSL): puoi semplicemente intercettare le comunicazioni di rete e alterarle sul filo. Oppure, crea i tuoi messaggi e inviali direttamente al server. È un po 'complicato, ma non troppo difficile. O semplicemente usa qualcosa come OllyDbg per afferrare i dati prima che scende ai fili. (Comunque, anche se cifrano il canale dovresti essere in grado di aggirare il problema, dal momento che è crittografato sul tuo client. È un po 'più complicato, ma non troppo difficile. E se vai su OllyDbg la crittografia del canale è irrilevante.)
In questo modo sarà possibile eseguire la tua SQL Injection, e nemmeno troppo difficile.

Ora, ho una risposta ancora migliore per te - non preoccuparti nemmeno di SQL Injection.
È molto probabile, data l'architettura semplicistica che era comune nelle app VB6, che l'app client comunichi direttamente con il database. (Nella remota possibilità che ci sia un'app server intermedia, questa parte non ti aiuterà).
Se questo è il caso, significa che da qualche parte nell'app client (possibilmente codificata), ci sono le credenziali per accedere direttamente al database. (Se non riesci a trovarli, prendili usando le tecniche precedenti).
Una volta ottenute queste credenziali, è sufficiente accedere direttamente al database, utilizzando lo strumento di gestione del fornitore del database e seguire la procedura. L'app non ha bisogno di essere a modo tuo a tutti.
Non solo puoi fare tutto ciò che vuoi con i dati e le tabelle, non ci sarà modo di risalire a te. In effetti, è altamente improbabile che sia possibile dimostrare che qualcuno ha fatto qualcosa di sbagliato ... (beh, ad eccezione dei dati mancanti ...)

Le preoccupazioni per un'applicazione Windows compilata che parla direttamente al database sono leggermente diverse rispetto a quelle di un'applicazione web. Come fai notare nel tuo secondo paragrafo, il controllo degli accessi è il vero problema qui. Perché passare al problema di manipolare il programma o la memoria del client se si può parlare direttamente al database? Nella revisione / auditing di questo tipo di applicazione, vorrei accertarmi che i seguenti elementi siano presenti in qualsiasi checklist in uso; tutti questi aspetti riguardano anche le app Web, ma questi elementi sarebbero di particolare interesse per un'app che comunica direttamente con il DB:

1. Esiste una traccia di controllo di chi ha effettuato l'accesso (e fuori) e quando, e da dove e quali modifiche hanno apportato? Questo è cruciale soprattutto dove ci sono potenziali problemi con il controllo degli accessi (che, ancora una volta, come lei sottolinea, è il vero problema). Questo tipo di controllo non è stato storicamente un punto di forza per la maggior parte dei server di database non aziendali, ma la maggior parte dei RDBMS ha incluso i trigger come funzionalità per un certo periodo di tempo, che può essere sfruttato per creare percorsi di controllo senza richiedere alcun codice aggiuntivo nell'applicazione. Trigger e stored procedure possono essere utilizzati anche per il retrofit del controllo su app legacy che non sono state pensate, ma questo deve essere fatto con attenzione, come alcune vecchie app, come quelle che usano DAO per l'accesso ai dati, dato che si parla di VB6 - può essere rovinato dai trigger in vari modi, come restituire l'insertID del record di controllo generato dal trigger piuttosto che la riga creata che ha attivato il trigger.

2. La comunicazione con il DB è crittografata? Per un'app interna, un certificato autofirmato o uno di una CA locale andrebbe spesso bene, ovviamente per le app rivolte al pubblico o ad alto rischio sarebbe preferibile un certificato di un'autorità attendibile e potrebbero essere considerati certificati client e server. pure. È abbastanza facile capire se c'è un qualche tipo di crittografia usando Wireshark, che tra le altre cose ti consentirà di vedere non solo i dati effettivi restituiti, ma ogni singola istruzione SELECT, INSERT, UPDATE e DELETE utilizzata dall'app se la connessione non è crittografata.

3. Le password degli utenti sono memorizzate nel DB? Se è così, sono in chiaro, o hash e salati? IMHO, idealmente, l'applicazione non memorizza o gestisce affatto le password e si sta invece autenticando contro LDAP, Active Directory o altri sistemi di autenticazione / gestione degli utenti che non implicano l'archiviazione delle password negli stessi utenti DB che utilizzano e abusano. Tuttavia, se sono archiviati nel DB, blah blah blah utilizza solo bcrypt . :) Potresti anche vedere alcuni sviluppatori tentare di inserire password o chiavi nel programma client per aggirare questo problema (ovvero nascondere alcuni o tutti i dettagli di autenticazione dell'utente per cercare di impedire loro di connettersi al DB all'esterno del database). app), ma questa è generalmente considerata una pessima idea.

4. Infine, un buon approccio al problema del controllo degli accessi in questa istanza (senza ricorrere a una soluzione proxy o middleware) sta negando completamente l'autorizzazione degli utenti alle tabelle e abilitando solo le stored procedure che accettano parametri e restituiscono , creare o modificare le righe appropriate. Questo ammette lo sviluppo più complicato e può ancora essere abusato (vorresti assolutamente assicurarti che qualsiasi cosa l'utente immetta direttamente nell'app sia parametrizzata / disinfettata), ma se l'utente ha piena autorizzazione sulle tabelle direttamente, questo è l'ultima delle tue preoccupazioni: non è necessario sfruttare l'app per ottenere l'accesso o il permesso di provocare il caos (in quanto dovrebbero sfruttare un'app Web in una vulnerabilità di SQL injection) perché possono farlo direttamente.

Per sapere se un menu a discesa deve essere disinfettato allo stesso modo di una casella di testo (che era l'essenza della domanda originale, dopotutto), direi se non stai utilizzando altre misure come la quelli sopra, è come chiedere se è necessario bloccare la finestra al piano di sopra quando la porta principale è spalancata e ogni utente ha una chiave per il cancello.