(Pseudo)Bezpieczeństwo
Od dłuższego czasu denerwuje mnie rzecz, którą można zauważyć na wielu stronach - robienie wszystkiego, żeby podwyższyć bezpieczeństwo. Nie ma w tym nic złego do momentu, kiedy te wszystkie zabezpieczenia zaczynają utrudniać korzystanie z witryny. Najgorzej, kiedy po dokładnym przyglądnięciu się im okazuje się, że nie są zbyt wiele warte.
Przykład? Przy logowaniu dostajemy cookie które jest zależne od naszego adresu IP. Fakt, jeśli ktoś w jakiś sposób dobierze się do ciasteczek nie będzie mógł ich użyć spod innego adresu. Ale może zamiast tego lepiej dokładnie sprawdzić całą stronę i upewnić się, że nie ma żadnego XSS'a? Na pewno użytkownicy ze zmiennym IP (w tym ja) ucieszą się, że nie muszą codziennie od nowa wpisywać swojego hasła.
Samo logowanie też może być niepotrzebnie utrudnione koniecznością przepisywania jakiegoś kodu z obrazka. O, jak na przykład tutaj. Ten kod można w miarę łatwo odczytać po prostu pobierając kolejne fragmenty obrazu i porównując je ze wzorami. Można też zerknąć w źródło i zobaczyć, że do adresu skryptu który generuje obrazek przekazywany jest parametr size o wartości 6. Po jego zmianie na 0 możemy zalogować się bez podawania "Security Code".
Na pewno taka CAPTCHA wygląda fajnie, użytkownikom (może i administracji) wydaje się, że strona jest zabezpieczona ale jak widać w praktyce nie robi nic, poza utrudnianiem życia.
I czemu ten kod ma w ogóle służyć? Zabezpieczać przed brute-force? Hasło jest sprawdzane przed kodem i nawet jeśli nie ma go w ogóle, to wyskoczy informacja o jego niepoprawności. Utrudnić logowanie skryptom/botom? Też nie, wystarczy albo 'nauczyć' bota odczytywać znaki z obrazka albo zwyczajnie przekazać mu cookie z przeglądarki po zalogowaniu.
Na PT ten problem (dopiero po jakimś czasie) został rozwiązany dużo sensowniej - CAPTCHA (dużo lepsza od tej) pojawia się dopiero po nieudanej próbie logowania. I wszyscy powinni być zadowoleni - userzy nie muszą przepisywać kodu (no chyba, że pomylą hasło) a i BF wykonać nie sposób.
Szkoda, że niektórzy starają się na siłę, bez głębszego przemyślenia, dodawać takie 'atrakcje' na strony, zamiast coś poprawiać tylko psują użytkownikom humor.
Czerwiec 25th, 2010 - 20:58
Coś dla ciebie:
http://www.3537.pl/analityk-zagrozen.html
Myślę, że sobie poradzisz.
Pozdro… ;).
Lipiec 2nd, 2010 - 17:56
Bardzo dobry artykuł, oświeciłeś mnie. Jak proponujesz sprawdzanie czy użytkownik miał błędne logowanie, cookie, sesja?
Lipiec 2nd, 2010 - 18:41
Cookie i sesje nie pomoga bo mozna je wyczyscic. Trzeba zapisywac w bazie adres IP. Chociaz IMHO i to nie jest potrzebne, przez neta raczej ciezko przeprowadzic jakies wieksze brute-force.
Lipiec 2nd, 2010 - 18:56
Z tym zapisywaniem IP to dobry pomysł, raczej mało by było IP w bazie, a i rekordy starsze niż dzień można by kasować. Jednak się lepiej można trochę zabezpieczyć. Dzięki. Co twoim zdaniem lepsze by było, zapisywanie IP w bazie czy pliku tekstowym?
Lipiec 2nd, 2010 - 19:00
Jak chciałbyś się lepiej zabezpieczyć? IP to chyba jedyny w miarę pewny sposób na poznanie użytkownika. No i oczywiście, że lepiej korzystać z bazy, robienie takich rzeczy na plikach jest passe…
Lipiec 2nd, 2010 - 19:04
Podasz jakieś konkretne argumenty dlaczego jednak baza? Myślę, że pliki mniej obciążają serwer?
Lipiec 2nd, 2010 - 19:09
Bo właśnie do tego służy baza danych. I już nie przesadzaj tak z tym obciążeniem, jakby na to patrzeć to można by powiedzieć, że Windows 95 jest dużo lepszy od 7, bo mniej obciąża komputer. Bazy danych służą własnie do tego – do przechowywania danych, trzeba się liczyć z tym, że kosztuje to trochę zasobów sprzętowych (przynajmniej w przypadku niewielu rekordów – przy pokaźnej ich liczbie to przeszukiwanie pliku byłoby naprawdę zasobożerne).
Lipiec 2nd, 2010 - 19:13
@bziomek: dopiero teraz zauważyłem, że koment wyleciał do spamu oO Dzięki za linka, już kiedyś na to wpadłem i nie radzę sobie – VB mnie przerasta ;]
Lipiec 2nd, 2010 - 19:14
No też prawda, ale niewielką ilość rekordów raczej w pliku umieszczać? Da się jakoś „wycachować” obrazki i czy to da jakiś wielki efekt np. na 10 obrazków na jednej stronie, każdy po 100 KB.
Lipiec 2nd, 2010 - 19:19
Jeśli masz niewielką liczbę rekordów i pewność, że się nie rozrosną to czemu nie – ale ja i tak zostaje przy bazie. Jak strona jest mała to nie generuje dużego obciążenia, jak ruch jest duży to baza powinna być czymś naturalnym. Co do cache – zależy, co chcesz cachować. Pobieranie plików ze zdalnego serwera? Po prostu zapisz je u siebie i jeśli to potrzebne to co jakiś czas odświeżaj. Jeśli chcesz włączyć cachowanie plików pobieranych z Twojego serwera w przeglądarkach to zapoznaj się np. z tym: http://www.webmasterworld.com/apache/3659750.htm?highlight=msg3659941#msg3659941
Lipiec 2nd, 2010 - 19:24
Te obrazki są wyświetlane z mojego hostingu. Możesz napisać coś więcej na temat rozwiązania z linku, angielski nie jest moim konikiem.
Lipiec 2nd, 2010 - 19:34
Ogólnie to najważniejsze będzie to (należy wrzucić do .htaccess):
# Włącz mod_expires
ExpiresActive on
# Dla plików graficznych, css, pdf, i JS
<filesmatch „\.(ico|pdf|flv|jpe?g|png|gif|js|css|swf)$”>
# ustawia czas cache na 30 dni (nie ma sensu na dłużej)
ExpiresDefault A2592000
# nie włączamy żadnych ograniczeń cachowania
Header unset Cache-Control
</filesmatch>
Lipiec 2nd, 2010 - 19:45
Jak to działa? Jakie efekty?
Lipiec 2nd, 2010 - 19:47
‘Mówi’ przeglądarce, kiedy ostatnio plik był modyfikowany i jeśli już posiada aktualną wersję w pamięci podręcznej to nie musi go po raz kolejny pobierać.
Lipiec 2nd, 2010 - 19:57
Rozumiem, czy robić jeszcze jakieś cachowanie obrazków?
Lipiec 2nd, 2010 - 19:57
Aaa. Jak sprawdzić czy działa tamten sposób?
Lipiec 2nd, 2010 - 19:59
To, co Ci własnie podałem to cache m.in. obrazków -.-
A żeby sprawdzić dodaj co trzeba do .htaccess, wejdź na stronę i sprawdź co jest przesyłane (głównie patrz na nagłówki).
I to tyle offtopowania, następne komenty nie na temat polecą do kosza bo się lekki syf zrobi.
Lipiec 25th, 2010 - 17:17
„Przykład? Przy logowaniu dostajemy cookie które jest zależne od naszego adresu IP. Fakt, jeśli ktoś w jakiś sposób dobierze się do ciasteczek nie będzie mógł ich użyć spod innego adresu. Ale może zamiast tego lepiej dokładnie sprawdzić całą stronę i upewnić się, że nie ma żadnego XSS’a? Na pewno użytkownicy ze zmiennym IP (w tym ja) ucieszą się, że nie muszą codziennie od nowa wpisywać swojego hasła.”
Wszystko to może niepotrzebne, kiedy mówimy o forum ogrodniczym czy hodowców świnek. Mam jednak wrażenie, że w wiele artykułów, w tym i ten, pozbawione są jednego drobnego założenia, mianowicie, że dotyczą mało ważnych zasobów.
A potem powstają wpoważnych aplikacjach niezłe potworki.
Wyjdźmy z Twojego założenia: Robimy stronę bez XSS(załóżmy, że chronienie sesji to tylkoXSS, chociaż to kolejne dość groźne uproszczenie) i wszystko jest super. Tylko, że za rok inny programista, albo nawet ten sam dopisuje nowy formularz/moduł do strony, i już niekoniecznie wie/pamięta co to XSS. W jeden dzień aplikacja staje się „niebezpeczna”. Oczywiście mozna powiedzieć, że to wina organizacji pracy, górnolotnie- jakości w firmie. Tylko dlaczego bezpieczeństwo mamy spychać na jakość?
Przed większością luk da sie bronić na wiele różnych sposobów, podchodząc temat z różnej strony. NIe oznacza to jednak, że tylko tą jedną stroną warto się bronić. Warto, jeśli niekosztuje to wiele i/lub po stosownej analizie, używac welu zabezpieczeń warstwowo. Wtedy ewentualny błąd (własny lub „czyjś”) nie musi przynosić żadnych konsekwencji.
Dla przykładu z Twojego tekstu można wywnioskować, że zapewnienie bezpieczeństwa sesji może nam dac ochrona przed XSS. To dobra rada ale dla kogoś komu do systemu chcemy się wbić ;)
Lipiec 25th, 2010 - 17:34
Nie mówię, że dodatkowe zabezpieczenia są złe, narzekam tylko, że czasami nie mają one sensu. OK, cookie jest zabezpieczone przez przypisanie go do konkretnego IP, pojawia się XSS – to znaczy, że nic się nie stanie? Nie, atakujący może wrzucić skrypt, który podmieni/wyciągnie jakieś dane np. przy użyciu AJAX’a.
Fakt, ciasteczek nikt do siebie nie skopiuje ale w dalszym ciągu można zrobić praktycznie wszystko – będzie to tylko wymagało trochę więcej kombinowania.
IMHO nie warto utrudniać życia użytkownikom tylko po to, żeby przy ewentualnym ataku trochę utrudnić (a nie całkiem uniemożliwić) zadanie intruzowi.