Sikkerhet og .NET

[HDSoftware]

Heisan folkens

Jeg har et spørsmål angående sikkerhet og .NET. Jeg koder i VB2005, men tror det har lite med saken å gjøre.

 

Jeg har laget en modul som jeg kaller WinSec. Denne modulen inneholder all sikkerhet rundt prosjektet mitt enten det går på lisensiering, brukerhåndtering etc. etc. Måten jeg drar dete inn i prosjektene på er pr. nå at jeg henter inn en DLL som en resurs. Det gjør jo at jeg kan opprette nye objekter på bakgrunn av den DLL. Men dette forhindrer jo ikke andre å gjøre det samme og dermed er jo hele konseptet ubeskyttet.

 

Er det noen annen måte å beskytte seg mot hacking på? Det er ingen grunn til å bruke for mye tid på å beskytte for hvis noen vil inn så kommer de inn. Men å lage noe som ikek hvem som helst klarer å hacke med hadde jo vert bra. En måte er jjo at kildekoden i WinSec importeres inn i prosjektet for så å bli rekompillert hver gang. Da vil jo funksjonene ligge gjemt i selve programmet og vil derfor måtte kreve mer avansert debugging for å hacke sikkerheten.

 

Andre ideer dere har kansje så kom igjen

 

Ole

[GeirGrusom]

I .NET er det lagt inn strong keys for å hindre andre programmer i å bruke dine DLL-er, og er ikke så vanskelig å få til.

Dessuten er det noe som heter obfuscation, som gjør reverse engineering vanskelig, og at mange disassemblers ikke vil klare å disassemble koden, tror det følger med en demo eller noe på et slikt program med Visual Studio.

[HDSoftware]

I .NET er det lagt inn strong keys for å hindre andre programmer i å bruke dine DLL-er, og er ikke så vanskelig å få til.

Dessuten er det noe som heter obfuscation, som gjør reverse engineering vanskelig, og at mange disassemblers ikke vil klare å disassemble koden, tror det følger med en demo eller noe på et slikt program med Visual Studio.

8421208[/snapback]

Ahh

Jeg kikket litt i prosjektet og fant under "Signing" at jeg kunne lage eller hente en Key File. Nå prøvde jeg dette, men den havner ikke under Release ved en BUILD. Må jeg shippe denne fila manuellt eller er dette en fil jeg kun skal bruke i Visual Studio slik at Visual Studio har anledning til å bruke DLL'ene mine? Hvis så er jo dette helt topp. I så fall - er det noen vits å lage en for hver DLL, eller er det like greit å ha en som er felles?

 

Ole

Endret 19. april 2007 av HDSoftware

[HDSoftware]

I .NET er det lagt inn strong keys for å hindre andre programmer i å bruke dine DLL-er, og er ikke så vanskelig å få til.

Dessuten er det noe som heter obfuscation, som gjør reverse engineering vanskelig, og at mange disassemblers ikke vil klare å disassemble koden, tror det følger med en demo eller noe på et slikt program med Visual Studio.

8421208[/snapback]

 

 

Hmm - Tror ikke jeg helt fiokk dette til

 

Jeg laget nå et test scenario

Test1.dll som har en metode, Test2.dll som har en annen metode

 

Så laget jeg en testapp som implimenterer disse DLL'ene

 

Når jeg signerer Test1.dll så får jeg fortsatt brukt den uten videre i test appen uten at jeg trenger implementere lisens filen som opprettes. Noe jeg ikke helt har fått med meg her?

 

Ole

[HDSoftware]

Dette virker på en måte litt baklengs....

 

Jeg fikk nå dette på en måte til, men helt motsatt av hva jeg så for meg

 

Jeg signerte som sagt den ene appen Test1, men ble aldri spurt om noe som helst i den appen som lager EXE fila

 

Men når jeg derimot signerer EXE fila så krever den at jeg også har signert DLL'ene..... Derfor:

 

* Signerte DLL'er kan brukes av hvem som helst uten vanskligheter så lenge EXE fila ikke er signert

* Signerte EXE filer krever at DLL'er også er signert

* Og siste, men ikke minst - Lisens filene som opprettes er helt individuelle og må ikke nødvendigvis ha samme passord

 

 

Jeg tror ikke jeg helt skjønner hensikten med denne signeringen. Noen som kan hjelpe meg?

 

Ole

Endret 19. april 2007 av HDSoftware

[j000rn]

Strong name er for å sikre at DLL/EXE filen er *akuratt* den filen du forventer at det er.

F.eks. lager du Min.ExE som bruker MinAssembly.DLL. For å hindre at jeg "hacker"/virus/etc applikasjonen din så har du gitt DLL filen din et strong name. Da vil EXE filen din skjønne at min DLL (som jeg prøver å få EXE filen din til å kjøre) ikke er den samme DLL filen som din MinAssembly.DLL. Det er "best practice" å alltid gi filene dine et strong name. På en enkel måte kan du se på det som en "CRC" eller MD5-hash av programmet ditt

 

I tillegg kan strong name brukes for å gi en maskin eller en bruker tilgang til å kjøre (evt; lese filer, koble mot database, gjøre webrequests, etc) denne filen. Dette blir helst brukt i litt større AD miljøer hvor systemadmin ikke vil at folk skal kjøre hvilken som helst filer. OG sysadmin kan også bestemme hva hver enkelt fil (avhengig av strong name, blandt annet - egentlic "evidence") skal ha tilgang til å gjøre. Evidence er regler for å slå fast policy på en fil. Evidence kan være f.eks. strong-name, publisher (sertifikat), hvor filen er fra (nettverk, lokal disk, internett), etc... .Net 1.1 følger det med et GUI verktøy for å sette dette. I .Net 2.0 har man kun caspol.exe (command line). GUI verktøyet kan hentes ned fra Microsoft.com i .Net Framework SDK (?). Poenget var at Microsoft av en eller annen grunn syntes at vanlige brukere ikke skal få lov å endre sånne ting, og at systemadministratorer bør laste den ned separat... Edit: På Vista'n min har jeg vist mulighet for å sette dette i .Net 2.0 Configuration, men det kan godt hende er fordi jeg har installert SDK'en.....?

 

For å hindre at andre bruker din DLL, ville jeg kryptert den (System.Security.Cryptography). Så får du .EXE filen din til å laste inn filen, dekryptere og "kjøre" DLL'en med Assembly.Load(byte[] ?);. Dette gjør nok at det blir hakket verre å teste koden... Om noen andre har et bedre forslag så fyr løs

 

Som andre har sagt før her... husk obfuscate! Test med reflector for å se hva som skjer hvis du IKKE gjør det http://www.aisto.com/roeder/dotnet/

Endret 19. april 2007 av jorn79

[HDSoftware]

Takker for info.

 

Greia er at jeg gjør noen kall mellom DLL'ene med passord som parameter for å sette opp fil strukturer etc. Ser jo at disse parameterene enkelt kan lese av og det er jo ikke bra.

 

Den ObFuscator greia - vil den klare dette på et vis?

[j000rn]

Takker for info.

 

Greia er at jeg gjør noen kall mellom DLL'ene med passord som parameter for å sette opp fil strukturer etc.  Ser jo at disse parameterene enkelt kan lese av og det er jo ikke bra.

 

Den ObFuscator greia - vil den klare dette på et vis?

8426552[/snapback]

 

Det avhenger av hvilken du velger å bruke. De billigste (gratis) vil som regel ikke kryptere string'er i filen din. Men de vil gjøre det vanskeligere å finne ut hva som faktisk skjer... Ikke lett å gjette hva som egentlig skjer når du kaller metode "public C A(int a,string A b,B c);"

 

Husk at for å kjøre obfuscate på flere filer og public objekter/properties/fields/metoder så trenger du en obfuscator som støtter dette... Tror igjen gratisversjonene bare tar én fil om gangen og som regel kun obfuscerer private/internal ting.

Endret 19. april 2007 av jorn79

[Manfred]

Er alle obfuscatorer like dyre? De jeg har sett ligger på mellom $700 og $1900, liksom...

[j000rn]

Er alle obfuscatorer like dyre? De jeg har sett ligger på mellom $700 og $1900, liksom...

8428931[/snapback]

 

Nei, noen av dem er gratis!

[GeirGrusom]

Men de som er gratis, kan bare rename... :´(

Fy i helsike så dyre de skulle være!

Tror jeg skal pøve Jorn sin versjon jeg...

[j000rn]

Selv om du krypterer... Så må du også huske å obfuskere... Hvis ikke er det ganske enkelt å lese ut av koden hvordan du dekompilerer

[Manfred]

Evt legge hovedtyngden av den logiske koden serverside?

 

Applikasjonene jeg lager kommuniserer stort sett med et serverside XML-API, så... Logikken får liksom ingen tak i selv med koden min. Der ser man bare hvilke script som er i bruk.

[HDSoftware]

Evt legge hovedtyngden av den logiske koden serverside?

 

Applikasjonene jeg lager kommuniserer stort sett med et serverside XML-API, så... Logikken får liksom ingen tak i selv med koden min. Der ser man bare hvilke script som er i bruk.

8448306[/snapback]

Vell, hjelper lite hvis du da ikke leier ut programmet via egen server. Så fort du putter koden på en kunde server så er du like langt.

[Manfred]

Som sagt: Applikasjonene jeg lager...

[HDSoftware]

Har vel rimelig lite med denne tråden å gjøre hva slags applikasjoner du lager ;-)

[Manfred]

Det var et innlegg om temaet som ble diskutert, og en eventuell annen løsning.

 

Hva du mener er relevant eller ikke driter jeg ganske mye i, egentlig.

[HDSoftware]

WOW! Hissig type du

[Manfred]

Jeg er vel ikke spesielt hissig, men jeg liker ikke attituden din...

[HDSoftware]

Skjønner vi har et kjemisk problem og det er jo synd. Har aldri vert meningen å være vanskelig eller noe slikt og det er bare å beklage hvis du oppfatter meg slik.

 

Er vel ikke mye å gjøre med det desverre