Prawidłowy sposób zarządzania sesjami w PHP?

Question

Aktualnie konfiguruję system uwierzytelniania. Mój obecny układ to pobranie jego wiadomości e-mail z adresu $_POST, md5 jego hasła i sprawdzenie bazy danych przed jego adresem e-mail i hasłem. Jeśli pasuje, używam session_start i zacznę przechowywania danych w zmiennej $_SESSION, tak:

$_SESSION['uid'] = $uid; 
$_SESSION['first_name'] = $first_name; 

A na każdej stronie internetowej, chciałbym preform prostą kontrolę

isset($_SESSION['uid']); 

jeśli nie, przekieruj do strony indeksu, jeśli jest, załaduj stronę.

Czy robię to poprawnie? Czy to wystarczająco bezpieczne? Jak łatwo jest sfałszować te dane?

Ktoś powiedział mi, że powinienem stworzyć stół, z adresem e-mail użytkownika i jego identyfikatorem sesji i użyć go do zarządzania rzeczami ... Stałem się raczej zdezorientowany - w jaki sposób to pomogłoby?

Czy ktoś mógłby to wyjaśnić? Jaki jest prawidłowy sposób zarządzania uwierzytelnianiem przy użyciu sesji PHP?

Dzięki.

Answer 1

aktualizacji zabezpieczeń: począwszy od 2017-10-23: rada w tej odpowiedzi, podczas gdy znaczenie historyczne, jest całkowicie niepewny. Nigdy nie należy używać md5 w haszowaniu hasłem, ponieważ jest on tak łatwo wymuszony. Zobacz: this answer o tym, jak używać wbudowanego password_ * api do mieszania i weryfikowania haseł.

---

mam do czynienia z systemami logowanie/uwierzytelniania wcześniej, a ja znaleźć kilka niedociągnięć w tej metodzie:

• ty „md5 jego hasło i sprawdź bazy danych” - oznacza to, że jeśli osoba ma dostęp do bazy danych, może rozpoznać, kto ma te same hasła!

DODATEK (19 września 2015) * Spójrz na to link. Wyjaśnia on wszystkie podstawy, metody, które można zastosować, powody, dla których warto zastosować te podejścia, a także podaje przykładowy kod PHP. Jeśli jest za długo, aby przeczytać, po prostu idź do końca, złap kod i przygotuj się!

lepsze podejście: przechowywać MD5 username+password+email+salt w bazie danych, sól jest losowa i przechowywane razem z rekordem użytkownika.

• używanie "uid" bezpośrednio w zmiennych sesji może być bardzo ryzykowne. Rozważmy to: mój znajomy jest zalogowany z mojej przeglądarki, a on wychodzi na przeciek. Szybko sprawdzam, które ciasteczka są ustawione w jego przeglądarce i rozszyfrowuję jego "uid". Teraz jestem jego właścicielem!

lepszego podejścia: wygenerować losową sessionid, gdy użytkownik loguje się skutecznie i przechowywać ten identyfikator sesji w tablicy $_SESSION[]. Będziesz także musiał skojarzyć sessionid z jego identyfikatorem uid (używając bazy danych lub memcached). Zalety to:

1. Można nawet powiązać sessionid do konkretnego adresu IP tak, że nie można sessionid nadużywane nawet jeśli to jest zrobione
2. można unieważnić starszą sessionid jeśli użytkownik loguje się z innego miejsca . Jeśli mój znajomy zaloguje się z własnego komputera, sessionid na moim komputerze stanie się automatycznie nieprawidłowy.

EDYCJA: Zawsze używałam ciasteczek ręcznie do obsługi sesji. Pomaga mi to łatwiej integrować składniki javascript w moich aplikacjach internetowych. Być może będziesz potrzebować tego samego w swoich aplikacjach w przyszłości.

Answer 2

Nie jestem w 100% na ten temat, ale myślę, że można sfałszować sesję, jeśli ktoś naprawdę chce!

Myślę, że zapisanie identyfikatora sesji w tabeli to najbezpieczniejszy sposób na zrobienie tego.

Ostatnio trochę się nad tym zastanawiałem, ale znowu nie jestem pewien, zainteresowany usłyszeniem najlepszej praktyki!

Oto kilka zasobów, aby spojrzeć na

http://www.sitepoint.com/article/php-security-blunders/

http://www.phpeasystep.com/workshopview.php?id=6

Answer 3

Nie ma nic złego robi nie jest przesyłany do użytkownika tej

isset($_SESSION['uid']); 

sesji danych jest przechowywany na serwerze (lub gdziekolwiek sesji Wózek przechowuje je). To, co jest przesyłane do użytkownika, to identyfikator sesji, który jest po prostu losowym ciągiem generowanym przez PHP, można go oczywiście ukraść, ponieważ jest wysyłany do użytkownika.

Należy wyraźnie zaznaczyć, że losowe zapisywanie ciągu znaków w bazie danych i sesji użytkowników, a następnie używanie go w celu identyfikacji użytkownika, nie powoduje, że sesja jest bezpieczniejsza, jeśli atakujący uzyska sesję, nadal będzie musiał naraził na szwank użytkownika.

To, o czym teraz dyskutujemy, to: session hijacking, może myślisz, że możesz po prostu zapisać adres IP w sesji i sprawdzić, czy adres IP pochodzi z żądania i że zostanie z nim zrobiony. Jednak często nie jest to takie proste, ostatnio spłonęło, gdy w dużej aplikacji internetowej przechowywaliśmy w sesji sesję z hasłem User Agent + IP, a następnie sprawdzaliśmy, czy są dopasowane w każdym przypadku dla 99% użytkowników to działało dobrze. Zaczęliśmy jednak otrzymywać zgłoszenia od osób, które stwierdzały, że są nieustannie wylogowywane bez żadnego wyjaśnienia. Sprawdziliśmy, co się dzieje, i sprawdziliśmy, czy te osoby przychodzą na jeden adres IP, a ich sesja będzie kontynuowana na innym. Nie była to próba porwania, ale miała związek z tym, jak ich serwer proxy W rezultacie zmieniliśmy nasz kod przejęcia sesji, aby ustalić numer class of the IP address, a następnie ustalić część sieciową adresu IP i zapisać tylko te części adresu IP, że jest to nieco mniej bezpieczne, ponieważ porwanie sesji może teoretycznie pochodzić z w tej samej sieci, ale spowodowało, że wszystkie fałszywe alarmy zniknęły.

Answer 4

Muszę dodać do tego. Jeśli robisz "MD5 hasło, a następnie sprawdź bazę danych" metoda, to sugeruje, że hasło jest przechowywane w jednym hash md5. Nie jest to już standardowy sposób przechowywania haszowanych haseł.

znalazłem ten link bardzo pouczające: http://www.itnewb.com/tutorial/Encrypting-Passwords-with-PHP-for-Storage-Using-the-RSA-PBKDF2-Standard