[ Pobierz całość w formacie PDF ]
.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
[ Pobierz całość w formacie PDF ]