mam rację sądząc, że jeśli kod podpisać exe, który odwołuje się do kilku bibliotek DLL (nie silne nazwie), że złośliwy użytkownik może zastąpić mój DLL i dystrybucji aplikacji w taki sposób, że wydaje się jakby jest podpisany przeze mnie, ale uruchamia swój kod?
Tak, jeśli pozostała część biblioteki DLL są podpisane i nie tylko silne nazwie mogą być wymieniane bez NET podnoszenie wyjątek. Wewnątrz exe można sprawdzić, czy biblioteki DLL są podpisane tym samym kluczem co exe. Żadne z tych podejść nie uniemożliwia zastąpienia plików DLL lub EXE.
Zakładając, że to prawda, wydaje się, że nie bardzo chce podpisać aplikację .NET bez silnej nazywając całość, w przeciwnym razie jesteś dając ludziom możliwość wykonywania kodu pod przykrywką twoją aplikację?
Generalnie sądzę, że jest to „najlepsze praktyki”, ale znowu nie zapobiegły czegokolwiek. Gdy użytkownik ma prawo do zmiany plików w systemie lokalnym, niewiele można zrobić, aby powstrzymać ich przed złośliwą działalnością.
Istnieje kilka technologii obfuskacji, które budują kompletne projekty .NET w jednym exe, może to być "najbezpieczniejsze" podejście, ale wciąż może zostać zmienione.
Prawdziwe pytanie brzmi: co próbujesz im uniemożliwić? Mam na myśli powiedzieć, dlaczego ktoś byłby zainteresowany zastąpieniem biblioteki dll? Co chcieliby osiągnąć, jaki jest ich cel? Jeśli próbujesz uniemożliwić komuś czytanie wrażliwych informacji z procesu, w którym jesteś, czeka Cię ciężka droga rozczarowania. Załóżmy, że złośliwa strona ma pełny dostęp do Twojego kodu źródłowego i wszystkich informacji użytych w twoim procesie, ponieważ tak robią. Załóżmy, że mogą one zastąpić cały lub część twojego kodu, ponieważ mogą.
Updated
Więc wiązania przekierowanie działa tylko z zespołów silnej nazwie z tym samym kluczem, a zatem nie chroni cię od DLL zostanie zmieniona?
Zgadza się, z wyjątkiem zauważyć, że wstrzyknięcie kodu nadal można zrobić na wiele sposobów.
... i powrót do pierwotnego pytania, czy podpisywania kodu bez silnej nazywania trochę osłabić punkt podpisywania kodu?
Niezupełnie. Podpisywanie kodu (niezbyt silna nazwa) ma dwa różne cele:
- Uwierzytelnienie. Sprawdzanie, kto jest autorem oprogramowania.
- Uczciwość. Sprawdzanie, czy oprogramowanie nie zostało zmienione od czasu podpisania.
Często jest to tylko uwierzytelniane i sprawdzane podczas instalacji. Właśnie dlatego podpisujemy nasz plik setup.exe, aby upewnić się, że klient otrzymał od nas niezmodyfikowany instalator. Zostają one poproszone o "Czy ufasz firmie XXXX" i tym samym udzielają autoryzacji instalatorowi uwierzytelnionemu/podpisanemu. Po zainstalowaniu jest jednak mało wbudowanego użycia podpisywania kodu przez system operacyjny (z wyjątkiem sterowników i niektórych innych niejasnych przypadków).
Silne nazewnictwo z drugiej strony ma zupełnie inny cel. Jest całkowicie skoncentrowany na "integralności" aplikacji. Nie ma certyfikatu, żadnego urzędu podpisującego (CA), aby go zweryfikować, żadnych informacji wyświetlanych przez użytkownika, aby je potwierdzić, i żaden system operacyjny nie może zweryfikować pliku wykonywalnego, który ma zostać uruchomiony.
.NET Framework używa silnych nazw dla wielu rzeczy, wszystkie z nich ja luźno kategoryzować jako integralności aplikacji:
- zawartość dll/exe ma podpisaną mieszania tak, że nie może być naruszone.
- Każda referencja musi być silnie nazwana i zweryfikowana podczas ładowania zależności.
- Zespoły można zarejestrować w GAC i można użyć zasad wydawcy.
- Natywne obrazy mogą wygenerować skompilowany obraz IL zespołu.
Jestem pewien, że brakuje tu innych rzeczy, ale są to podstawowe zastosowania, o których wiem.
Najlepsze praktyki do podpisywania i Strong nazewnictwa
- Użyj podpisaną instalatorowi
- użyć kodu podpisany wykonywalny
- Użyj silny nazwie pliku wykonywalnego
- Strong nazwa wszystkie zależności i odniesienia do nich
- Zależności podpisywania kodu nie są na ogół wymagane *
- Rozważmy GAC rejestracji zespołów w czasie instalacji
* Uwaga: podpisanie Kod może być przydatna w niektórych przypadkach do DLL dla obiektów przykład COM oznaczony jako „bezpieczne” i osadzony w przeglądarce powinna zostać podpisana i silne nazwany jeśli był to plik wykonywalny. Podpisywanie kodu może być również przydatne w zewnętrznie weryfikowaniu zależności bez ładowania zespołu lub odzwierciedlania jego atrybutów.
Nie mam przykładu, który próbuję chronić, po prostu staram się w pełni zrozumieć podpisywanie kodu/SN :-) Sugerujesz, że SN może być ominięty z powiązaniami przekierowania ... Czy to nie jest taka porażka? punkt SN całkowicie? –
Masz rację, wiążące przekierowanie nie może zmienić klucza podpisu. Mam zamiar sprawdzić moje fakty po opublikowaniu, ale się rozproszyłem. –
Tak wiążące przekierowanie działa tylko w przypadku zestawów o silnych nazwach z tym samym kluczem, a zatem * nie * chroni przed zmianami bibliotek DLL? (iz powrotem do pierwotnego pytania, czy podpisywanie kodu bez silnego nazewnictwa podkopuje sens podpisywania kodu?) –