Jak zabezpieczyć bibliotekę .NET DLL

Question

Co to jest najlepsza praktyka w zabezpieczaniu bibliotek DLL dla projektów, nad którymi pracujesz? Niektóre biblioteki DLL, które chcę rozwijać, będą miały warstwę dostępu do danych (DAL) i warstwę logiki biznesowej (BLL). Może istnieć kilka aplikacji, które mogą ostatecznie trafić te biblioteki DLL w celu wykonywania specyficznych funkcji biznesowych.

Jaki jest najlepszy sposób zabezpieczenia tych bibliotek DLL, aby mogły być używane tylko przez aplikacje twórców?

bezpieczeństwo zarówno blokowania nieautoryzowanego użycia DLL i zabezpieczenie przed ewentualnym dekompilacji są zarówno pożądane.

Answer 1

Jedną z opcji może być zaznaczenie wszystkich eksponowanych klas w bibliotece DLL jako "wewnętrznych" zamiast "publicznych", a następnie użycie atrybutu "InternalsVisibleTo" w bibliotece DLL w celu jawnego nazwania bibliotek DLL (i ewentualnie plików exe), z których można korzystać. twoje wewnętrzne typy. Może to wymagać, aby wszyscy uczestnicy byli potępieni, ale i tak jest to dobre.

Ostatecznie nie jest absolutnym sposób, aby zapobiec zdecydowane hakera dostępu do kodu, gdy kod jest wykonywany na komputerze hakera. Cały kod, który może być wykonany przez maszynę, można zdemontować i ponownie złożyć w coś innego z wystarczająco zaawansowanymi narzędziami i doświadczeniem.

Najlepszym sposobem podejścia do kwestii bezpieczeństwa kodu jest zadawanie pytania "Jak trudno jest nam to zrobić, aby ktoś użył tego kodu bez licencji lub autoryzacji i ile czasu/pieniędzy jesteśmy gotowi wydać, aby to osiągnąć. ? " Jeśli nic nie robisz, bardzo łatwo jest komuś użyć bibliotek DLL w innym projekcie. Jeśli zrobisz kilka prostych rzeczy, możesz sprawić, że niewygodne będzie korzystanie z twoich bibliotek DLL w innym miejscu. Jeśli poświęcisz wiele czasu na wysiłek, możesz bardzo utrudniać komuś nadużywanie kodu, ale nigdy nie uniemożliwisz tego.

Jedną z technik, które jest tak blisko całkowicie bezpieczna, jak można sobie wyobrazić, jest: nie wykonanie kodu (albo hakera) Maszyna do klienta w ogóle. Zamiast tego uruchom usługę sieciową i zachowaj swój kod na serwerze, na którym haker nie może przypadkowo uruchomić debuggera w procesie lub zdemontować kodu. Zabezpieczenia twojego kodu są następnie definiowane przez fizyczne bezpieczeństwo na poziomie serwera i bezpieczeństwo dostępu do sieci do portów serwera. Te wektory ataku są o wiele rzędów wielkości trudniejsze do ominięcia niż cokolwiek, co można zrobić, aby zakodować, które wykonuje na komputerze hakera.

W przypadku niektórych firm zajmujących się oprogramowaniem przeniesienie części aplikacji z klienta do chmury nie polega na uzyskaniu lepszej skalowalności lub łatwiejszych aktualizacji lub obniżeniu kosztów, lecz na bezpieczeństwie kodu i zapobieganiu piractwu.

Answer 2

Ustanów uwierzytelnianie za pomocą mechanizmu klucza otwartego. Funkcje w bibliotece DLL działają tylko wtedy, gdy podasz prawidłowy klucz i token.

Answer 3

Jeśli ktoś ma dostęp do komputera z tych wszystkich zespołów, trzeba więcej, aby być zaniepokojony niż ktoś ich użyciem, mogliby po prostu przejść bezpośrednio do bazy danych zamiast korzystania z zestawu.

Jeśli jest to aplikacja komputerowa lub coś w tym rodzaju, a użytkownik bezpośrednio uzyskuje dostęp do bazy danych, należy ponownie przeanalizować aplikację, uzyskać dostęp do danych za pośrednictwem usług internetowych lub coś w tym stylu, a nie bezpośrednio do bazy danych.

Answer 4

Ochrona własności intelektualnej nie jest możliwa, jeśli przesyłasz ją w formie .NET DLL do klienta. Możesz hostować logikę aplikacji w chmurze, ale może to nie odpowiadać twojemu scenariuszowi.

Nawet "najlepsi" obfuscatorzy nie są nieomylni.Prawdopodobnie można odstraszać przypadkowego hakera, ale jak mówi dthorpe, jeśli ktoś naprawdę chce zdekompilować swoje zgromadzenia, zrobią to.