Notice: query (INSERT INTO lemat_stats_browser (day,browser,ilosc,internal) VALUES ('2024-11-21','Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)',1,'2')) failed at /home/lemat/lemat.priv.pl/stats.php:151: Array ( [0] => 22001 [1] => 1406 [2] => Data too long for column 'browser' at row 1 ) in /home/lemat/lemat.priv.pl/panel_adm/dbclass.inc.php on line 15

Warning: Cannot modify header information - headers already sent by (output started at /home/lemat/lemat.priv.pl/panel_adm/dbclass.inc.php:15) in /home/lemat/lemat.priv.pl/stats.php on line 174
Bezpieczne logowanie - Lemat, strona prywatna
Lemat, strona prywatna

Czy sesje są bezpieczne?

Chciałbym tu poruszyć temat bezpiecznego logowania do sajtu opartego na PHP. Okazuje się, że to nie takie proste jak by się mogło zdawać. No ale zacznijmy od początku:

Po pierwsze musimy zdawać sobie sprawę z tego, że login i hasło

  1. zna użytkownik - można się włamać "na Mittnicka"
  2. "zna" komputer użytkownika (możliwość keyloggerów, ostatnio pojawiły się też exploity na przegladarki umożliwiające fałszowanie zawartości paska adresu - klient mysli, że wszedł na właściwą stronę a jest na stronie spreparowanej)
  3. każde urządzenie pośrednie pomiędzy komputerem usera a serwerem (atak man-in-the-middle, wszelkie podsłuchy)
  4. hasło przechodzi przez skrypty PHP - można podstawić własny skrypt
  5. hasło jest zapisane gdzieś na serwerze - można podejrzeć
  6. webmaster i twórca sajtu na pewno mają jakieś backdoory pozwalające na zmianę hasła jeśli user go zapomni.

Standardowo logowanie wygląda tak:
user wypełnia formularz z loginem i hasłem, jest on wysyłany metodą POST do serwera, tam jest weryfikowana poprawność i otwierana sesja.
Każde odwołanie się usera do serwisu powoduje najpierw sprawdzenie ważności sesji i jeśli jest ok -> wyświetlenia strony serwisu.
Po zakończeniu pracy z serwisem user powinien się wylogować i sesja powinna zostać zniszczona.

W jaki sposób należy się bronić przed wykradzeniem hasła?

  1. Uświadamiać swoich userów, że np. zapisywania hasła na kartce jest głupotą, podawanie go nie/znajomym także nie jest zbytnio szczęśliwym pomysłem.
  2. Uświadamiać swoich userów aby nie ciągneli z netu śmieci i surowo karać "po premii" za takie wykroczenia. Bardzo często synek pracownika potrafi wiele zrobić z siecią firmową...
  3. posiadać wystarczająco bezpieczną sieć, wykrywanie intruzów (IDS) i wszelkich podsłuchów, stosować szyfrowane połączenie klient-serwer (HTTPS)
  4. Dbać o bezpieczeństwo własnego serwera, uniemożliwić podglądanie plików z hasłami innym userom. Rozdzielić katalogi tymczasowe z sesjami różnych sajtów.
  5. Hasła należy szyfrować algorytmem haszującym, czyli takim, który nie pozwala odszyfrować hasła. Bardzo dobrym przykładem jest md5(). Ale co ciekawe znajomość loginu/hasła wcale nie jest potrzebna do tego aby przejąć uprawnienia zalogowanego usera!
    Jak wspomniałem wcześniej po sprawdzeniu na serwerze ważności loginu i hasła tworzona jest sesja. Czyli w PHP tworzone jest ciastko PHPSESSID=jakiś numer. Jeżeli będziemy znali ten numer to bez trudu skorzystamy z tego, że ktoś inny akurat się zalogował.
    Aby przejąć ten numer wystarczy wstawić kawałek javascriptu wywołujący nasz_skrypt.php?PHPSESSID=odczytany numer z ciastka. Np. w księdze gości, na forum - wszędzie tam gdzie można wstawić jakiś tekst - wyświetlenie odpowiednio spreparowanego tekstu spowoduje uruchomienie javascriptu i tym samym przejęcie uprawnień przez włamywacza. Rozwiązaniem jest tutaj striptags() i wycinanie przynajmniej javascriptu z tekstu. Dodatkowo należy zapisywać w sesji numer IP z którego nastąpiło logowanie i porównywać z numerem IP odwiedzającego stronę przy każdym następnym wejściu.
  6. Wszelkie backdoory, a jest nimi na przykład możliwość edycji haseł w bazie danych (phpMyAdmin) powinny być bardzo dobrze zabezpieczone.

Oczywiście to, że user po zakończeniu pracy powinien się poprawnie wylogować jest utopią. Nawet ja, muszę się przyznać, to olewam i po prostu zamykam przeglądarkę. Dlatego należy stosować dodatkowe sprawdzenie przy logowaniu - czy user poprzednio się poprawnie wylogował i czy przypadkiem na ten sam login i hasło ktoś inny już nie jest zalogowany - jeżeli user zamknie nieprawidłowo sesję to niech teraz grzecznie poczeka aż ona wygaśnie i dopiero wtedy będzie mógł się zalogować ponownie. Oczywiście należy wziąć poprawkę na userów, którym Bill zawiesza kompa a TePsa zamyka połączenie z internetem.

Dodatkowe wodotryski, które podnoszą nieco bezpieczeństwo to:


Data utworzenia : 2004-01-05

Skomentuj ten tekst

Komentarze:

Miklosz
2007-06-28 01:48:12
Logowanie, zabezpieczanie no i intranet
"blokowanie możliwości logowania spoza sieci wewnętrznej firmy" czyli po prostu postawienie aplikacji na serwerze bez fizycznego dostępu do internetu - i mamy spokój, no chyba że pracownicy zechcą coś zbroić Ostatnio taki manewr zastosowałem i przynajmniej śpię spokojnie nie martwiąc się wciąż o sekjuriti
borys
2007-03-24 13:55:54
logowanie
a ja zrobilem ostatnio wlasny engine obslugi sesji dla php. zabezpieczen jest sporo: - 64-znakowy SID, ktory ma okreslona skladnie i jest ona za kazdym razem sprawdzana (w cookie widoczny jest bezsensowny dlugi ciag duzych i malych liter oraz cyfr) - 32-znakowy VK (verification key) - dodatkowe zabezpieczenie dla SID'a - konrola adresu IP engine sesji napisany jest jako statyczna klasa PHP5 sesje moga byc albo zapisywane w MySQL albo w plikach na serwerze - w zaleznosci od konfiguracji silnika. Jesli ktos jest zainteresowany, prosze o maila: borys.forytarz [AT] pjwstk [DOT] edu [DOT] pl
chester
2007-02-14 19:13:57
hashe
md5 - faktycznie nie jest już bezpieczny. Ale podobnie ma się sprawa z sha-1. Obecnie sha-256 to minimum sensowności. Dostępne w bibliotece MCrypt. Tylko zadajmy sobie jedno pytanie: czy to naprawdę ma sens? Wszak md5($haslo.$secretstring) i tak jest w naszej bazie. W momencie jeśli ktoś się wbije do naszej bazy to i tak mamy pozamiatane i nic nam nie pomoże - jaki jest sens stosowania NAPRAWDĘ skutecznych funkcji skrótu? Webmaster jak zechce to hasło pozna, a lepiej skoncentrować się na zabezpieczeniu przed SQL Injection itp niż na złudnym poczuciu bezpieczeństwa oferowanym przez SHA-1048576 ;-)
perqsista
2007-02-08 15:24:46
Dodatkowy zmienny token
Do tego co napisał Lemat można dodać jeszcze taki wodotrysk jak dodatkowy token generowany podczas każdego odświeżania zabezpieczonej strony. Token może być zapisywany np. w tabeli SQL składającej się z pol np. id_sesji_php, token, lifetime(czas ważnosci tokena). po wygenerowaniu i zapisaniu tokena w tabeli wysyła go w postaci np. ciastka. Przy kolejnym odświeżeniu, przejściu pomiędzy stronami klient musi odesłać prawidłowy stary token. Jak jest OK to dostaje nowy do otwarcia kolejnej strony. Jak jest Be, to do widzenia-uwalamy sesję PHP, i logout. Wiadomo, że można przechwycić także i ten token ale jednak może to być bardziej upierdliwe dla włamywacza, zwłaszcza, że pomiędzy czasem przechwytu a próbą wykorzystania tokena i sesji PHP jest bardzo prawdopodobne że straci on ważność.
marcin
2006-06-08 13:50:45
md5
Stosowanie md5 nie jest zalecane, jakiś czas temu ktoś znalazł metodę na znalezienie ciągu znaków który da takie samo md5 jak poszukiwane w parę godzin na PCcie. Ja stosuję sha1.
wszystkie opinie »
Protected by spf
[Nospam-PL.NET]
Seti@Home
www.php.net
© Lemat 2004 - ∞