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

[Niktoś]

No właśnie nie mógłbyś byś. Bo jak wtedy zidentyfikujesz użytkownika bez sesji?

No właśnie nie czytałeś, albo zbyt ogólnikowo to napisałem.Mógłbym dla każdego użytkownika utworzyć unikalny token i zapisać w MSSQL, czy MySQL i według tego identyfikować kosz dla użytkownika.Wcale bym nie musiał używać SID'a sesji,ale po co-to rozwiązanie jest łatwiejsze.Jak nie będzie spełniało moich wymogów bezpieczeństwa(będą częste manipulacje), to utworzę dodatkową kolumnę w bazie MSSQL z unikatowym tokenem.Na razie nie ma ani jednego odwołania do bazy danych MSSQL w moim systemie koszyka.Następuje dopiero przy realizacji zamówienia i o taki efekt mi chodziło.

a więc jesteś narażony na wszystkie ataki (które wymieniłeś), co gorsza - korzystasz z ciasteczek, a więc ktoś może przechwycić twoje dane!

I tutaj się bardzo mylisz, bo ja nie zapisuję danych do ciasteczek ,tylko SID ,żeby sesję podtrzymać jak ktoś zamknie browser i wróci ponownie, dane zaś siedzą sobie w nierelacyjne bazie danych,czyli w oddzielnej aplikacji.
Jak nawet ktoś zmanipuluje danymi czy to w cookies,czy w sesji to po prostu otrzyma inny (czyjś)koszyk,ale nie zmieni samych danych(kwot,nazw przedmiotów,adresu itp.),bo te dane siedzą w nierelacyjnej bazie danych,ewentualnie doda nowy produkt lub jakiś usunie i tyle uda mu się uzyskać nic poza tym.

W przypadku manipulacji koszyku opartym na sesji,przechwycenie ,czy wstrzyknięcie(poisoning) może mieć znacznie gorsze konsekwencje np. manipulacja danymi ,podmiana kwot ,podmiana nazw produktów itp., gdyż wszystkie dane są (zserializowane) i umieszczone w sesji.Nie wiem jak przebiega dokładnie ataki na sesje ,czy są trudne ,czy w ogóle praktycznie możliwe, ale możliwości ataków są i nie należy ich wykluczać.

I teraz takie praktyczne pytanie:Można przejrzeć liczne tematy, liczne fora i wszędzie programiści piszą :"nie przechowuje się haseł w sesjach !". Dlaczego tak piszą, jeżeli rzeczywiście sesje są tak bezpieczne jak co niektórzy piszą?
EDIT: @DOWN

Nie chodzi o to gdzie zapiszesz ten identyfikator tylko w jaki sposób użytkownik będzie Ci go przesyłał jeśli nie przez mechanizm sesji?

W końcu zajarzyłem-np.przez geta w urlu.

Na razie nie ma ani jednego odwołąnia do bazy danych w moim systemie koszyka

Te 2 chyba trochę sobie przeczą....

Chodziło mi o bazę danych MSSQL.Poprawiłem bo faktycznie namieszałem.

ale na pozostałe rodzaje ataków Twój sposób już jest narażony, bo przykładowo jak hacker ukradnie użytkownikowi sesje, żeby się za niego poszyć to nie ma w tym momencie znaczenia czy masz sesję opartą o bazę, pliki, czy ram.

Nie, globalnie mam flagę httpOnly na coocies,dodatkowo mogę wprowadzić flagę secure na sesje(wymaga ssl).

Nie chce nabijać postów więc odpowiadam tutaj.

Ten post edytował Niktoś 6.05.2012, 21:11:02

[greycoffey]

No właśnie nie czytałeś, albo zbyt ogólnikowo to napisałem.Mógłbym dla każdego użytkownika utworzyć unikalny token i zapisać w MSSQL, czy MySQL i według tego identyfikować kosz dla użytkownika.Wcale bym nie musiał używać SID'a sesji,ale po co-to rozwiązanie jest łatwiejsze.Jak nie będzie spełniało moich wymogów bezpieczeństwa(będą częste manipulacje), to utworzę dodatkową kolumnę w bazie MSSQL z unikatowym tokenem.Na razie nie ma ani jednego odwołąnia do bazy danych w moim systemie koszyka.Następuje dopiero przy realizacji zamówienia i o taki efekt mi chodziło.

Czyli używasz SIDa - btw. SID to Session IDentity, czyli jakikolwiek identyfikator sesji.

I tutaj się bardzo mylisz, bo ja nie zapisuję danych do ciasteczek ,tylko SID ,żeby sesję podtrzymać jak ktoś zamknie browser i wróci ponownie, dane zaś siedzą sobie w nierelacyjne bazie danych,czyli w oddzielnej aplikacji.
Jak nawet ktoś zmanipuluje danymi czy to w cookies,czy w sesji to po prostu otrzyma inny (czyjś)koszyk,ale nie zmieni samych danych(kwot,nazw przedmiotów,adresu itp.),bo te dane siedzą w relacyjnej bazie danych,ewentualnie doda nowy produkt lub jakiś usunie i tyle uda mu się uzyskać nic poza tym.

Ech.. Sesja a ciastka łączą się tym, że ciastka zawierają bardzo czesto SID - a to jest dobrym rozwiązaniem. Jedynie idioci (z punktu bezpieczeństwa) zapisują dane przeznaczone dla sesji w ciasteczkach.
To twoje zachowanie cechuje się dla praktycznie każdej sesji, a możliwo·ść ataku Session Poisoning to wina programisty.

W przypadku manipulacji koszyku opartym na sesji,przechwycenie ,czy wstrzyknięcie(poisoning) może mieć znacznie gorsze konsekwencje np. manipulacja danymi ,podmiana kwot ,podmiana nazw produktów itp., gdyż wszystkie dane są (zserializowane) i umieszczone w sesji.Nie wiem jak przebiega dokładnie ataki na sesje ,czy są trudne ,czy w ogóle praktycznie możliwe, ale możliwości ataków są i nie należy ich wykluczać.

Ponownie: g**** wiesz. Jak już wyżej wspomniałem, Session Poisoning to wina daremnego programisty, który tworzy potworki typu:

[PHP] pobierz, plaintext 
$_SESSION[$_GET['name']] = $_GET['value'];
[PHP] pobierz, plaintext 

A przechwycenie sesji, jak wyżej wspomniałeś: zmanipuluje danymi czy to w cookies,czy w sesji to po prostu otrzyma inny (czyjś)koszyk,ale nie zmieni samych danych(kwot,nazw przedmiotów,adresu itp.),bo te dane siedzą w relacyjnej bazie danych,ewentualnie doda nowy produkt lub jakiś usunie i tyle uda mu się uzyskać nic poza tym.

I teraz takie praktyczne pytanie:Można przejrzeć liczne tematy, liczne fora i wszędzie programiści piszą :"nie przechowuje się haseł w sesjach !". Dlaczego tak piszą, jeżeli rzeczywiście sesje są tak bezpieczne jak co niektórzy piszą?

Nie przechowuje się haseł w sesjach. Nie przechowuje się cen produktów w sesjach. Nie przechowuje się nazw przedmiotów w sesjach.
Sesje poprawnie zaimplementowane są bezpieczne, jednak zgodnie z zasada przezorny zawsze ubezpieczony oraz atomowości danych, nie przechowuje się rzeczy stałych (nazwa produktu, cena) tylko identyfikator (wskaźnik) do nich. Sesje są ulotne, nie ma sensu klonować bytów. Czy w twojej implementacji sesji nei da się wstawić ceny do sesji? Jeśli tak, to gratuluje pomysłowo·ści oraz świetnej sztucznej inteligencji.

Nie wiem jak przebiega dokładnie ataki na sesje ,czy są trudne ,czy w ogóle praktycznie możliwe

I to podsumowywuje twój poziom wiedzy. Nie wiesz jak ich dokonać, nie wiesz jak się przed nimi bronić. Nie wiesz nawet, czy to, przed czym się "bronisz" jest możliwe. Praktykę i teorię trzeba łączyć. A tutaj widzę, że nawet teorii nie ma. Session Hijacking jest możliwe w praktycznie każdej implementacji sesji, kiedy połączenie nie jest szyfrowane w obrębie całego zasięgu ciastka z SIDem (chociaż wtedy można pewnie dokonać MITM). Session Fixation to właściwie brute-force na identyfikatorze sesji, tutaj siła zabezpieczenia jest równa ilości wszystkich możliwych identyfikatorów sesji. Sesion Poisoning to już wina programisty-idioty, jak już wcześniej wspomniałem.

Update do twojego update^^:

Nie, globalnie mam flagę httpOnly na coocies,dodatkowo mogę wprowadzić flagę secure na sesje(wymaga ssl).

To nei wyklucza ataku MITM, CSRF w celu uzyskania identyfikatora sesji. Dodatkowo, SID może być generowany po kolei przez włamywacza, w celu trafienia na jakiś - tutaj przydają się dodatkowe zabezpieczenia jak np. sprawdzanie czy w jednej sesji nie zmienił się USER_AGENT, akceptowane języki etc. - stałe ustawienia danej przeglądarki.


Ten post edytował greycoffey 6.05.2012, 21:15:43