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 wymuszanych w kodzie, należy wznieść bariery, aby zapobiec uzyskiwaniu dostępu do informacji, które nie mają dostępu do informacji, których nie chcesz, ani wykonywania innych niepożądanych akcji. 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 komunikacji wirtualnej platformy .NET.
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 przezroczysty zabezpieczeń nie są obsługiwane jako granica zabezpieczeń z częściowo zaufanym kodem. Odradzamy ładowanie i wykonywanie kodu z nieznanego źródła bez zapewnienia alternatywnych środków bezpieczeństwa. Alternatywne środki bezpieczeństwa to:
Wirtualizacja
AppContainers
Użytkownicy i uprawnienia systemu operacyjnego
Kontenery funkcji 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 nazywają 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 zostanie wyświetlony w wyniku przewodnika stosu 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ć 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 otoka 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 otoki można łatwo zapisywać przy użyciu wywołania platformy lub międzyoperacyjności modelu COM. Jeśli jednak to zrobisz, osoby wywołujące opakowań muszą mieć niezarządzane prawa kodu w celu pomyślnego wykonania operacji. W obszarze zasad domyślnych oznacza to, że kod pobrany z intranetu lub Internetu nie będzie działał z otokami.
Zamiast udzielać niezarządzanych praw kodu wszystkim aplikacjom korzystającym z tych otoek, lepiej jest nadać te prawa tylko kodzie otoki. Jeśli podstawowa funkcja nie uwidacznia żadnych zasobów, a implementacja jest również bezpieczna, otoka musi jedynie dochodzić swoich praw, co umożliwia wywołanie kodu za jego pośrednictwem. Jeśli zasoby są zaangażowane, kodowanie zabezpieczeń powinno być takie samo jak przypadek kodu biblioteki opisany w następnej sekcji. Ponieważ otoka potencjalnie uwidacznia obiekty wywołujące te zasoby, niezbędna jest staranna weryfikacja bezpieczeństwa kodu natywnego i jest odpowiedzialna za otokę.
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.
