[PHP]bezpieczne logowanie, bezpieczeństwo poważnego projektu Opcje

[gitbejbe]

Witam. Mam pytanie czysto teoretyczne tak więc nie będę wklejał niepotrzebnie kodu.
Przeleciałem już kilkanascie stronn na tym forum w poszukiwaniu pomocy, również w googlasie nie jest łatwo odzszukac jednoznaczej odpowiedzi na mój problem.

Muszę zrobić jak najbezpieczniejsze logowanie. Robie duży projekt, w którym w gre już wchodzą pieniądze na kontach użytkowników.

Dlatego tez mam pytanie odnośnie logowania, najpierw zaczne od tego co zrobiłem.

w moim formularzu, mozna logowac sie poprzez email/login i hasło

-najpierw pobieram dane i nakładam na nie "htmlspecialchar"
-sprawdzam później poprzez wyrażenia regularne w php, czy oba pola posiadają dozwolone znaki. Dla loginu przewiduje tylko litery, cyfry i znaki używane w mailach. Dla hasła tylko cyfry i litery.
- jeśli jest ok, sprawdzam, czy ktoś taki istnieje - po loginie albo emailu (poprzez funkcje sprawdzam kto co podał do logowania)
- sprawdzam tylko czy istnieje takie ID w bazie i czy konto jest aktywne, jeśli tak pobieram tylko ID.
- jeśli istnieje, tworze sesje i narazie to wszystko

co do trzech pierwszy punktów, chce jeszcze dodać dla hasła znaki specjalne dla zwiększenia siły i wymóg w rejestracji do stosowania znaków specjalnych.
mam dodaną również blokadę logowania dla IP na 15min jeśli w ciagu 5minut logował się bez powodzenia 20razy.
Hasła są pięknie kodowane w sh1 i solone tak, że nie ma bata na złamanie.

do sesji dodaje tylko ID użytkownika na zasadzie $_SESSION['identyfikator'] = $row['id']. No a póżniej sprawdzam czy istnieje taka sesja na odpowiednich stronach

no i teraz odnośnie tworzenia sesji. Tutaj jest mój dylemat. Nie mogę sobie pozwolić na ataki, gdzie ktoś mógłby wejść na czyjeś konto i np zażądać wypłaty jego pieniędzy.
Naczytałem się, że najbezpieczniej jest użyć do tego ciastek, gdzie do takiego ciastka wrzucam np te ID z sesji i sprawdzam za każdym razem czy sesja i ciastko są takie same. Wolałbym jednak nie bawić się w ciastka ze względu na to, że każdy ma prawo je blokować w przeglądarce.

Wytłumaczcie mi jeszcze, jeśli zna ktoś mój identyfikator sesji czyli dla $_SESSION['identyfikator'] jest nią string "identyfikator", to co wtedy ? jakiś przykład ?

Jak ktoś ma z was dobre doświadczenie odnośnie bezpieczeństwa sesji, prosze o pomoc merytoryczną jak najlepiej się zabezpieczyć. Tylko prosze prostym językiem i łopatologicznie bo jeszcze nigdy takich zabezpieczeń dla sesji nie robiłem.

Ten post edytował gitbejbe 4.06.2013, 06:41:00

[Sephirus]

co do ciastka i blokady, to zamiast może solić danymi o przeglądarce i IP to może lepiej wygenerowac jakiś token dla sesji ? czyli sesja składałaby się z z ID i tokenu. Ciastko to byłby hash md5 czy tam sh1 z solą id oraz token. (...)

Oj nie - nie do końca rozumiesz - to nic nie da.

Rozważ taką sytuację:

Włamywacz na chwilę siada do komputera ofiary, kopiuje wszystkie ciastka i ucieka. Wraca do siebie, wrzuca ciastka do swojej przeglądarki i odpala stronę. Jeśli użytkownik jest poznawany tylko po hashu/id sesji z ciastka to gościu już ma dostęp - niezależnie od tego jakiego jakiego tokenu i kombinacji funkcji skrótu użyjesz. Po wejściu na stronę sprawdzisz ten hash z ciastka/ id sesji i wszystko się będzie zgadzać - masz włam.

Sytuacja druga (moja propozycja):

Dokładnie to samo - kradzież ciastek i odpalenie strony u siebie. Teraz włamywacz dodał dwa ciastka - jedno z id sesji a drugie AUTH. System sprawdza że sesja posiada id_user więc nastepuję sprawdzenie ciastka AUTH. Generowany jest HASH na podstawie MD5 z danych IP/przeglądarki i id sesji. Włamywacz korzysta z innej przeglądarki lub ma inne IP. Hash więc nie jest taki jak zapisany w AUTH - wyświetlamy - SPADAJ WŁAMYWACZU (IMG:style_emoticons/default/smile.gif)

Zamiast blokować to może poprostu usuwać sesje i przekierowywać na strone glówną ? nie chciałbym, aby ktoś był niechcąca poszkodowany.

Słusznie (IMG:style_emoticons/default/smile.gif) ja nie radzę też blokować w takiej sytuacji. Wylogowanie byłoby chyba najlepszym rozwiązaniem. Możesz oczywiście połączyć to z bazą danych i monitorować wszystko. Są takie systemiki i wcale nie trudne do napisania. Wystarczy zapisywać przy każdym logowaniu usera ID sesji i jego ID gdzieś do bazy - w ten sposób masz info które sesje są aktywne i poprawne. Zobacz taką sytuację:

Klient loguje się z domu. Zapisujesz w tabeli Id usera i id sesji i czas kiedy się zalogował. Jego kolega loguje się w pracy na jego konto. Podaje dane i zostaje zalogowany - znowu dodajesz wpis do bazy. Widzisz już w niej że dany user jest zalogowany z dwóch różnych miejsc ale poprawnie - może to być atak ale nie musi (jak w tym przypadku własnie nie jest). W każdej chwili możesz pokazać użytkownikowi kiedy i skąd się logował (jak dodasz do tego wpisy historyczne). Dzięki temu user będzie widział że jego kolega bez pozwolenia logował się z pracy na przykład. No i sytuacja najgorsza - ktoś skopiował (np zły kolega z pracy) ciastka tego gościa z pracy i wrzucił do siebie. System wykryje że coś jest nie halo - bo IP lub UA nie będzie się zgadzało. W tym miejscu możesz poinformować userów na obu aktywnych sesjach o tym, że nastąpiła próba włamania z danego IP itp. I kolega z pracy ochrzani tego włamywacza a klient kolegę że dał mu pobrać ciastka... (IMG:style_emoticons/default/tongue.gif)

Oczywiście samo sprawdzanie po IP / User-agent jest dobre w zamyśle że komputer włamywacza nie jest podpięty pod ten sam switch i nie ma tej samej przeglądarki (IMG:style_emoticons/default/smile.gif) ale taka sytuacja już jest naprawdę bardzo rzadka.

a i czaje z tym kodowaniem. Czyli jak ktoś nawet przechwyci jakoś ciastko z id_sesji, to zobaczy tylko hash, którego porpostu nie odkoduje więc nie będzie wiedział co w nim jest. To rozwiązuje problem podszycia pod każdą inną osobę, lecz jeśli ma hash konkretnej sesji w ciastku, to i tak może go on wykorzystać do włamania? Skoro na stronie sprawdzam hash ciastka, a włamywacz go posiada, to tak czy siak może się on włamać na to konkretne konto ?

No to opisałem właśnie wyżej (IMG:style_emoticons/default/wink.gif) - jeśli będzie to tylko ciastko z sesison_id to włam po jego zdobyciu jest nieunikniony (chyba że zastosujesz jakąś metodę ochrony - przykładowo moją)

Mógłbyś mi jeszcze wytłumaczyć sens regenerating_session_id ?

Regenerowanie id sesji jest dobre jako zabezpieczenie ale kłopotliwe. Działa to tak, że co każdy (lub co któryś) request do strony id sesji jest tworzone na nowo i przypisywane. Traci się to stare ID sesji przez co jak ktoś je skopiuje i użyje to nie zaloguje się. Ale... tak jak pisałem to kłopotliwe - za każdym razem tracisz całą sesję i musisz ją przepisywać - jest to niewygodne. Poczytaj o tym więcej - ja unikam tego rozwiązania bo jest ciężkie w kontroli - jeśli chciałbyś zrobić na tym coś zaawansowane jak system monitoringu to wiążę się z tym dużo pracy / zmian / kopiowania sesji do sesji / zapytań do bazy - odradzam.