[ Pobierz całość w formacie PDF ]
.Zagadnienia związane z zarządzaniem sesjąCzęsto sterowanie poufnymi danymi odbywa się poprzez zarządzanie sesją na serwerze WWW.Pouwierzytelnieniu (albo przy użyciu uwierzytelnienia HTTP, albo systemu opartego naformularzach  forms-based systems), odpowiedni żeton jest dołączony do sesji i w jakiśsposób wbudowany w każdą stronę WWW.Serwer WWW poprzez sprawdzenie żetonu określa,czy konkretne działania lub dane są dostępne.(Cookies i ukryte pola formularza  hidden formfields to dwa najpopularniejsze sposoby stosowane w takich sytuacjach).Uwierzytelnienie jest poważnym problemem sieci WWW.Najprostsze metody  prosteformularze HTML lub podstawowe uwierzytelnienie HTTP  są również najmniej bezpieczne,ponieważ przekazują hasła wyraznym tekstem poprzez Internet.HTTP obsługuje uwierzytelnianieDigest, które używa MD5 do zmieszania hasła przed jego wysłaniem.Jednak niewiele to pomaga,gdyż agresor może zwyczajnie użyć zmodyfikowanego oprogramowania klienta i wyszperać zsieci postać zmieszaną, by przesłać ją ponownie.Użycie protokołu SSL szyfrowania sesji jest obowiązkowe dla bezpieczeństwa sesji przesyłaniapoufnej informacji (zobacz poniżej jak używać SSL).W tych okolicznościach, uwierzytelnieniewyraznym tekstem nie jest poważnym problemem, gdyż hasła nie mogą być wyszperane z sieci.Jednak w sytuacjach, w których SSL nie może być udostępnione lub nie jest uzasadnione (zjakiegokolwiek powodu), są dostępne inne środki dla poprawy bezpieczeństwa procesuuwierzytelniania.Na przykład, formularz rejestracji w systemie mógłby użyć prostego protokołu wyzwanie-odpowiedz (ang.challenge-response) dla uniemożliwienia przesyłania haseł.Z takim systemem,formularz mógłby mieć losowy bajt wyzwania (ang.challenge byte) zachowany w ukrytym poluformularza.Przycisk  dostarcz (ang.submit button) nie powodowałby bezpośredniegoprzedłożenia formularza.Zamiast tego, mógłby złączyć bajt wyzwania i hasło, zmieszać je zapomocą bezpiecznej funkcji mieszania, wyczyścić pole hasła w żądaniu, a następnie przedłożyćjedynie formularz ze zmieszaną postacią hasła.Z uwagi na wymagania dla przechowywania hasłana serwerze, hasło mogłoby być zmieszane dwa razy  raz do wygenerowania postaci zmieszanejhasła do przechowania na serwerze, a drugi raz, aby włączyć bajt wyzwania.Problem skryptów w witrynach przeplatanych (cross-site scripting)Większe możliwości współczesnych przeglądarek doprowadziły do nowego i niespotykanegodotąd problemu z bezpieczeństwem WWW.Pojęcie wykonywania skryptów w witrynachprzeplatanych (ang. cross-site scripting ) jest odrobinę mylące, gdyż faktycznie obejmuje coświęcej niż ataki za pomocą skryptów.Niemniej jednak jest to powszechna nazwa dla całej klasyataków, które usiłują wykorzystać zaufanie między użytkownikiem a witryną.Problem powstaje, kiedy, na ogół zaufana, witryna dołącza dynamiczne dane dostarczone jej przezużytkowników, bez pełnej weryfikacji wprowadzonych danych.Złośliwi użytkownicy mogąwykorzystać ten problem, dostarczając do witryny dane, które, jeśli wyświetlone, mająnieoczekiwane skutki uboczne.Te efekty zwykle wiążą się z przesyłaniem danych do agresora zapośrednictwem innej, już mniej zaufanej witryny.Zdarza się (choć rzadko), że sama zaatakowanawitryna może być użyta do przesłania informacji. Przykład już jest gotowy.Załóżmy, że witryna z aktualnościami zbiera komentarze odużytkowników na temat prezentowanych tam wiadomości i wyświetla je jako część każdejwiadomości.Jednym sposobem implementacji tego (w Perlu) byłby poniższy kod:# OSTRZEZENIE: to nie jest bezpieczne! Uzywac ostroznie!# Tablica @komentarze zawiera tablice asocjacyjne z atrybutami# komentarza dla kazdej z nich.foreach $komentarz (@komentarze){print "Autor komentarza ", $$komentarz{"nazwisko"}, "\n";print "\n";print $$komentarz{"tekst"}, "\n";print "\n";}Ten kod wygląda całkowicie rozsądnie i, sam w sobie, nie jest w gruncie rzeczy niezabezpieczony.Ale rozważmy co by się stało, jeśli użytkownik przedłoży poniższy komentarz:Wiecie co mysle o tym artykule? Jego autor toJeśli witryna nie zrobiła nic, aby zatwierdzić komentarze, to obrazek spoza witryny zostaniepokazany jako część strony.W rzeczywistości, dla niewprawnego oka to mogłoby wydać sięczęścią samej opowieści, zatwierdzonej przez witrynę.Choć nieco humorystyczny, przykład ten nie oddaje w pełni dostępnych możliwości.Znacznikmógłby być całkiem spokojnie znacznikiem.Dysponując pewną wiedzą owitrynie, ów skrypt mógłby zebrać inną informację z witryny i przekazać ją do serwerakontrolowanego przez agresora.W obrębie znacznika , dane wprowadzone przez agresoramogły zmienić zachowanie formularza, nawet do tego stopnia, że spowodują przekazanieinformacji do innego zródła.Ewentualnie, znacznik mógłby być przezroczystymobrazkiem 1x1w formacie GIF z dołączonym, zamiast obrazliwego obrazka, cookie.Podrzucającdo witryn z aktualnościami komentarze w tym stylu, agresor mógłby zbudować imponujące profileużytkowników, a nawet połączyć je z konkretnymi osobami.Taka informacja mogłaby byćwykorzystana do naruszenia ich prywatności, czy oszukania ich w jakiś sposób.Są kroki, które można podjąć, by przeciwdziałać tego rodzaju atakom:Zawsze należy zatwierdzać poprawność danych wprowadzanych z zewnętrznego zródła.Obejmujeto dokumenty pobrane z innych witryn, takie jak RSS-RDF streszczenia aktualności, każde dane zformularzy (nawet z ukrytych pól formularza  dopisanie za pomocą POST dowolnej wartości doadresu URL jest dziecinnie łatwe), cookies, czy też pobrania plików.Należy ściśle definiować dopuszczalne typy danych.Odrzucając wszystko z wyjątkiempoprawnych danych wejściowych (zamiast odrzucania tylko znanych niewłaściwych danychwejściowych), uniemożliwia się agresorom zastosowanie nowatorskich sposobów, wymyślonychdla obejścia procedur zatwierdzania. Zawsze należy zatwierdzać poprawność danych wejściowych po ich zdekodowaniu, jeśli nieprzedtem.To zapobiega przemyceniu przez agresorów kodów nadużywających, w postaciwariantów zakodowanych w URL.Zawsze należy określić charset dla każdej strony dynamicznej (zalecane właściwie dla każdejstrony).Przeglądarki używają różnych domyślnych zestawów charset w zależności od wieluróżnych czynników.Zostały napisane nadużywające programy do przemycenia niewinniewyglądającego tekstu do witryny, wykorzystujące niejednoznaczność charset.Taki tekst, kiedyjest pokazany w określonym charset, powoduje w efekcie aktywację witryny przeplatanej.Standardowe sieciowe narzędziakryptograficzneW zapewnieniu bezpieczeństwa aplikacji sieciowych często niemałą rolę odgrywa kryptografia.Wzwiązku z tym powstało kilka standardów dla wspomagania programistów w używaniukryptografii poprzez sieć.Standardy te są zwykle łatwe w implementacji, dobrze współdziałają i sąw większości niewidoczne dla aplikacji.SSL-TLSSSL był jednym z pierwszych systemów szyfrowania ogólnego przeznaczenia dla Internetu i dodziś pozostaje również systemem najbardziej popularnym.Początkowo był rozwinięty dlaułatwienia bezpiecznych transakcji WWW, a przy odrobinie wysiłku może być zastosowany dodowolnego protokołu opartego na TCP.sshNarzędzie ssh (i stowarzyszona usługa sshd) zapewnia w pełni funkcjonalny i bezpiecznyzamiennik usług rsh.Wiele aplikacji używa usługi rsh dla zaimplementowania aplikacjisieciowych, gdyż współgra ona korzystnie z filozofią narzędzi UNIX-a [ Pobierz całość w formacie PDF ]
  • zanotowane.pl
  • doc.pisz.pl
  • pdf.pisz.pl
  • agnieszka90.opx.pl