2009-07-25 9 views
48

Mam skrypt logowania, który weryfikuje nazwę użytkownika/hasło względem danych w tabeli "użytkownika". Ponadto mam tabelę "ról", która określa poziom dostępu danego użytkownika. Zakładając, że używam bezpiecznych skryptów logowania, czy są jakieś luki w zabezpieczeniach po prostu wykonując dodatkowe zapytanie, po udanym logowaniu, w tabeli "ról", aby odkryć poziom autoryzacji użytkownika i zapisać go w zmiennej sesji? Pomysł byłby taki, że na dowolnej stronie z mieszanym autorytetem mógłbym po prostu wysłać zapytanie do zmiennej sesji, aby wykryć poziom autoryzacji zalogowanego użytkownika.Jak bezpieczne są zmienne sesji PHP?

Dzięki.

Odpowiedz

69

Sesje są znacznie bezpieczniejsze niż, powiedzmy, ciasteczka. Ale nadal można ukraść sesję, a tym samym haker będzie miał pełny dostęp do tego, co jest w tej sesji. Niektórymi sposobami uniknięcia tego są IP Checking (który działa całkiem dobrze, ale ma bardzo niską wartość fi, a zatem nie jest wiarygodny sam) i używa nonce. Zwykle z dodatkiem, masz "token" na stronie, tak aby każda strona sprawdzała, czy pozycja końcowa ostatniej strony pasuje do tego, co zapisała.

W każdym sprawdzeniu bezpieczeństwa występuje utrata użyteczności. Jeśli przeprowadzasz sprawdzanie adresu IP, a użytkownik znajduje się za zaporą intranetową (lub inną sytuacją, która to powoduje), która nie ma stałego adresu IP dla tego użytkownika, będzie musiał ponownie uwierzytelnić za każdym razem, gdy straci swoje IP. Dzięki jednorazowości otrzymujesz zawsze dobrą zabawę "Kliknięcie w tył spowoduje, że ta strona się zerwie".

Ale z ciasteczkiem, haker może ukraść sesję za pomocą dość prostych technik XSS. Jeśli przechowujesz identyfikator sesji użytkownika jako plik cookie, są one również podatne na to. Więc nawet jeśli sesja jest dostępna dla kogoś, kto może wykonać hack na poziomie serwera (który wymaga znacznie bardziej wyrafinowanych metod i zazwyczaj pewnej ilości uprawnień, jeśli serwer jest bezpieczny), nadal będziesz potrzebować dodatkowego poziomu weryfikacji na każde żądanie skryptu. Nie powinieneś używać ciasteczek i AJAX razem, ponieważ sprawia to, że łatwiej jest całkowicie przejść do miasta, jeśli ten plik cookie zostanie skradziony, ponieważ twoje żądania ajax mogą nie uzyskać kontroli bezpieczeństwa dla każdego żądania. Na przykład, jeśli strona używa nonce, ale strona nigdy nie jest ponownie ładowana, skrypt może sprawdzać tylko pod kątem tego dopasowania. A jeśli plik cookie utrzymuje metodę uwierzytelniania, mogę teraz udać się do miasta, robiąc moje szaleństwo, używając skradzionego pliku cookie i dziury AJAX.

+19

Należy zauważyć, że PHP przechowuje identyfikator sesji jako plik cookie. –

+0

+1 Czy możesz wyjaśnić więcej o jednorazowo? możliwy link? – Petrogad

+5

Artykuł wiki na temat nonce jest dość lekki, ale ma przyzwoite linki: http://en.wikipedia.org/wiki/Cryptographic_nonce podstawowa idea, jak rozumiem, jest jak token, ale można go użyć tylko raz (numer użyty raz). Każde żądanie strony sprawdza ostatni numer i tworzy nowy. Więc jeśli spróbuję ataku brutalnym siłą na twoje hasło, dostaję jeden strzał, jako że nonce nie pasuje do drugiej rundy. Jeśli ukradnę sesję i nonce tej strony, będę mógł kontynuować składanie próśb i odnawianie tej kwoty aż do złożysz wniosek, który wyrzuca niezgodność. Ponieważ zobaczyłby moją prośbę i mój nonce, zaktualizuj ... – Anthony

16

Tylko skrypty wykonywane na serwerze mają dostęp do tablicy _SESSION. Jeśli zdefiniujesz zasięg pliku cookie sesji, możesz nawet ograniczyć go do określonego katalogu. Jedynym sposobem, aby ktoś oprócz Ciebie mógł uzyskać dane sesji, jest wstrzyknięcie kodu PHP na jedną ze stron.

Jeśli chodzi o używany system, jest on akceptowalny i jest dobrym sposobem na zapisywanie wywołań bazy danych, ale należy pamiętać, że będzie wymagać od użytkownika wylogowania i ponownego logowania się w celu wprowadzenia zmian w autoryzacji. Jeśli więc chcesz zablokować konto i ten użytkownik jest już zalogowany, nie możesz.

2

Jeśli polegasz na wartości przechowywanej wewnątrz zmiennej sesji, aby określić role, tracisz możliwość zmiany wartości w DB i ma ona odzwierciedlenie w bieżącej sesji użytkownika. Jeśli spojrzeć na Zend Framework, istnieje wyraźne rozróżnienie między uwierzytelnianiem a autoryzacją i silnie sformułowanymi ostrzeżeniami w podręczniku, aby przechowywać tylko minimalną ilość danych w sesji (tj. "Tak, jest on użytkownikiem # 37 &, który się zalogował") .

Jeśli chodzi o "bezpieczeństwo" - o ile nie jesteś na współdzielonym hoście, nie ma się czym martwić. Na poprawnie skonfigurowanym współdzielonym hoście, powinny one również być względnie bezpieczne.

13

Należy zauważyć, że w Apache superglobal PHP $ _SESSION jest dostępny dla wirtualnych hostów.Rozważmy następujący scenariusz:

  • Twój serwer obsługuje dwie domeny, example.com i instance.org. Sesje PHP są przechowywane w plikach cookie, które są ograniczone do domeny.
  • Użytkownik loguje się do witryny example.com i otrzymuje identyfikator sesji. Example.com ustawia niektóre zmienne sesji (które są przechowywane na serwerze, a nie w pliku cookie).
  • Osoba trzecia przechwytuje plik cookie podczas transmisji i przekazuje go do instancji.org. Instance.org ma teraz dostęp do zmiennych sesji przyklad.com.

To nie jest takie ważne, gdy kontrolujesz wszystkie wirtualne hosty na serwerze, ale jeśli korzystasz z współdzielonego komputera, jest to problematyczne.

+1

czy wiesz, jak ograniczyć jeden sperglobal na hosta wirtualnego, jeśli to możliwe? – JRsz

+0

@ JRsz można zmienić katalog, w którym sesje są przechowywane w pliku php.ini ou za pomocą funkcji session_save_path() (http://php.net/manual/en/function.session-save-path.php). – SandroMarques

Powiązane problemy