Det finns andra sätt att göra det på. Det beror på vem du tror kommer efter din anslutningssträng och vilken typ av åtkomst och färdighetsnivåer de kommer att ha. Anslutningssträngen finns där, någonstans, oavsett hur du försöker gömma den.
Eftersom jag vet att anslutningssträngen kan hackas, antar jag alltid att den kommer att hackas och vidtar försiktighetsåtgärder i andra änden.
Vi gör flera saker på DB-serverns ände för att säkerställa att även om anslutningssträngen är komprimerad är data fortfarande säker.
- Användaren som är kopplad till anslutningssträngen har praktiskt taget noll behörigheter på servern. De enda behörigheterna de har är EXECUTE och KONTROLL på SCHEMA som innehåller de lagrade procedurerna.
- Den enda åtkomst som gränssnittet har är genom lagrade procedurer. Vi tillåter aldrig gränssnittet att skicka upp SQL-strängar.
- Datan hålls i ett separat schema än de körbara filerna, i DATA-schemat har användaren associerad med anslutningssträngen NOLL behörigheter, de kan inte titta på den, lukta på den eller röra den.
- De lagrade procedurerna delegerar behörigheter till användare utan inloggning som har tillräckligt med behörigheter för att utföra processen. (MED UTFÖR SOM "användare utan inloggning")
Det här är ungefär allt vi kan göra. Vi har inte hittat något sätt att förhindra att anslutningssträngen exponeras på något sätt någonstans.
Som svar på frågan som Alex ställde nedan. (för lång tid för en kommentar)
Notera. Följande är för MS SQL Server, det kan gälla andra DBMS-system men jag kan inte garantera några andra.
En databas innehåller schema, schemat innehåller databasobjekt såsom tabeller, vyer, lagrade procedurer. Schmea låter dig inhägna databasobjekt, till exempel om du hade en grupp tabeller som vem som helst fick se, så kunde de ingå i ett GEMENSAMT schema, om du hade löneinformation som du behövde för att säkra kan du lägga in det i ett LÖNschema. Du kan sedan sätta olika säkerhetsåtgärder på SCHEMA baserat på typen av objekt som finns inuti dem. Grafiskt ser de ut som mappar på en hårddisk och under dem finns alla databasobjekt som de innehåller. När du startar din server finns det flera scheman som skapas automatiskt. Den som du är mest bekant med skulle vara DBO schmea. Du kanske inte är medveten om det om din administratör har ställt in det som ditt standardschema.
Vad vi gör är att placera all data i en DATA-schmea, detta betyder att endast tabeller är tillåtna. Så om vi hade en lönedatabas skulle datatabellerna gå in i ett schema som heter dataPayroll.
En lagrad procedur är ett block eller block av SQL-kod som databasservern kan köra när den anropas. Den kan returnera en datatabell eller ett enstaka värde. Se det som en metod i C#.
Lagrade procedurer har ingångs- och returparametrar som används i SQL-koden. Paramatariserade lagrade procedurer är ett starkt försvar mot SQL Injection-attacker.
Vårt protokoll säger att de lagrade procedurerna och vyerna alla lagras i ett schema som föregås av "prog". Så i fallet med lönedatabasen finns alla objekt som inte är data inom progPayroll-schemat.
Användaren som definieras av anslutningssträngen har då bara kontroll- och exekveringsbehörigheter på "prog"-schemat. Detta gör att de kan anropa den lagrade proceduren. Användaren som definieras av anslutningssträngen nekas alla andra behörigheter. Denna användare nekas också ALLA behörigheter överallt annars. I den lagrade proceduren delegeras behörigheten att komma åt data till en NO LOGIN-användare som har behörighet att hämta data från schemat "data" med kommandot EXECUTE AS.
Det finns INGEN sql i frontend. Allt som frontend-programmerare vet är vad de lagrade procedurerna heter, parametrarna och returtyperna och -värdena.
På det här sättet, även om angriparen lyckas reta ut anslutningssträngen från ditt program, har de fortfarande mycket arbete att göra för att kunna göra något med din databas eftersom användaren som de har bara kan köra en lagrad procedur.
Om du inte har någon aning om vad något av det här är så behöver du verkligen få en DB-programmerare att ställa in ditt system åt dig.