Bezpieczeństwo

Z poziomu języków C# i Java widać, że oba rozwiązania starają się maksymalnie wyeliminować groźbę popełnienia błędu przez programistę (np. automatyczna obsługa zwalniania pamięci). Są jednak spore różnice.

Java opiera się głównie na modelu piaskownicy, gdzie poszczególne instancje maszyny wirtualnej są izolowane od systemu operacyjnego. Ponieważ nie ma tam mechanizmów bezpośredniego dostępu do pamięci, system operacyjny może zakończyć działanie błędnie pracującego procesu JVM i np. uruchomić go ponownie.

W .Net mechanizm bezpieczeństwa jest oparty na systemie ewidencyjnym, gdzie fragment kodu (bazując m.in. na "mocnej", podpisanej cyfrowo nazwie pakietu) jest sprawdzany, czy może działać. Administrator definiuje zasady bezpieczeństwa dla danego pakietu/fragmentu kodu i np. danego użytkownika, podpisu cyfrowego domeny itp. W Javie taki podpis obowiązuje dla całej aplikacji (JAR) i administrator ma mniejsze możliwości precyzyjnego określenia praw, co dany kod może wykonać. W .Net można przypisywać katalogom określone prawa zapisu. W Javie można co najwyżej zablokować zapis lub odczyt dla wszystkich katalogów.

W .Net prawa dostępu mogą być analizowane z poziomu aplikacji - specjalny interfejs pozwala sprawdzić, czy dana operacja może być wykonana (nie jest konieczne stosowanie mechanizmu zgłaszania wyjątków czy obsługi błędów). System ewidencji kodu uwzględnia: strefę (analogiczną do Internet Explorer), URL, kod hash, mocną nazwę, domenę, katalog na dysku użytkownika, certyfikat autora kodu. Od każdego z tych elementów może zależeć polisa bezpieczeństwa, czyli operacje, jakie dany fragment kodu może wykonać. Można też dodatkowo uwzględniać rolę użytkownika - tak by np. pracownik działu handlowego nie miał dostępu do kodu obsługującego dane personalne pracowników.

Ostatnim krokiem w .Net jest weryfikacja kodu. Sprawdza on, czy dany fragment MSIL może być skompilowany do kodu maszynowego i czy nie narusza bezpieczeństwa typu. Równocześnie przy weryfikacji badane są referencje wynikające z metadanych pakietu, gdy np. typ jest zdefiniowany w innym komponencie. W .Net można uruchamiać kod niezarządzalny (np. wywołać API Win32). Oczywiście, można zablokować dostęp dla tej funkcjonalności.

Warto wspomnieć, że w .Net jest zaimplementowany nowy sposób segregacji programów, tzw. domeny aplikacji. Zwykle to system operacyjny oddzielał poszczególne procesy. Jednak przy dużej liczbie użytkowników powstawało wiele procesów, co przekładało się na większe wykorzystanie zasobów. Natomiast domena aplikacji pozwala, dzięki weryfikacji kodu, podzielić proces na oddzielne elementy i każdemu przypisać inne prawa lub związać go z innym użytkownikiem. Nie ma potrzeby, by tworzyć tyle odrębnych procesów. Wówczas znacznie tańsza jest komunikacja między poszczególnymi częściami rozwiązania.

"Zabezpieczenie przez ewidencję" i bardzo szczegółowy system polis nakładają na programistę obowiązek dokładnego badania, w jakich sytuacjach jego aplikacja wymaga określonych praw.

Bezpieczeństwo polityczne

Specyfikacja Javy jest dostępna publicznie. Technologia jest już dosyć dobrze poznana - ma ponad 7 lat. Natomiast niewiele wiadomo o implementacji poszczególnych maszyn wirtualnych czy serwerów aplikacyjnych.

Microsoft wynajął audytora - firmę Foundstone, która od początku uczestniczy w pracach nad .Net Framework. Dzięki raportom Foundstone dużo zmieniono między .Net beta 1 i beta 2. Audytor zauważył, że było zbyt dużo metod dostępu do kodu niezarządzalnego z poziomu zarządzalnej aplikacji (kompilowanej do MSIL), co potencjalnie otwierało możliwości ataku.

Niemniej obie technologie mają zasadniczą wadę - ich bezpieczeństwo zależy od bezpieczeństwa "pojemnika". Trudno sobie np. wyobrazić kod .Net, który uszkadza inny moduł znajdujący się w pamięci. Jednak można sobie wyobrazić złośliwy program, który z poziomu systemu operacyjnego zmieni działanie samej maszyny wirtualnej (Javy lub .Net). Równie dobrze może on modyfikować działanie sieci itp. W pewnym stopniu mechanizm podpisywania pakietów zabezpiecza przed takimi sytuacjami, jednak nie jest to w 100% pewne. Dopóki nie powstanie system operacyjny, na którym będą działać tylko bytecody Javy czy MSIL Microsoftu, dotąd będzie możliwa nie autoryzowana modyfikacja działania rozwiązania - zarówno w .Net, jak i Javie.