Zrezygnowałem z pisania własnego session_handlera (co okazało się ponad moje umiejętności) i postanowiłem napisać system autoryzacji na zwykłych sesjach, oczywiście odpowiednio zabezpieczony.

Na blogu Bełdzia  wyczytałem, że dobrą praktyką jest wyłączenie możliwości przesyłania SID-a w $_GET i dopisania do .htaccess (bo do php.ini nie mam dostępu) nastepujących linii:



Rozumiem, że dzięki temu jedynym sposobem na przesłanie SID-a będzie zmienna $_COOKIE, ale co jeśli użytkownik ma wyłączoną obsługę ciastek... ? Czy nie dojdzie w ten sposób do sytuacji, że user z wyłączonymi ciastkami będzie po każdym kliknięciu wylogowywany?

Z góry dzięki za odpowiedzi

Tak właśnie będzie.

no coz nie ma nic za darmo teraz tylko pytanie jaki % userow naszego serwisu ma wylaczone cookisy

Generalnie użycie session_regenerate_id" title="Zobacz w manualu PHP" target="_manual zmiejsza prawdopodobieństwo ataku poprzez spreparowany SessionID do bliskiego zeru - wiec uzyj tego zamiast samych ciastek

OK, ciastka w takim razie zostają.

Ale co do nich włożyć, żeby ew. skradzione cookie nie posłużyło do autologowania? Jeśli umieszcze tam id sesji, to po jej przejęciu włamywacz będzie chyba autoryzowany jako zwykly użytkownik? Nie mogę przecież sprawdzać ip czy przeglądarki, bo w czasie istnienia cookie wartości te mogą się zmienić...

Przeglądarkę możesz sprawdzać spokojnie - zlicz sobie co jaki czas średnio zmieniają się przeglądarki - dostaniesz odpowiedź że na tyle rzadko iż możesz się tym nie przejmować. Z ip również często jest takie zabezpieczenie, tutaj musisz sam się nad tym zastanowić, bo ip zmienia się dalece częściej niż przeglądarka... jednakże, jeśli zamierzasz robić to tylko na sesjach, nie ustawiając stałego zalogowania, to i tak zabójczo niewielki procent podczas jednej sesji zmieni sobie ip.

ps. Poza id sesji możesz przechowywać również inne zmienne sesyjne, na przykład login. Jeśli ktoś zdobędzie id sesji, a nie będzie miał ustawionej zmiennej sesyjnej login będziesz wiedział, że tak naprawdę nie jest zalogowany.

Hmmmm, nie zrozumieliśmy się chyba jednak.

Chce oprzeć system o wykorzystanie zarówno cookie jak i sesji, na zasadzie takiej, że z sesji będzie można korzystaćprzy pojedynczym logowaniu, zaś z cookies przy autologowaniu.

Myślałem o czymś takim: przy logowaniu zapisuje do bazy danych unikalny kod użytkownika (zapisuje go również do ciastka), zaś przy autologowaniu porównuje wartość zapisaną w ciastku z wartością zapisaną w bazie danych. Czy jest to dobry sposób na zabezpieczenie danych?

A co jak ktoś ukradnie ciastko z tym unikalnym kodem?

Dalej uważam, że oparcie o wersję przeglądarki jest dobrym pomysłem, przy autologowaniu natomiast sprawdzanie ip w moich projektach przeważnie pozwalam włączyć lub wyłączyć w profilu - dla tych bardziej zainteresowanych oraz ze stałym ip.

Ogólnie wiadomo, że cookies są mniej bezpieczne niż sesje. Jeśli zaś user upgradeuje przeglądarkę moim zdaniem powinien się spodziewać tego, że może być jeszcze raz poproszony o hasło.

Sęk w tym, że na dobrą sprawą, co by nie wrzucić do ciastek to po przejęciu właściwie otwierają się wszystkie furtki



O, to z opcjonalnym sprawdzaniem IP to dobry pomysł, bo moim głównym problemem było właśnie to, że zbyt wiely polskich internautów używa łąćz z dynamicznie generowanymi IP i dlatego w nich przypadku taka weryfikacja przy autologowaniu byłaby bez sensu.

Z drugiej strony tak sobie myślę, że może lepiej uszczelnić system przed atakami typu XSS czy SQL Injection zamiast paranoicznie bać się o wykradzenie ciasteczka? Czytałem kilka tutków na ten temat, filtruje dane przy pomocy strip_tags, addslashes czy mysql_real_escape_string, ale czy to wystarczy?

Dzięki za zainteresowanie tematem Shili

Dlatego ktoś kiedyś wymyślił sprawdzanie ip, przeglądarki oraz paru innych ciekawych rzeczy W końcu tego w ciastku nie ustawiasz tylko na przykład zapisujesz w bazie danych, przepisujesz do sesji itd.

Myślę, że lepiej pomyśleć o jednym i drugim.
addslashes nie polecam, już bardziej mysql_real_escape_string, które faktycznie przygotuje praktycznie każdy ciąg znaków do wstawienia do bazy danych. strip_tags jak najbardziej załatwia sprawę.

Ok, to jeszcze jedno. Czy zamiast przekazywania SID-a przez ciastko lub adres URL nie lepiej zarejestrować po udanym logowaniu zmienną sesyjną np. login = 1, a później po prostu sprawdzać, czy ma wartość 0 czy 1 (0 przyjmowała by oczywiście przy wylogowaniu) ?

Tak naprawdę identyfikator sesji tak czy siak się pojawi. Jednakże jednocześnie spokojnie można sobie stworzyć taką zmienną sesyjną, nic nie stoi na przeszkodzie.

Dzięki identyfikatorowi php może "śledzić" sesje. Bez niego nie wiadomo czy zmienna login będzie się odnosić do sesji wygenerowanej dla użytkownika A odwiedzającego stronę, użytkownika B, czy C.

Czyli wychodzi na to, że jeśli ktoś się znajdzie w tej 1.6% Polaków blokujących ciastka to tak czy inaczej dostanie doklejonego SID-a do adresu URL?

Przy session.use_only_cookies użytkownik bez cookies powinien mieć mocno utrudnioną możliwość logowania, zapewne przy tej dyrektywie nic nie zostanie przesłane, ani przez adres, ani przez cookie, których użytkownik nie przyjmuje.

jest na to proste rozwiązanie:

[PHP] pobierz, plaintext 
<?php
$browser = get_browser(null, true);
if($browser['cookies'] == 0)
{
die('musisz miec wlaczone cookies...');
}
?>
[PHP] pobierz, plaintext 

Zacząłem powoli wdrażać podane rozwiązania w życie, jednak nie obyło się bez problemów. Mianowicie, po dopisaniu podanych wyżej linijek do .htaccess jedynym efektem jest wyrzucenie wewnętrznego błędu serwera (500). Próbowałem zmienić php_value na php_flag ale nic to.

Wujek Google podpowiada, że na niektórych serwerach modyfikacja ini przez .htaccess nie przynosi efektu. Chyba jednak te 1,6% userów wyłączających ciastka będzie trzeba doedukować co do przekazywania adresu URL z SID-em osobom trzecim. :|