Ci sono altri modi per farlo. Dipende da chi pensi venga dopo la tua stringa di connessione e dal tipo di accesso e dai livelli di abilità che avranno. La stringa di connessione è lì, da qualche parte, non importa come provi a nasconderla.
Sapendo che la stringa di connessione potrebbe essere violata, presumo sempre che verrà violata e prendo precauzioni dall'altra parte.
Facciamo diverse cose sul server DB per assicurarci che, anche se la stringa di connessione è compressa, i dati siano ancora al sicuro.
- L'utente associato alla stringa di connessione ha praticamente zero autorizzazioni sul server. Le uniche autorizzazioni che hanno sono ESECUZIONE e CONTROLLO sullo SCHEMA che contiene le stored procedure.
- L'unico accesso di cui dispone il front-end è tramite stored procedure. Non consentiamo mai al front-end di inviare stringhe SQL.
- I dati sono conservati in uno schema separato rispetto agli eseguibili, nello schema DATA l'utente associato alla stringa di connessione ha autorizzazioni ZERO, non può guardarlo, annusarlo o toccarlo.
- Le procedure memorizzate delegano le autorizzazioni all'utente senza accesso che dispone di autorizzazioni sufficienti per eseguire il proc. (CON ESEGUITO COME 'Utente senza accesso')
Questo è tutto ciò che possiamo fare. Non abbiamo trovato un modo per impedire che la stringa di connessione venga esposta in qualche modo da qualche parte.
In risposta alla domanda che Alex ha posto di seguito. (troppo lungo per un commento)
Nota. Quanto segue è per MS SQL Server, può essere applicato ad altri sistemi DBMS ma non posso garantire per nessun altro.
Un database contiene uno schema, lo schema contiene oggetti di database come tabelle, viste, stored procedure. Lo schmea ti consente di isolare gli oggetti del database, ad esempio, se avevi un gruppo di tabelle che chiunque poteva vedere, allora potevano entrare in uno schema COMMON, se avevi informazioni sul libro paga che avevi bisogno di proteggere potresti mettere che in uno schema PAYROLL. È quindi possibile inserire diverse misure di sicurezza sullo SCHEMA in base al tipo di oggetti che si trovano al loro interno. Graficamente sembrano cartelle su un disco rigido e sotto di esse ci sono tutti gli oggetti di database che contengono. Quando accendi il tuo server, ci sono diversi schemi che vengono creati automaticamente. Quello con cui hai più familiarità sarebbe lo schmea DBO. Potresti non esserne a conoscenza se il tuo amministratore lo ha impostato come schema predefinito.
Quello che facciamo è inserire tutti i dati in un DATA schmea, questo significa che sono consentite solo le tabelle. Quindi, se avessimo un database sui salari, le tabelle di dati andrebbero in uno schema chiamato dataPayroll.
Una stored procedure è un blocco o blocchi di codice SQL che il server di database può eseguire quando viene chiamato. Può restituire una tabella di dati o un singolo valore. Pensalo come un metodo in C#.
Le stored procedure hanno input e restituiscono parametri utilizzati nel codice SQL. Le stored procedure paramatarizzate sono una solida difesa contro gli attacchi SQL Injection.
Il nostro protocollo afferma che le stored procedure e le viste sono tutte archiviate in uno schema preceduto da "prog". Quindi, nel caso del database del libro paga, tutti gli oggetti che non sono dati sono all'interno dello schema progPayroll.
L'utente definito dalla stringa di connessione dispone quindi solo delle autorizzazioni di controllo ed esecuzione sullo schema "prog". Ciò consente loro di chiamare la stored procedure. All'utente definito dalla stringa di connessione vengono negate tutte le altre autorizzazioni. A questo utente vengono negate anche TUTTE le autorizzazioni ovunque. Nella procedura Stored, l'autorizzazione per accedere ai dati è delegata a un utente NO LOGIN che dispone dell'autorizzazione per recuperare i dati dallo schema 'data' utilizzando il comando ESEGUI AS.
Non c'è sql nel front-end. Tutto ciò che i programmatori front end sanno è il nome delle stored procedure, i parametri, i tipi e i valori restituiti.
In questo modo, anche se l'attaccante riesce a estrarre la stringa di connessione dal tuo programma, ha ancora molto lavoro da fare per poter fare qualsiasi cosa al tuo database poiché l'utente che ha può solo eseguire una stored procedure.
Se non hai idea di cosa siano queste cose, allora hai davvero bisogno di un programmatore DB per configurare il tuo sistema per te.
