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?

Bez najmniejszego problemu

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

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

Dlaczego nieszczęsne?

@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

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

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

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.

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.

@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ę.

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).

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ć

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

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...

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

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ą.

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.

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:(

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.

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:)

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

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.

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".
Czepianie się... oczywiście, że kod się różni. Ale raczej dla nikogo nie powinno być wielkim problem zamienienie pomiędzy jednym i drugim.
Z systemu pliku / pamięci też się same nie usuną.
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.
W gruncie rzeczy jest to jeden z podstawowych celów for - prowadzenie dyskusji (tak, sprzeczanie się jest formą dyskusji, nie kłótni).
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ę.

Z drugiej strony ,to tak jakby Pan o polu input powiedział mechanizm przechwytywania danych,a jest to obiekt ,który ma swoje cechy i właściwości -tak jak i obiekt Session.
Co Pan powie o cookies,jaki to będzie mechanizm?
Dla przykładu:
http://windowshosting.pl/print/Zrozumiec.s...cji.ASP.NET.2.0-takich stron mogę znaleźć dziesiątki ,łącznie z MSDN.

-To a propo skąd mi się wzięło 20 %.To jest ASP powiecie a tymczasem ,czytam na stronie manuala MySQL:

.
ze źródła http://dev.mysql.com/tech-resources/articl...procedures.html.
Czyli sprawa,szybkości składowanie przykładowo sesji w bazie danych w PHP,wygląda na wolniejszą, niż w ASP,który używa składni języka C#.

obiekt session istnieje w przytoczonym ASP.NET co nie oznacza że sesja jest obiektem bo bezsprzecznie nim nie jest, najprościej to po prostu mechanizm pozwalający na przechowywanie danych pomiędzy kolejnymi zapytaniami. To czy w ASP sesja jest reprezentowana przez obiekt session, czy też w PHP przez tablicę $_SESSION to kwestia języka.

Druga sprawa to kwestia wydajności, nie ma się co dziwić, że przechowywanie sesji w bazie danych wpływa negatywnie na czas ładowania strony. Przytoczony fragment z manuala mysql dotyczy wydajności procedur, dziwne byłoby gdyby procedury wbudowane działały wolniej niż te które dopiero muszą zostać zinterpretowane.



A tego niestety nie udało mi się zrozumieć, skąd taki wniosek ?

Powyższy przykład z Mysql powinien wyjaśnić.
Niech Pan ,zobaczy różnice między kompilatorem(c#),a interpreterem(PHP).Jeśli w ASP system składowanie sesji do bazy spowalnia, wczytywanie strony o jakieś 10-20%,to w PHP sytuacja musi wyglądać podobnie lub nawet gorzej.

Jeśli chodzi o nazwę sesji ,to w PHP najwidoczniej używa się nazwy mechanizm, w ASP.net piszę się o sesji jako o obiekcie.

Składowanie sesji w bazie danych jest o jakieś 10 - 20% wolniejsze od składowania jej bezpośrednio w pamięci. Jak to ma się do czasu wczytywania strony? Zapewne jest to różnica kompletnie niezauważalna.