Bezpieczeństwo ciasteczek, Czy tak jest? Opcje

[Zeelof]

Chciałbym się dowiedzieć na ile bezpieczne są ciasteczka?
Konkretniej zastanawiam się czy istnieje możliwość dodania ciasteczka podpisując się pod inny adres?
np. mam ciasteczko o nazwie "status" i zmienną z nazwą użytkownika, jeżeli ono istnieje to użytkownik jest zalogowany, a jak nie to nie jest zalogowany i takie ciasteczko wysyła mój skrypt, tylko czy ktoś zupełnie obcy może dodać sobie takie samo ciasteczko co będzie miało wpływ na jego pozycje na mojej witrynie?

[nospor]

tylko czy ktoś zupełnie obcy może dodać sobie takie samo ciasteczko co będzie miało wpływ na jego pozycje na mojej witrynie?

Bez najmniejszego problemu

W ciasteczkach nie wolno przechowywać żadnych statusów, stanów autoryzacji itp...

[Zeelof]

ahh czyli jednak zostają mi nieszczęsne sesje ;/

Ten post edytował Zeelof 21.02.2011, 10:23:32

[erix]

Dlaczego nieszczęsne?

[tehaha]

@Zeelof, źle do tego podchodzisz, nie trzymaj czegoś takiego jak status:zalogowany, kiedy użytkownik loguje się na stronie i zaznacza opcję typu "zapamiętaj mnie na tym komputerze" to generujesz dla tego użytkownika jakiś unikatowy hasz i zapisujesz go w bazie oraz w ciastku i na podstawie tego haszu i ID użytkownika automatycznie go zalogujesz, ponadto w bazie ustawiasz datę ważności dla tego haszu

Ten post edytował tehaha 21.02.2011, 14:17:47

[wNogachSpisz]

W ciasteczkach nie wolno przechowywać żadnych statusów, stanów autoryzacji itp...

Generalnie prawda...

Aczkolwiek w swoim ostatnim projekcie poniekąd zerwałem z tą zasadą.
Po zalogowaniu umieszczam w cookie login użytkownika, ale tylko po to aby potem przy pomocy JavaScript wyświketlić ten login w nagłówku, rozumiecie "zalogowany jako xxx".
Cel był jeden, jak najwięcej podstron ma być w formie statycznej .html, dzięki temu shared-hostingi nie zliczają wejść na statyczne dokumenty do swoich "liczników obciążenia procesora".
Rzecz jasna gdy użytkownik chce przejść do funkcji przeznaczonych wyłącznie dla zalogowanego użytkownika, takich jak np. "edycja profilu", musi nastąpił właściwe sprawdzenie sesji...
Ostatnio chodzi mi po głowie pomysł jak obejść i to i uratować jeszcze więcej czasu procesora serwera, ale to już historia na inną okazję ;p

[Crozin]

Ostatnio chodzi mi po głowie pomysł jak obejść i to i uratować jeszcze więcej czasu procesora serwera, ale to już historia na inną okazję ;p

Wykosztować się na hosting za 200 zł / rok zamiast 40 zł / rok?

[d3ut3r]

Takie zabawy nie mają sensu, tak jak Crozin napisał zmień lepiej hosting. Sesje są bezpieczniejsze od ciasteczek i nie ma co kombinować z próbą ominięcia tego.

[wszerad]

Ludzie ale przecież sesja jest określana na podstawie ciasteczka! Przeglądarka wysyła ciasteczka przypisane do witryny i na tej podstawie połączenie jest przypisywane do danego użytkownika! Dlatego jeżeli ktoś zdobędzie numer SSID to przejmuje kontrole nad sesją. Z drugiej strony jeżeli ktoś ma dostęp do ciasteczek to dlaczego ma nie mieć dostępu do wysyłanych danych?

Ja przy pisaniu strony staram się jak najwięcej robić po stronie klienta, co prawda pisze specyficzne strony w, których treści są generowane na podstawię bardzo małej ilości danych. Dodatkowo mam ten luksus, że i po stronie klienta jak i po stronie serwera korzystam z tego samego języka więc przenoszenie pewnych algorytmów jest proste i nie wymaga przepisywania.

Ten post edytował wszerad 26.02.2011, 00:47:51

[Crozin]

@wszerad: Jeżeli ktoś wpada na taki genialny pomysł jak identyfikacja sesji wyłącznie na podstawie jej ID to rzeczywiście jej przejęcie nie będzie aż tak trudne. Między innymi dlatego dodaje się warunki na adres IP czy pewne względnie stałe nagłówki przesyłane przez przeglądarkę.

Z drugiej strony jeżeli ktoś ma dostęp do ciasteczek to dlaczego ma nie mieć dostępu do wysyłanych danych?

Razem z ciasteczkami z reguły zdobędziesz również treść żądania i odpowiedzi wysyłanej do klienta. Ale nie będziesz miał możliwości bezpośredniego ingerowania (np. poprzez wykorzystanie zdobytego ID w celu samodzielnego wykonania kilku operacji).

[Rid]

Można ,używać loginów ,haseł i innych danych w session ,jeśli użyjemy metody składowania session w bazie danych mysql,a samą bazę dobrze zabezpieczyć,ale nie jest wskazane przetrzymywanie takich danych w sesji.Z drugiej strony wymaga to trochę wkładu by taką sesję zapisać do bazy,wymagana jest wtedy serializacja obiektów ,zmiennych,dodatkowo procedura składowania sesji w bazie MySQL,ale warto ze względu na bezpieczeństwo.Minus,prędkość wczytywania strony spada o jakieś 20%,ale coś za coś.Ma jeszcze ,drugi plus jeśli się użyje serializacji binarnej,można użyć dwóch serwerów do upublicznienia strony (tak-zwany webGarding),wtedy nawet jeśli jeden serwer padnie lub się zrestartuje drugi serwer będzie podtrzymywał sesje,a klient nie straci połączenia.Przykładowo ,można użyć dwóch hostingów do upublicznienia swej strony w którym jeden z nich będzie asekurował ten pierwszy ,jeśli połączenie zostanie zerwane.Dlatego,myślę że warto zapisać session do bazy ze względu na bezpieczeństwo jak i dodatkowe możliwości.Jeśli,komuś to mało ,można użyć do podtrzymania życia takiej sesji obiektu cache(nie wiem czy w php jest, bo w ASP.net tak i ma metode expired time-czyli z góry określamy czas życia tego obiektu,nawet po zamknięciu przeglądarki cache nie ginie bo zapisuje się do pamięci serwera ),jednakże ma minus pochłania to naszą pamięć operacyjną,plus szybkość dostępu do obiektu cache.W ten o to sposób ,po stronie klienta nie ma żadnych obiektów.nie ma ani identyfikatorów sessji ani obiektów cookies.Będę taką metodę podtrzymywania sesji próbował wdrożyć w swój projekt ,jednakże nie wiem czy jest on dobry i czy ktoś takie rozwiązanie próbował.Jeszcze będę musiał się zastanowić

Ten post edytował Rid 26.02.2011, 18:02:57

[Crozin]

@Rid: Ilość bzdur przypadających na zdanie naprawdę utrudnia czytanie takich postów.

[erix]

Czyli jednak źle zrobiłem gryząc się w język... ^^.

Bez urazy, ale ja to widzę tak:

i nie chodzi tu o problemy ze wzrokiem, tylko brak akapitów, sensownej składni, mimo że znam język polski, to ni w ząb nie rozumiem, co napisałeś... O wszystkim i o niczym...

[Rid]

Jeśli coś źle napisałem ,to mnie popraw,a nie krytykujesz:)

[tehaha]

rzecz w tym, że rzuciłeś kilka haseł a tak na prawdę o niczym nie napisałeś, temat jest o bezpieczeństwie ciastek, Ty zacząłeś od sesji w bazie danych, potem przerzut na serializację obiektów, webgarding, ASP. Wymieszałeś wszystko co się dało i w zasadzie nie da się wyciągnąć myśli przewodniej Twojej wypowiedzi. Wybacz ale trochę mi to przypomina wypowiedź naszych polityków, którzy rzucą trochę trudnych terminów a tak na prawdę nic konkretnego nie mówią.

Minus,prędkość wczytywania strony spada o jakieś 20%

Przeprowadzałeś jakieś testy? Czytałeś w książce czy tylko tak rzuciłeś procentem, żeby nie był to taki pusty fakt.
P.s Haseł się nie trzyma w sesji.

[Rid]

Przeprowadzałeś jakieś testy? Czytałeś w książce czy tylko tak rzuciłeś procentem, żeby nie był to taki pusty fakt.

Myślę,że w PHP sprawa wygląda podobnie jak w ASP.Net ,jeśli chodzi o metodę zapisu sesji do bazy danych.Zwykłe sesje zapisywane są In-Proc w pamięci ,dlatego dostęp do nich jest znacznie szybszy.Komunikacja między serwerem a bazą danych jest wolniejsza i do tego dochodzi jeszcze serializacja,dlatego stąd opóźnienie wczytywania strony.O wynikach tej metody można przeczytać na stronach Microsoftu.

Odnośnie ,pisania o Sesji zamiast o Cookies ,autor tego wątku chciał się dowiedzieć o bezpieczeństwie Cookies a także szukał ,alternatywy z tego co zrozumiałem.Chciałem przedstawić swoją koncepcję przetrzymywania danych, za co zostałem skrytykowany:(

[Crozin]

Jeśli coś źle napisałem ,to mnie popraw,a nie krytykujesz:)

OK, najpierw trochę krytyki co do języka Twoich wypowiedzi:
- [...] innych danych w session[...] — język polski ma odpowiedniki większości słów z języka angielskiego.
- Spację wstawiamy po przecinku, nie przed.
- Akapity to świetny "wynalazek".
- Natomiast żonglowanie różnymi tematami / terminami do świetnych nie należy.
- O brak myślników / dywizów, średników, odpowiednich nawiasów w wypowiedziach itp. nie czepiam się. Ale cholera kropka, przecinek czy spacja to nie jest wysiłek.

A teraz konkrety:
- w bazie danych mysql — a inne bazy (w tym te nierelacyjne) mogą być?
- ale nie jest wskazane przetrzymywanie takich danych w sesji — takich, czyli jakich? Hasło rozumiem - bo jest ono właściwie bezużyteczne, ale co złego jest w przechowywaniu loginu czy "innych danych" w sesji?
- Z drugiej strony wymaga to trochę wkładu by taką sesję zapisać do bazy — jakieś specjalnej różnicy pomiędzy zapisem do pliku, a zapisem do bazy danych nie ma.
- wymagana jest wtedy serializacja obiektów ,zmiennych — a w przypadku plików to niby nie?
- dodatkowo procedura składowania sesji w bazie MySQL — do czego konkretnie będzie Ci tam potrzebna jakaś procedura?
- Minus,prędkość wczytywania strony spada o jakieś 20%— skąd Ci się to 20% wzięło? Poza tym możesz przechowywać dane sesji bezpośrednio w pamięci co zwiększy szybkość ładowania się podstron w większości przypadków.

To się tyczy pierwszych linijek tej ściany tekstu - reszty mi się komentować nie chce, bo nawet nie ma to związku z tematem.

[Rid]

Może Pan używać tych odpowiedników w swojej stronie,nie ma języka programowego czysto napisanego w języku polskim,jest natomiast select, insert, update no i obiekt Session a nie obiekt Sesja, bo tak może Pan nazwać swoją zmienną.
1.Nie zajmowałem się innymi bazami ,nie piszę tutaj publikacji i porównań między bazami relacyjnymi i tymi nie.

2.Wycina, Pan wyrazy wyrwane z kontekstu i je krytykuje-Napisałem przecież na początku" Można użyć" ,potem-"jednak nie jest to wskazane."Najlepiej jest użyć Id użytkownika.

3.Nie jest moją winą, że nie widzi Pan różnicy między zapisem do pliku, a do bazy danych.

4.Choćby ,procedura usuwania sesji, która uległa przedawnieniu,same się przecież nie usuną z bazy.

5.Temat różnić prędkości, już opisałem.

6.Nie będę już pisał na tym forum a przynajmniej z Panem, nie mam ochoty się kłócić,nie po to chyba jest te forum,jak już wyżej napisałem chciałem przedstawić swoją koncepcję,a jeśli coś źle napisałem należałoby po prostu sprostować,jeśli w czymś popełniłem błąd, lub coś się Panu nie podoba.Krytykować jest łatwo:)

[everth]

Źródła, proszę państwa, źródła. Przynajmniej wypowiedzi można będzie skonfrontować i wybrać wartościowe.

[Crozin]

Co innego opisywać konkretne konstrukcje czy elementy języka, co innego nazywać pewne nie związane nawet z samym językiem mechanizmy. Dane "insertujesz do db" czy "dodajesz do bazy"? Jeszcze rozumiem, gdy takie "kaleczenie języka" istotnie upraszcza wypowiedź (sprawdź w IFie czy $a = 5 VS dodaj sobie instrukcję warunkową sprawdzającą czy zmienna a ma wartość równą 5) albo gdy nie istnieje polski popularny odpowiednik.
Wracając do sesji. Sesja to nie żaden obiekt, to mechanizm pozwalający na identyfikację kolejnych żądań - dla przypomnienia: protokół HTTP jest protokołem bezstanowym (ang. stateless). Dlatego właśnie mówimy o mechanizmie sesji, a nie o mechanizmie session. Dane przechowujemy w sesji (co prawda jest to zdanie kompletnie bezsensowne, ale każdy doskonale wie o co chodzi), a nie w session. Trochę tak jakbyś pisał o użyciu variable zamiast zmiennej.

Wycina, Pan wyrazy wyrwane z kontekstu i je krytykuje

Tak, wycinałem zdania, ale nawet podając całe nie zmieniłbym swoich pytań. Napisałeś "można ... ale" - odniosłem się do samego "ale", ponieważ istotne było jedynie to "ale".

Nie jest moją winą, że nie widzi Pan różnicy między zapisem do pliku, a do bazy danych.

Czepianie się... oczywiście, że kod się różni. Ale raczej dla nikogo nie powinno być wielkim problem zamienienie pomiędzy jednym i drugim.

Choćby ,procedura usuwania sesji, która uległa przedawnieniu,same się przecież nie usuną z bazy.

Z systemu pliku / pamięci też się same nie usuną.

Temat różnić prędkości, już opisałem.

Twoja odpowiedź pojawiła się w momencie gdy ja pisałem swoją, tak więc nie miałem okazji jej przeczytać. Mimo wszystko... nie pokazałeś żadnych testów. Poza tym większość silników bazodanowych potrafią operować bezpośrednio w pamięci.

[...] nie mam ochoty się kłócić,nie po to chyba jest te forum [...]

W gruncie rzeczy jest to jeden z podstawowych celów for - prowadzenie dyskusji (tak, sprzeczanie się jest formą dyskusji, nie kłótni).

Chciałem przedstawić swoją koncepcję przetrzymywania danych, za co zostałem skrytykowany:(

Zostałeś skrytykowany ponieważ... należało Ci się. Beznadziejnie napisany post w wielu momentach kompletnie niezwiązany z tematem. Nie rozumiem natomiast dlaczego zamiast przyjąć krytykę (konstruktywną jakby na to nie patrzeć) burzysz się i dziękujesz za dyskusję.