Beskytte dll fil?

Hvis din database er konfigureret til at modtage connections fra localhost (eller den IP-adresse du selv arbejder fra) så burde andre ikke kunne tilgå den udefra; Kun programmer som afvikles direkte fra serveren ville kunne se databasen.

Som udgangspunkt er det ikke - i .NET - muligt at beskytte en .DLL imod deasemblering.

Jeg ved ikke helt om jeg forstår dig korrekt.

Jeg har eksempelvis i min dll-fil angivet host, user og pass
DB_HOST = xxx.xxx.xxx.xxx
DB_USER = user
DB_PASS = pass

Denne dll distribueres sammen med mit WinForms program til eksempelvis 10 brugere. Dermed er jeg vel "tvunget" til at angive den eksakte IP adresse på db-serveren og ikke "bare" localhost, som jeg f.eks. ville kunne have gjort i ASP.net der altid afvikles fra samme udgangspunkt.

Det jeg frygter er ikke så meget en disassembly (overvejer at forvrænge med Dotfuscator), men mere at ondsindet bruger skulle tage min dll-fil, oprette sig eget visual studio projekt, sige "Add reference" til min fil og derefter kalde GetConnection(), som ville give ham fuld adgang til min database.

Ved ikke om det giver mere mening? Det er en problemstilling jeg slet ikke havde tænkt over inden jeg gav mig i kast med at placere alt min db-halløj i en dll-fil. Jeg tænkte bare at det kunne være smart at have denne fælles fil tilgængelig både i WinForms og ASP.net

Du kunne jo overveje om at bruge Remoting i dine Windows-programmer - i stedet for at de forbinder sig direkte til DB-serveren så går de via en klasse på serveren.

Det vil jeg lige prøve at google lidt på, altså simpelt forklaret ligge dll funktionaliteten op på serveren?

øh

er der et problem ?

IIS vil da ikke tillade brugere at hente en dll fra bin dir !?!?

og det der med at forhindre folk med fuld server adgang i noget er som oftest
formålsløst

Sådan som jeg har forstået problemstillingen så er der et Windowsprogram og en databaseserver. Windowsprogrammerne ligger sammen med DLL'en på klientmaskinerne og kan derfor stjæles derfra af en tilstrækkelig skruppelløs person.

Det er DLL'en som indkapsler databaseforbindelsen, og nu agter du så at også ville bruge denne direkte på din webserver for at understøtte at en ASP.NET løsning.

Hvis dette er rigtigt forstået så er ASP.NET løsningen lidt irrelevant i sammenhængen idet din database i princippet blev tilgængelig da du udgav DLL'en sammen med dit Windowsprogram.

nielle -> Helt korrekt forstået. Det er på klient niveauet jeg har problemer. Jeg vendte det lidt med en ven, og han forslog straks at lade user + pass blive givet til GetConnection() som parametre, og så lagre user + pass på klient maskinen i en krypteret fil?

Hvad siger i til den løsning?

Hvis man har adgang til dine programmer og er kyndig i brugen af deassembleren kan man jo også se hvordan du dekoder user+pass. Derefter kan man gøre det samme selv.

Ja det er jo selvfølgelig bare at rykke det hele et niveau. Nogen af Jer der har erfaring med Dotfuscator, vil den kunne "sløre" tilstrækkeligt til at mine strenge og metoder ikke bliver umiddelbart læsbare?

Aner det faktisk ikke - jeg har dog generelt ikke meget respekt til overs for ofuscating. Mit råd er stadig at du kigger på Remoting og styre adgangen til at bruge databasen direkte på serveren.

Okay, tak for dine gode råd. Det er rart lige at kunne sparre med nogen :)

hvorfor skulle det være bedre at gå gennem en remoting server
end at gå direkte til databasen ?

Hvorfor skulle det ikke være bedre? Så undgår man da at opbevare user og pass i den del at applikationen som brugeren kan komme til. Desuden kan man så implementere adgangskontrollen til hvem som kan få lov til at benytte serveren i den del af koden som brugerne ikke har adgang til. Eller tager jeg fuldstændig fejl?

hvordan checker du remoting client på remoting server ? sender et password ?  :-)

Det afhænger jo af hvordan strukturen på systemet er. Hvis det f.eks. var maskiner på samme domæne så ville jeg bruge almindeligt Windows-logon. Hvis det var maskiner "ude i byen" så kunne jeg måske finde på at tjekke via IP-adresser hvis det var praktisk muligt.

Eller jeg kunne lave en løsning baseret på ActivCard - lige som hos visse netbanker.

remoting understøtter mig bekendt ikke SSPI nemt så der skal skrives en del
kode, hvis databasen tilfældigvis er SQLServer så kan man lave SSPI ved
bare at rette connection string

hvis vi snakker om scenariet hvor der er adgang til dll på client PC, så er check
på IP adresse nok ikke meget værd

et system med engangspassword vil løse problemet, men så er vi også ovre
i en løsning i en helt anden kaliber
ikke

Jeg ved ikke hvad det lige præcist er som pfp ønsker at opnå - men jeg går da ud fra at det drejere sig om at forhinder nogen i at lave en anden snylte-applikation og så afvikle den på en *anden* klient end dem som har betalt.

Jeg er helt enig i at en løsning baseret på sådan noget som ActiveCard er af en helt anden størelsesklasse. Min pointe med eksemplet var nu også bare at man trods alt har nogle muligheder for at styre adgangen hvis noget af logikken placeres på serveren; I modsætning til situationen hvor al logikken er på klienterne og serveren kun fungere som databaseserver.

ihvertfald hvis det er SQLServer så kommer man ret langt med SSPI og konsekvent
brug af stored procedures

Jeg vil lige prøve at opridse mit scenarie lidt bedre.

Jeg har en database (SQL Server 2000) hvor x brugere har deres hjemmeside kørende fra via mit CMS. Altså fælles database for x brugere. Jeg har så udviklet et WinForms program som de kan anvende når de vil redigere deres hjemmeside - set det som et alternativ til de mange systemer hvor alt absolut skal foregå via browseren.

Når en bruger vil logge ind for at redigere sin hjemmeside logger han på med sin e-mail adresse og en personlig adgangskode. Alt i hele databasen har så et SiteId (jvf. ideen med fælles database for x brugere), og når brugeren så er logget ind kan han kun redigere hvor alt passer med "hans eget" SiteId.

Det smarte for mig er selvfølgelig at jeg ikke skal vedligeholde 10 databaser hver gang jeg tilføjer nye features, eller kommer med rettelser. Ulempen er så lige så klart, at databasen bliver knudepunktet, og dermed et absolut ekstra følsomt område.

Det der for alt i verden ikke må ske, er at hacker/cracker (eller hvad de kaldes nu om stunder) via min dll-fil får fri adgang til databasen og for sjov tester med "DROP DATABASE"...

Alle manipulationer i databasen fra min Windows klient foregår via Stored Procedures, som Arne jo anbefaler. Men det forhindrer jo ikke personen med fri adgang til at fyre vilkårlige SQL strenge efter min server, eller for den sags skyld oprette sine egne procedurer.

Håber jeg har fået forklaret lidt bedre hvad mit mål er og at det ikke er grebet så fundamentalt forkert an, at mit nu halvfærdige projekt skal kasseres pga. denne struktur...

Mvh Peter

du laver de SP som der skal bruges

de ejes så af DBO

DBO har fuld adgang til tabeller

så laver du et eller flere brugernavne som ingen adgang overhovedet har til noget
som helst (de kan ikke lave en SELECT på en tabel) udover at køre de SP

hvorfor bruger du ikke SSPI ?

Hej Arne,

Altså DBO ala root, og en bruger som kun anvendes til at kalde de SP'er? Hvis jeg lige forstår de rigtigt, så de lyder det jo umiddelbart som en rigtig god løsning. Men, og ret mig endelig, en virkelig "ond" bruger, som jeg jo så går ud fra stadig kan disassemble sig til user + pass (ikke DBO), kan jo så stadig udføre min SP'er, hvis han får opsnappet hvad de hedder og hvad de forventer af parametre? Eller har jeg misforstået noget? Men det løser jo i hvert fald problemet så langt at han ikke har FRI adgang til serveren.

Jeg kender ikke til SSPI, men vil da lige prøve at læse lidt om det i min database-bog.

Endnu engang tak til Jer begge, det er simpelthen uvurderligt.

SSPI betyder at connection string ikke indeholder username og password

SQLServer betragter connection som kommende fra windows brugernavnet

der er fri adgang til at kalde SP men der er ikke adgang til andet

i nogle tilfælde er det et godt bidrag til sikkerheden

Nååh, det er det med Integrated Security? Det tror jeg du har prøvet at forklare mig en gang tidligere, uden jeg helt forstod det. Men jeg læser lige på lektien, så må vi se om det er noget jeg kan finde ud af at håndtere.

Jeg må hellere få lukket her.

Interesserede bedes venligst lægge et svar.

.

Hvad med dig Nielle. Vil du have point?

Gerne, men du havde jo ikke tilkendegivet om du kunne bruge mit input til noget. Jeg tager normalt kun point for input som folk rent faktisk kan bruge.

..,´. og et svar :^)

Denne tråd har været meget opklarende for mig på baggrund af dine og Arne's indlæg. Det er jeg glad for, og selvom jeg måske ikke har fået en konkret løsning leveret, har jeg fået de input jeg forsøgte. Hjælp til selvhjælp om man vil - som Eksperten bør være efter min mening.

"input jeg forsøgte", skulle naturligvis have været "input jeg søgte"