Udostępnij za pośrednictwem

Wskazówki dotyczące bezpiecznego kodowania

Większość kodu aplikacji może po prostu używać infrastruktury implementowanej przez platformę .NET. W niektórych przypadkach wymagane jest dodatkowe zabezpieczenia specyficzne dla aplikacji, utworzone przez rozszerzenie systemu zabezpieczeń lub przy użyciu nowych metod ad hoc.

Korzystając z wymuszonych uprawnień platformy .NET i innych mechanizmów egzekwowania w Twoim kodzie, należy wznieść bariery, aby zapobiec uzyskiwaniu dostępu do informacji, których nie chcesz, aby były dostępne, lub wykonywania innych niepożądanych działań. Ponadto należy zachować równowagę między zabezpieczeniami i użytecznością we wszystkich oczekiwanych scenariuszach przy użyciu zaufanego kodu.

W tym omówieniu opisano różne sposoby projektowania kodu do pracy z systemem zabezpieczeń.

Zabezpieczanie dostępu do zasobów

Podczas projektowania i pisania kodu należy chronić i ograniczać dostęp do tego kodu do zasobów, szczególnie w przypadku używania lub wywoływania kodu nieznanego źródła. Należy więc pamiętać o następujących technikach, aby upewnić się, że kod jest bezpieczny:

  • Nie używaj zabezpieczeń dostępu kodu (CAS).

  • Nie używaj częściowego zaufanego kodu.

  • Nie używaj atrybutu AllowPartiallyTrustedCaller (APTCA).

  • Nie używaj .NET Remoting.

  • Nie należy używać modelu obiektów składników rozproszonych (DCOM).

  • Nie używaj formaterów binarnych.

Zabezpieczenia dostępu kodu i kod Security-Transparent nie są obsługiwane jako granica bezpieczeństwa dla częściowo zaufanego kodu. Odradzamy ładowanie i wykonywanie kodu nieznanego pochodzenia bez wprowadzenia alternatywnych środków bezpieczeństwa. Alternatywne środki bezpieczeństwa to:

  • Wirtualizacja

  • AppContainers

  • Użytkownicy i uprawnienia systemu operacyjnego

  • kontenery Hyper-V

Kod neutralny pod względem zabezpieczeń

Kod neutralny pod względem zabezpieczeń nie wykonuje żadnych jawnych czynności w systemie zabezpieczeń. Jest uruchamiany z uprawnieniami, które otrzymuje. Mimo że aplikacje, które nie przechwytują wyjątków zabezpieczeń skojarzonych z chronionymi operacjami (takimi jak używanie plików, sieci itd.), mogą spowodować nieobsługiwany wyjątek, kod neutralny pod względem zabezpieczeń nadal korzysta z technologii zabezpieczeń na platformie .NET.

Biblioteka neutralna pod względem zabezpieczeń ma specjalne cechy, które należy zrozumieć. Załóżmy, że biblioteka udostępnia elementy interfejsu API, które używają plików lub wywołują kod niezarządzany. Jeśli kod nie ma odpowiednich uprawnień, nie zostanie uruchomiony zgodnie z opisem. Jednak nawet jeśli kod ma uprawnienie, każdy kod aplikacji, który wywołuje go, musi mieć takie samo uprawnienie, aby działać. Jeśli kod wywołujący nie ma odpowiednich uprawnień, SecurityException pojawi się w wyniku przechodzenia po stosie zabezpieczeń dostępu do kodu.

Kod aplikacji, który nie jest składnikiem wielokrotnego użytku

Jeśli kod jest częścią aplikacji, która nie będzie wywoływana przez inny kod, zabezpieczenia są proste i specjalne kodowanie może nie być wymagane. Należy jednak pamiętać, że złośliwy kod może wywoływać twój kod. Chociaż zabezpieczenia dostępu do kodu mogą uniemożliwić złośliwemu kodowi dostęp do zasobów, taki kod może nadal odczytywać wartości pól lub właściwości, które mogą zawierać poufne informacje.

Ponadto jeśli kod akceptuje dane wejściowe użytkownika z Internetu lub innych niewiarygodnych źródeł, należy zachować ostrożność w przypadku złośliwych danych wejściowych.

Zarządzana powłoka do implementacji kodu natywnego

Zazwyczaj w tym scenariuszu niektóre przydatne funkcje są implementowane w kodzie natywnym, który ma być dostępny dla kodu zarządzanego. Zarządzane obudowy można łatwo pisać za pomocą wywołania P/Invoke lub COM Interop. Jeśli jednak to zrobisz, osoby wywołujące wrappery muszą mieć prawa do niezarządzanego kodu, aby odnieść sukces. Zgodnie z domyślną polityką oznacza to, że kod pobrany z intranetu lub Internetu nie będzie działał z opakowaniami.

Zamiast udzielać praw do niezarządzanego kodu wszystkim aplikacjom korzystającym z tych otoczek, lepiej jest nadać te prawa tylko kodowi otoczki. Jeśli podstawowa funkcja nie uwidacznia żadnych zasobów, a implementacja jest również bezpieczna, otoczka musi jedynie przypisać sobie prawa, aby dowolny kod mógł być wywołany za jej pośrednictwem. Jeśli zasoby są zaangażowane, kodowanie zabezpieczeń powinno być takie samo jak przypadek kodu biblioteki opisany w następnej sekcji. Ponieważ powłoka potencjalnie udostępnia zasoby wywołującym, niezbędna jest staranna weryfikacja bezpieczeństwa kodu natywnego; odpowiedzialność za to spoczywa na powłoce.

Kod biblioteki, który uwidacznia chronione zasoby

Poniższe podejście jest najbardziej zaawansowane, dlatego potencjalnie niebezpieczne (jeśli zostało wykonane niepoprawnie) do kodowania zabezpieczeń: Biblioteka służy jako interfejs dla innego kodu w celu uzyskania dostępu do niektórych zasobów, które nie są dostępne w inny sposób, tak jak klasy platformy .NET wymuszają uprawnienia do używanych zasobów. Wszędzie tam, gdzie uwidaczniasz zasób, kod musi najpierw zażądać uprawnienia odpowiedniego dla zasobu (czyli musi przeprowadzić sprawdzanie zabezpieczeń), a następnie zazwyczaj dochodzić swoich praw do wykonywania rzeczywistej operacji.

Zobacz także