Ochrona klienta

Przeglądarki są zasadniczym, choć nie jedynym obszarem ochrony klienta. Wynika to z faktu, że przeglądarki nie mogą być bardziej bezpieczne niż stacja robocza i system operacyjny, na którym pracują, czy też użytkownicy, którzy się nimi posługują. Według tradycyjnych kryteriów oceny systemów informacyjnych współczesne przeglądarki webowe są aplikacjami mało bezpiecznymi. Popularne przeglądarki nie mają mechanizmów ochronnych niezbędnych do wspomagania strategicznych aplikacji intrasieciowych. Wśród najbardziej znanych, słabych punktów większości współczesnych przeglądarek komercyjnych jest brak zabezpieczeń hasłem, ich niezdolność do automatycznego zamykania się po określonym czasie bezczynności, nieograniczony dostęp do zasobów komputera lokalnego oraz możliwość ujawniania istotnych danych przez przyciski back i forward, ważniejsze pozycje książek adresowych, folder historii, zakładki i podświetlone łączniki.

W celu rozwiązania problemów bezpieczeństwa połączenia większość komercyjnych przeglądarek jest przygotowana do obsługi standardu przemysłowego SSL (Secure Sockets Layer) w wersji 2.0 lub 3.0 - protokołu kryptograficznego dla ochrony transakcji realizowanych w HTTP, FTP i innych protokołach internetowych.

SSL stosuje szyfrowanie kluczem publicznym, wymieniając 40- lub 128-bitowe klucze sesyjne pomiędzy przeglądarką i serwerem webowym. Klucz sesyjny jest używany do szyfrowania zarówno dyspozycji, jak i odpowiedzi transakcji online, zachowując w tajemnicy prywatne klucze użytkownika i serwera.

Powszechnie uważa się jednak, że SSL nie jest dostatecznie silny, aby wspierać trudny rynek elektroniczny typu bussines-to-bussines. Klucz 40-bitowy nie jest odpowiedni dla działalności innej niż informacja publiczna. W serwerach handlu elektronicznego powinien być stosowany klucz co najmniej 128-bitowy, odpowiedni dla aplikacji kontrolujących istotne informacje lub duże obroty pieniężne.

Bezpieczeństwo intrasieci w dużym stopniu zależy również od tego, czy można zaufać komponentom programowym - apletom, sterownikom, rozszerzeniom i innym elementom wykonawczym - sprowadzanym i instalowanym przez przeglądarki.

W przypadku apletów Javy i ActiveX te pierwsze w dużym stopniu zależą od tego, na ile bezpieczny jest ich oryginalny model sand box, ograniczający aplety w funkcjach czytania lub zapisu na dysku lokalnym użytkownika oraz komunikacji z dowolnym serwerem webowym innym niż ten, z którego pochodzą. ActiveX Control dla odmiany mają na ogół pełny dostęp do lokalnych zasobów użytkownika, tak więc mają potencjalnie więcej okazji do czynienia szkód.

W bezpiecznej implementacji administratorzy sieci będą mieli możliwość "zawieszania" apletów Javy (np. na zaporze ogniowej), zanim dopuszczą je do przeglądarki. Należy zauważyć, że podpisane (certyfikowane) aplety Javy lub ActiveX nie muszą być wcale bardziej "przyjazne" niż te, które są przenoszone bez uwierzytelniania. Certyfikacja cyfrowa używa technologii kryptograficznej do uwierzytelniania, czy dany aplet lub fragment kodu został wydany przez oryginalnego wydawcę oraz czy został przesłany w stanie nienaruszonym. Innymi słowy, certyfikacja gwarantuje autentyczność apletu, ale nie ręczy za intencje jego twórcy.