Koszyk w sesji czy w bazie? Opcje

[usb2.0]

Witam
jak w temacie
sam nie wiem jak do końca to rozwiązać więc czekam na za i przeciw.
Pozdrawiam

[greycoffey]

Może generalizuje ,ale:
sesja= session hijacking, session fixation, session Poisoning-dużo możliwości manualowania danymi.To samo tyczy się coockies ,a może są jeszcze bardziej niebezpieczne.

Załóżmy klient kupuje artykułów na 20tys, głupio by było jakby tobie zamówienie wysłał na 2zł bo dobry hacker z niego i podmienił tobie dane sesji.Nie mówię już o wykradaniu adresów i e-maili.Chyba,że w sesji będziesz przechowywał klucze główne(id) do poszczególnych kolumn i wiązał je z bazą danych, wtedy to będzie w miarę bezpieczne.

Może to paranoja, ale dużo się naczytałem, że kluczowych danych w sesji czy cookie nie przechowuje się.

Niktosiu, w takim razie w jaki sposób implementujesz autoryzację? Czy wy nie rozumiecie, że sesje mogą być różnie zaimplementowane?
Session hijacking - obrona przed CSRF - tokeny oraz ciasteczko z SID httpOnly, w przypadku ataku man-in-the-middle pomoże wam tylko SSL, w innym wypadku ktoś i tak może się podszyć pod daną osobę, nei tylko przez ciastko z SID, ale także podsłuchując dane logowania, adresy etc.
Session fixation - wybacz, ale to zagrożenia związanee nie z samymi sesjami, potrzebna jest tu inna luka, przeważnie XSS.
Session poisoning - jak kotś ustawia dane sesyjne, na podstawie klucz generowanego przez podaną przez użytkownika daną, to jest głupi i zamiast programowaniem, powinien się zająć czymś innym.
Hahaha, w takim razie jak powiążesz kluczowe dane z niezalogowanym użytkownikiem, jak nie losowym kluczem przechowywanym w $_COOKIE?

@Niktoś
Kto normalny przechowuje np. ceny czy wartość zamówienia w sesji/cookies?

True^^.

Dane koszyka to raczej dane temporalne-użytkownik może zamówić, ale nie musi zrealizować zamówienia. Dlatego ta część aplikacji może stanowić problem. Używając bazy danych, w pewnym momencie może okazać się ,że jest to niewydajne.Są wszakże tabele temporalne(do czasu trwania sesji lub aplikacji) ,ale to także generuje masę zapytań do bazy danych ,a przy złożeniu zamówienia przez użytkownika trzeba by było zrobić zrzut zamówionych towarów z tabeli temporalnej do tabeli właściwej,aby zachować te dane.

Używanie samych sesji czy cookies do tego typu rzeczy do najbezpieczniejszych sposobów nie należy.

Ja użyłem nierelacyjną bazę danych -gdzie tak jak w cookies czy w sesji jest expiration time(można ustawić czas życia koszyka, co dla danych tymczasowych jest idealnym rozwiązaniem. Same dane zapisują się w pamięci-więc dostęp do nich jest znacznie szybszy.Cookies i Sesje identyfikują użytkownika po (SID) i po nich następuję pobranie odpowiednich danych z nierelacyjnej bazy danych.W sesji czy cookies nie ma żadnych dodatkowych danych tylko SID.Nawet jak ktoś mi zmanipuluje tymi danymi to co najwyżej dostanie inny koszyk, lecz nie zmanipuluje danymi w nich.

Ta twoja nierelacyjna baza danych to właśnie WŁASNA IMPLEMENTACJA SESJI, dlatego twoja implemntacja, tak samo jak podstawowa i wszystkie inne, może być podatna na wyżej wymienione przez ciebie ataki.
Mechanizm jest taki sam. Identyfikacja użytkownika po losowym kluczu, tylko zamiast z pliku korzystasz z bazy danych.
Twoja nierelacyjna baza danych to SESJA, przed którą tak bardzo przestrzegasz.

Nom w darmowym ,czy nawet płatnym hostingu tego nie zrobisz, musiałbyś co najmniej dedyka sobie sprawić.

Wystarczy VPS.

Śmieszy mnie niektórych niechęć wobec sesji, a zwłaszcza kiedy mówicie, że są złe, a sami używacie ich alternatywnej wersji "bazy danych". Wasz mechanizm różni się tylko tym, że dane są przechowywane w innym miejscu. A jakie tutaj zagrożenia? I do twojej bazy danych, i do tamtego pliku również można się w jakiś sposób dostać, czy bezpieczeństwo jest większe?