Der er andre måder at gøre det på. Det afhænger af, hvem du tror, der kommer efter din forbindelsesstreng, og hvilken type adgang og færdighedsniveauer de vil have. Forbindelsesstrengen er derinde, et eller andet sted, uanset hvordan du prøver at skjule den.
Da jeg ved, at forbindelsesstrengen kan blive hacket, antager jeg altid, at den bliver hacket og tager forholdsregler i den anden ende.
Vi gør flere ting på DB-serverens ende for at sikre, at selvom forbindelsesstrengen er komprimeret, er dataene stadig sikre.
- Brugeren, der er tilknyttet forbindelsesstrengen, har praktisk talt nul tilladelser på serveren. De eneste tilladelser, de har, er EXECUTE og CONTROL på SCHEMA, der indeholder de lagrede procedurer.
- Den eneste adgang, som frontenden har, er gennem lagrede procedurer. Vi tillader aldrig frontenden at sende SQL-strenge.
- Dataene opbevares i et separat skema end de eksekverbare filer, i DATA-skemaet har brugeren knyttet til forbindelsesstrengen NUL tilladelser, de kan ikke se på det, lugte til det eller røre ved det.
- De lagrede procedurer delegerer tilladelser til brugere uden login, som har nok tilladelser til at udføre processen. (MED UDFØR SOM 'bruger uden login')
Det er omtrent alt, hvad vi kan gøre. Vi har ikke fundet en måde at forhindre forbindelsesstrengen i at blive eksponeret på en eller anden måde et eller andet sted.
Som svar på spørgsmålet, som Alex stillede nedenfor. (for lang til en kommentar)
Bemærk. Følgende er til MS SQL Server, det kan gælde for andre DBMS-systemer, men jeg kan ikke stå inde for andre.
En database indeholder skema, skemaet indeholder databaseobjekter såsom tabeller, visninger, lagrede procedurer. Schmea giver dig mulighed for at afskærme databaseobjekter, for eksempel, hvis du havde en gruppe tabeller, som alle havde lov til at se, så kunne de ind i et FÆLLES skema, hvis du havde lønoplysninger, som du havde brug for at sikre, kunne du lægge det ind i et LØNNINGSskema. Du kan derefter sætte forskellige sikkerhedsforanstaltninger på SCHEMA baseret på typen af objekter, der er inde i dem. Grafisk ligner de mapper på en harddisk, og under dem er alle de databaseobjekter, de indeholder. Når du tænder din server, er der flere skemaer, der automatisk oprettes. Den, du er mest bekendt med, ville være DBO schmea. Du er muligvis ikke klar over det, hvis din administrator har sat det op som dit standardskema.
Det, vi gør, er at placere alle data i en DATA-schmea, det betyder, at kun tabeller er tilladt. Så hvis vi havde en løndatabase, ville datatabellerne gå ind i et skema kaldet dataPayroll.
En Stored Procedure er en blok eller blokke af SQL-kode, som databaseserveren kan køre, når den kaldes på. Det kan returnere en tabel med data eller en enkelt værdi. Tænk på det som en metode i C#.
Lagrede procedurer har input- og returparametre, der bruges i SQL-koden. Paramatariserede Stored Procedures er et stærkt forsvar mod SQL Injection-angreb.
Vores protokal siger, at de lagrede procedurer og visninger alle er gemt i et skema, der går forud for 'prog'. Så i tilfældet med løndatabasen er alle de objekter, der ikke er data, inde i progPayroll-skemaet.
Brugeren, der er defineret af forbindelsesstrengen, har så kun kontrol- og udfør-tilladelser på 'prog'-skemaet. Dette giver dem mulighed for at kalde den lagrede procedure. Brugeren, der er defineret af forbindelsesstrengen, nægtes alle andre tilladelser. Denne bruger bliver også nægtet ALLE tilladelser alle andre steder. I den lagrede procedure delegeres tilladelsen til at få adgang til dataene til en NO LOGIN-bruger, der har tilladelse til at hente dataene fra 'data'-skemaet ved hjælp af kommandoen EXECUTE AS.
Der er INGEN sql i frontend. Det eneste, frontend-programmørerne ved, er, hvad navnet på de lagrede procedurer er, parametrene og returtyperne og -værdierne.
På denne måde, selvom angriberen formår at tease forbindelsesstrengen fra dit program, har de stadig meget arbejde at gøre for at kunne gøre noget ved din database, da den bruger, de har, kun kan udføre en lagret procedure.
Hvis du ikke har nogen idé om, hvad nogen af disse ting er, skal du virkelig have en DB-programmør til at sætte dit system op for dig.