Opracowanie bezpiecznej strategii logowania i uwierzytelniania PHP

Nie powinno być. sesja php jest przechowywana na twoim serwerze nie przez użytkownika. php simpily pozostawia plik cookie sesji wskazujący na niego. jeśli nie korzystasz z hostingu współdzielonego, sesja nie musi być nawet zahaszowana.

Joe

Przechowywanie pliku cookie w bazie danych to HORRILBE idea. Oznacza to, że jeśli atakujący miał lukę sql injection, mógł natychmiast uzyskać dostęp bez konieczności łamania zahaszowanego hasła.

Nigdy nie Generuj własnych identyfikatorów sesji, używaj session_start () i $_SESSION Super global.

To jest bezpieczne sposób na przekierowanie ludzi. Jeśli nie umrzesz po header() reszta kodu php jest nadal wykonywana, mimo że nie jest wyświetlana przez normalne przeglądarki (hakerzy nadal go widzą :)

header("location: index.php");
die();

Zależy jak bezpiecznie chcesz być..

Luki między stronami: Powiedzmy, że inna strona kieruje przeglądarkę do przesłania formularza do witryny, która robi coś takiego jak publikowanie spamu (lub gorzej), jeśli użytkownik jest już zalogowany na przesyłanie formularza będzie działać. Musisz sprawdzić referer i wygenerowany Ukryty formID dla każdego formularza, aby w pełni przed tym chronić.

Po drugie: jeśli masz duży lub średni ruch, sesje można powtórzyć lub nawet odgadnąć, sprawdzałbym przed second hand generowany identyfikator, który jest przechowywany w plikach cookie użytkowników.

Schemat wydaje się niepotrzebnie skomplikowany na kilka sposobów, ponieważ dodatkowa złożoność nie daje Ci nic w zakresie funkcjonalności lub bezpieczeństwa.

1. wszelkie dane przesyłane przez przeglądarkę (np. pliki cookie, User-agent) są fałszywe. Sprawdzanie User-agent pomoże tylko wtedy, gdy atakujący znajduje się za tym samym NAT co fałszywy użytkownik, a atakujący używa innej przeglądarki, ale nie myśli, aby zmienić User-agent.
2. Sessions Przechowuje identyfikator sesji po stronie klienta za pomocą Plików cookie lub parametr zapytania URL. Jeśli chcesz przedłużyć żywotność sesji, użyj session_set_cookie_params aby utrzymać plik cookie sesji na dłużej.

User-agent nie jest tajnymi danymi, więc hashowanie jest niepotrzebne.

Ataki, których session cookie+checking remote IP nie wychwyci to:

1. atakujący stoi za tym samym NAT co użytkownik
2. ataki typu Blind injection, w których atakujący podszywa się pod adres IP użytkownika. Pomimo tego, że są tylko do zapisu, nadal mogą zrobić kilka uszkodzenia.
[4]}ataki wykorzystujące własną przeglądarkę użytkownika, takie jak[21]}cross-site request forgery (CSRF).

2) można zapobiec, jeśli można wypracować sposób wysłania wyzwania do przeglądarki użytkownika, na które należy odpowiedzieć przed wypełnieniem żądania, ale jest to trudne, gdy nie napisałeś do klienta. Dzięki AJAXOWI można to zrobić. 3) (Jak zauważył MindStalker) można zapobiec, sprawdzając nagłówek Referer, który działa, ponieważ ataki CSRF nie mają możliwość wpływania na dowolne nagłówki, a XMLHttpRequest nie powinien zezwalać na ustawianie nagłówka Referera(zgodnie ze standardem W3C , choć implementacje mogą nie być zgodne). Z iframes, może być możliwe obejście sprawdzania Referer. Ponadto nagłówek Referer może być zablokowany po stronie klienta.

Większość witryn używa tylko sesji PHP; dane sesji ($_SESSION) znajdują się w Pliku na Twoim serwerze. Wszystko, co jest wysyłane do przeglądarki to identyfikator sesji. Pamiętaj, aby regenerować sesję każdego żądania ( session_regenerate_id). Nie musisz wysyłać dwóch ciasteczek ani niczego innego.

Jest to mniej podatne na przechwytywanie sesji, ponieważ każde żądanie jest nowym identyfikatorem, więc stary przechwycony przez atakującego jest bezużyteczny.

Najlepszym rozwiązaniem byłoby oczywiście używaj protokołu SSL przez całą sesję.

IMHO ważne jest również, aby informacje o sesji zostały zmienione po pomyślnym zalogowaniu. Zapisywanie informacji o sesji w bazie danych nie jest zapisywane z powodu zastrzyków.

-użyj sha1 z solą - oczywiście musisz zdefiniować, że każdy formularz nie jest bezpieczny, więc używany token dla każdego formularza. Że tworzysz każdy wpis formularza i oczyszczasz go za pomocą preg_match. Proces zwany kanalizacją.