2010-04-11 15 views
7

Podczas czytania artykułów o przechwytywaniu sesji dowiedziałem się, że dobrze byłoby zaszyfrować wartość identyfikatora sesji przechowywaną w pliku cookie.Jak zaszyfrować identyfikator sesji w pliku cookie?

O ile wiem, kiedy zaczynam sesję dzwoniąc pod numer session_start(), PHP nie szyfruje wartości identyfikatora sesji w pliku cookie.

Jak zaszyfrować wartość identyfikatora sesji, a następnie zainicjować z nią sesję?

+0

Czy ktoś może usunąć tag 'session-encrypt'? –

+0

@smotchkiss // Myślałem też o tym. Przepraszamy za nieokreśloną nazwę tagu. – Moon

+0

Wiem, że to nie odpowiada na twoje pytanie za głos. Ale czy rozważałeś zapisanie adresu IP wraz z identyfikatorem sesji i sprawdzenie adresu IP podczas czytania sesji. W ten sposób możesz być dość pewny, że komputer, który podaje identyfikator sesji, jest taki sam, do którego wydałeś sesję. – Voltin

Odpowiedz

18

Szyfrowanie nie pomoże. Plik cookie sesji jest po prostu magiczną liczbą. Szyfrowanie to po prostu oznacza, że ​​jest inna magiczna liczba do przejęcia. W zależności od scenariuszy porywania, które masz na myśli, istnieją inne możliwe ograniczenia. Na przykład możesz ograniczyć sesje do pojedynczego adresu IP. Stwarza to jednak pewne problemy, np. ludzie przełączają się między punktami dostępowymi.

+0

Po prostu (miejmy nadzieję) wyjaśnić dla OP - sesja *, w której plik cookie jest przesyłany, powinna być nadal zaszyfrowana, a flaga HTTPOnly z ciasteczkami powinna być ustawiona tak, aby uniemożliwić jej przesyłanie przez nieszyfrowane kanały. Prawidłowe zaszyfrowanie kanału komunikacyjnego, przez który przesyłany jest plik cookie sesji, utrudnia intruzowi przechwycenie pliku cookie. – atk

+0

Pytanie dotyczyło szyfrowania samego cookie, tj. Wartości przechowywanej przez przeglądarkę. Zgadzam się, szyfrowanie ruchu jest opłacalne w przypadku niektórych aplikacji. Myślę, że masz na myśli bezpieczną flagę, a nie (tylko) HTTPOnly. –

+0

Dzięki. Ta odpowiedź pomogła zrozumieć domenę problemu. Teraz mam rozwiązanie w https i gdzie identyfikator sesji jest zastępowany dla każdego żądania. – nalply

3

Zakładając, że plik cookie sesji jest identyfikatorem GUID, nie ma sensu go szyfrować. Po prostu zastąpi jeden pseudolosowy łańcuch innym.

1

Niestety szyfrowanie identyfikatora sesji nie zwiększy znacząco bezpieczeństwa, ponieważ atakujący może po prostu użyć zaszyfrowanego formularza (co jest jedyną rzeczą widoczną dla nich w każdym razie).

Jedyne, co może temu zapobiec, to sztuczka, w której wysyłasz komuś link z: PHPSESSID = foo, co spowoduje, że PHP utworzy tę sesję. Możesz temu zapobiec za pomocą szyfrowania i sprawdzania poprawności, ale powinieneś całkowicie wyłączyć przekazywanie identyfikatorów sesji w adresie URL.

+0

Uważam, że wystarczy zatrzymanie sesji session.use_trans_sid (http://www.php.net/manual/en/session.configuration.php#ini.session.use-trans-sid), aby temu zapobiec. –

+0

Tak, jest. Na szczęście jest on domyślnie wyłączony. –

5

Ważniejsze jest, aby identyfikatory sesji były losowe (tzn. Ktoś nie może użyć identyfikatora sesji do odgadnięcia innej osoby), ponieważ prawdziwym zagrożeniem jest ktoś, kto dostanie identyfikator sesji innego użytkownika. Tak długo, jak zachowujesz je naprawdę przypadkowo, nie ma powodu ani użyteczności w ich szyfrowaniu.

1

Utwórz ten skrypt, uzyskaj dostęp do niego za pomocą przeglądarki internetowej, a następnie sprawdź pliki cookie.

<?php 
    session_start(); 
?> 

Najprawdopodobniej zobaczyć coś takiego

Site   Cookie  Value 
mysite.com PHPSESSID 6fktilab3hldc5277r94qh2204 

PHP robi świetną robotę jeśli generowania piękny, niepowtarzalny identyfikator. Nie ma sensu szyfrowanie tego.

+0

To wcale nie dotyczy pytania z plakatu? – zombat

+0

@zombat, właśnie pokazałem, że PHP nie generuje 'PHPSESSID'' 5' lub czegoś zupełnie słabego takiego jak OP, być może myślał. –

1

To zawsze dobry pomysł, aby nigdy nie polegać wyłącznie na jednym pliku cookie lub produkcie, aby zweryfikować (zalogować) użytkownika (użytkowników). Jak wspomniano powyżej, dobrym pomysłem jest również zapisanie adresu IP i sprawdzenie go. Dobrym dodatkiem byłoby przechowywanie USER_AGENT.

Należy pamiętać, że jeśli twoja aplikacja jest dostępna w wersji open source, jesteś równie dobry z samym identyfikatorem sesji, ponieważ haker może z łatwością zidentyfikować, z czym walczysz.

0

Identyfikator sesji jest względnie nieczytelny, więc to nie jest problem.

Istnieje rzeczy można zrobić podobne do tego, aby przeciwdziałać atakom:

  • utworzyć nową sesję, gdy użytkownik loguje się w
  • ograniczyć długość sesji

Istnieje także kilka innych rzeczy.Zawsze zalecam studiowanie Rails Guide w tych kwestiach - oferuje bardzo przystępne wyjaśnienie znanych problemów i środków zaradczych - wszystkie jednakowo stosowane do kodu PHP.

0

Sensowne jest szyfrowanie danych cookie podczas korzystania z plików cookie do przechowywania poufnych informacji. że tylko serwer powinien odczytać (odszyfrować).

Nie ma powodu do szyfrowania identyfikatora sesji, ponieważ haker może użyć tego zaszyfrowanego identyfikatora sesji do podszycia się pod swoją ofiarę.

Powiązane problemy