Koszyk w sesji czy w bazie? Opcje

[Niktoś]

Niktosiu, w takim razie w jaki sposób implementujesz autoryzację?

Nie implementuje, mam system otwarty.Wszyscy mogą kupować.
Nierelacyjna baza to to samo co sesje?No przestań żartować.Inny obszar składowania danych,do którego użytkownik nie ma bezpośredniego dostępu,a sama aplikacja łączy się z nierelacyjną bazą danych przez tzw. connection stringa.Te połączenie akurat w tej bazie mogę zaszyfrować przez ssl.Chyba by mi się musieli na komputer wbić i bezpośredni dane z pamięci pobrać ,żeby coś naskrobać.

[greycoffey]

Nie implementuje, mam system otwarty.Wszyscy mogą kupować.
Nierelacyjna baza to to samo co sesje?No przestań żartować.Inny obszar składowania danych,do którego użytkownik nie ma bezpośredniego dostępu,a sama aplikacja łączy się z nierelacyjną bazą danych przez tzw. connection stringa.Te połączenie akurat w tej bazie mogę zaszyfrować przez ssl.Chyba by mi się musieli na komputer wbić i bezpośredni dane z pamięci pobrać ,żeby coś naskrobać.

Prawde mówiąc: gówno wiesz na temat tych ataków które wymieniłeś. Wszystkie z nich mają związek z użytkownikiem oraz serwerem, nie między serwerem a miejscem przechowywania sesji. Oraz session posioning - tutaj wymagany jest programista idiota. W takim razie jak identyfikujesz użytkownika, że to właśnei on ma jakieś konkretne zasoby w twojej sesji, tfu, przepraszam, NIERELACYJNEJ BAZIE DANYCH. Czy użytkownik ma dostęp do miejsca, w którym przechowywane są domyślne sesje PHP? Nie. TO JEST TWOJA IMPLEMENTACJA SESJI! Zresztą, widziałeś te linki które przesłałem post przed twoim? Sesja to mechanizm, który przechowuje dane i przydziela je konkretnym użytkownikom na podstawie losowego klucza, najczęściej i najbezpieczniej przechowywanego w ciasteczku z flagą httpOnly. To czy ona jest zaimplementowana na twojej NIERELACYJNEJ BAZIE DANYCH, podkreślam, NIERELACYJNEJ, i musisz wymieniać jesj NIERELACYJNOŚĆ na każdym kroku, czy na relacyjnej bazie danych, w pliku, w pamięci (PHP ma już wbudowaną obsługę memcache oraz memecached, także sqlite) czy w zaszyfrowanej ciemnej dupie - to nie ma znaczenia.

Nazwij to jak chcesz, ale twoja NIERELACYJNA BAZA DANYCH to SESJA.

[Niktoś]

Prawde mówiąc: gówno wiesz na temat tych ataków które wymieniłeś. Wszystkie z nich mają związek z użytkownikiem oraz serwerem, nie między serwerem a miejscem przechowywania sesji.

No ale standardowo sesje przecież zapisują się w obszarze pamięci serwera użytkownik "bezpośrednio" z tego opszaru korzysta, zaś nierelacyjne bazy danych w cache komputera do którego serwer aplikacji "bezpośredniego" dostępu już nie ma i to jest różnica ,którą Ty najwidoczniej nie potrafisz zauważyć.

Ten post edytował Niktoś 6.05.2012, 11:50:56

[greycoffey]

No ale standardowo sesje przecież zapisują się w obszarze pamięci serwera użytkownik "bezpośrednio" z tego opszaru korzysta, zaś nierelacyjne bazy danych w cache komputera do którego serwer aplikacji "bezpośredniego" dostępu już nie ma i to jest różnica ,którą Ty najwidoczniej nie potrafisz zauważyć.

Śmiesznyś! Standardowo sesje zapisują się w /tmp (obszar pamięci serwera? dysk po prostu), ale to mozna zmienić - session.save_path. Powiedz mi w takim razie, co pośredniczy między serwerem aplikacji a twoją nierelacyjną bazą danych, jak to wpływa na bezpieczeństwo i czym się to różni od sesji oprócz miejsca przechowywania danych? Uzytkownik nie korzysta z tego obszaru, bo nie ma do niego dostępu. Na jakiej podstawie rozpoznajesz, że dany użytkownik posiada dany koszyk?
Nie zmienia to jednak faktu który od początku tego tematu wymieniam: To, że korzystasz ze swojej nierelacyjnej bazy danych zamiast z jakiegoś innego kontenera danych, nie zmienia faktu, że jest to sesja i nic więcej.

[tehaha]

nierelacyjne bazy danych w cache komputera do którego serwer aplikacji "bezpośredniego" dostępu już nie m

W jakim cache komputera? Mógłbyś to rozwinąć?

[wNogachSpisz]

Pytanie dobre, ale obawiam się że autor w zależności od odpowiedzi weźmie się za pisanie zupełnie różnego kodu. Bez sensu.
W CodeIgniterze jest to rozwiązane prawidłowo. Koszyk korzysta z sesji a sesja korzysta albo z cookie albo z bazy - do ustawienia w configu. Amen.

[greycoffey]

Generalnie najlepiej zaimplementować to w PHP 5.4 używając już istniejących klas i interfejsów, ale można też napisać własną nakładkę na sesję - klasa Factory tworząca odpowiednie obiekty interfejsu SessionHandlerInterface, obsługujące poszczególne bazy danych, pliki, pamięć czy wszystko co sobie wymyślisz.

[Niktoś]

W jakim cache komputera? Mógłbyś to rozwinąć?

Chodziło mi o to że działa w innym,odrębnym procesie systemowym niezależnym od serwera IIS, czy innym.

Standardowo sesje zapisują się w /tmp (obszar pamięci serwera? dysk po prostu), ale to mozna zmienić - session.save_path.

Widzisz ,a u mnie w nierelacyjnej bazie nie ma śladu na dysku ,ani żadnych folderów ,aplikacja korzysta z pamięci RAM, i jest niezależna od serwera.
Więcej info Tutaj

Powiedz mi w takim razie, co pośredniczy między serwerem aplikacji a twoją nierelacyjną bazą danych.

Klient(zbiór klas) tejże bazy, odpowiadających za nawiązanie połączenia z bazą i manipulowanie danymi.

Na jakiej podstawie rozpoznajesz, że dany użytkownik posiada dany koszyk?

Opisałem wcześniej, nie czytasz.

Nie zmienia to jednak faktu który od początku tego tematu wymieniam: To, że korzystasz ze swojej nierelacyjnej bazy danych zamiast z jakiegoś innego kontenera danych, nie zmienia faktu, że jest to sesja i nic więcej.

Tak,relacyjne(MySql, MSSQL ,inne) jak i nie relacyjne bazy danych, pliki tekstowe jak i xml pełniące funkcję kontenerów danych to wszystko to są sesje (IMG:style_emoticons/default/wink.gif)

Ten post edytował Niktoś 6.05.2012, 16:06:29

[tehaha]

Tak,relacyjne(MySql, MSSQL ,inne) jak i nie relacyjne bazy danych, pliki tekstowe jak i xml pełniące funkcję kontenerów danych to wszystko to są sesje

Nie to nie są sesje, sesja to mechanizm pozwalający na identyfikację użytkownika pomiędzy żądaniami http poprzez identyfikator w ciastku, a to czy sesja jest oparta o pliki czy bazę to już inna kwestia.

Chodziło mi o to że działa w innym,odrębnym procesie systemowym niezależnym od serwera IIS, czy innym.

Ogólnie to trochę kręcisz, bo wcześniej pisałeś, że trzymasz te dane tam gdzie serwer nie ma do nich dostępu, co ma zabezpieczać przed włamaniem, może najlepiej jakbyś pokazał kawałek kodu to wtedy skończymy te puste odbijanie piłeczki, bo wygląda na to, że używasz sesji opartej o bazę, ale wydaje Ci się, że to nie jest sesja bo nie jest oparta o domyślne pliki w tmp/.

aplikacja korzysta z pamięci RAM, i jest niezależna od serwera.

różnica między trzymaniem sesji na dysku a w pamięci RAM jest bardziej w wydajności niż bezpieczeństwie, poza tym RAM ma tą wadę, że te dane mogą zostać łatwo utracone i użytkownicy zostaną wylogowani lub utracą inne dane

@Niktoś nie traktuj tego personalnie bo chodzi głównie o to, że potem początkujący czytają takie tematy i głupio powtarzają "a ja czytałem, że sesje są niebezpieczne i nie można z nich korzystać" bo ostatnio co raz więcej takich ludzi na forum, trzeba być świadomym zagrożeń i zabezpieczać się poprzez odpowiednią logikę systemu i standardowe zabezpieczenie. Ponadto należy stosować rozwiązania zgodnie z ich przeznaczeniem bo nie ma nic gorszego niż fałszywe poczucie bezpieczeństwa

[Niktoś]

Nie to nie są sesje, sesja to mechanizm pozwalający na identyfikację użytkownika pomiędzy żądaniami http poprzez identyfikator w ciastku, a to czy sesja jest oparta o pliki czy bazę to już inna kwestia.

Ja to wiem, ale co niektórzy chyba myślą inaczej.

Ogólnie to trochę kręcisz, bo wcześniej pisałeś, że trzymasz te dane tam gdzie serwer nie ma do nich dostępu, co ma zabezpieczać przed włamaniem, może najlepiej jakbyś pokazał kawałek kodu to wtedy skończymy te puste odbijanie piłeczki, bo wygląda na to, że używasz sesji opartej o bazę, ale wydaje Ci się, że to nie jest sesja bo nie jest oparta o domyślne pliki w tmp/.

Używam sesji,a raczej jej SID tylko i wyłącznie do kojarzenia kosza z użytkownikiem, bo jest unikalna. Równie dobrze mógłbym w MSSQL ,czy w MYSQL utworzyć unikalny token i po nim identyfikować i sesji w ogóle nie używać, ale po co jak to się sprawdza. Absolutnie nie są używane sesje jako kontener danych, to robi nierelacyjna baza.Jeśli chodzi o kod ,to co mam pokazać jak nawiązuje połączenie z tą bazą danych? Dane pochodzą bezpośrednio z wysyłanych formularzy i zapisywane do nierelacyjnej bazy danych.Zobacz na ten link co podałem wyżej a będziesz wiedział, mniej więcej jak to działa. Fajna rzecz, naprawdę.

różnica między trzymaniem sesji na dysku a w pamięci RAM jest bardziej w wydajności niż bezpieczeństwie, poza tym RAM ma tą wadę, że te dane mogą zostać łatwo utracone i użytkownicy zostaną wylogowani lub utracą inne dane

Tu się z tobą zgodzę-chociaż nie za bardzo rozumie co miałeś na myśli ,przez "łatwo".Chodzi o ewentualny restart komputera,chwilowy zanik prądu itp.?Sesje też na to nie są odporne przynajmniej te in-proc,zapisywane w bazie danych czy na serwerze owszem są.

@Niktoś nie traktuj tego personalnie bo chodzi głównie o to, że potem początkujący czytają takie tematy i głupio powtarzają "a ja czytałem, że sesje są niebezpieczne i nie można z nich korzystać" bo ostatnio co raz więcej takich ludzi na forum, trzeba być świadomym zagrożeń i zabezpieczać się poprzez odpowiednią logikę systemu i standardowe zabezpieczenie. Ponadto należy stosować rozwiązania zgodnie z ich przeznaczeniem bo nie ma nic gorszego niż fałszywe poczucie bezpieczeństwa

Nie biorę tego personalnie, ale jak pisałem w jednym z pierwszych postów, dużo czytałem o bezpieczeństwie sesji i może udzieliła mi się paranoja-nie wiem. Ogólnie rzecz biorąc takie rozwiązanie jakie zastosowałem ,wydaje mi się dużo bezpieczniejsze.

Ten post edytował Niktoś 6.05.2012, 17:51:48

[r4xz]

Używam sesji,a raczej jej SID tylko i wyłącznie do kojarzenia kosza z użytkownikiem, bo jest unikalna

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! tylko na co komu kolejne wydatki (pełen kosz) etc...? twoja obsesja na punkcie bezpieczeństwa kompletnie traci tutaj sens (IMG:style_emoticons/default/wink.gif)

prosta sesja i po sprawie, a bezpieczeństwo? owszem, ale nie trzymamy tutaj danych kodu genetycznego czy czegoś w tym stylu, tylko zwykł koszyk... w supermarkecie chyba też nie przykrywacie koszyka kocem żeby nikt nie ukradł co nie (trochę taki dziwny przykład, ale jest (IMG:style_emoticons/default/smile.gif) )?

[tehaha]

Równie dobrze mógłbym w MSSQL ,czy w MYSQL utworzyć unikalny token i po nim identyfikować i sesji w ogóle nie używać,

No właśnie nie mógłbyś byś. Bo jak wtedy zidentyfikujesz użytkownika bez sesji? Sesja oparta o MsSQL/MySQL to jest dalej sesja.

Sesje też na to nie są odporne przynajmniej te in-proc, zapisywane w bazie danych czy na serwerze owszem są.

in-process to chyba w asp.net a nie php

Ogólnie rzecz biorąc takie rozwiązanie jakie zastosowałem ,wydaje mi się dużo bezpieczniejsze.

No właśnie, wydaje Ci się... bo wydaje Ci się, że sesji nie używasz i przez to nie jesteś podatny na jej ataki, ale okazuje się, że jednak sesji używasz i to jest właśnie to fałszywe poczucie bezpieczeństwa.

[greycoffey]

w supermarkecie chyba też nie przykrywacie koszyka kocem żeby nikt nie ukradł co nie (trochę taki dziwny przykład, ale jest (IMG:style_emoticons/default/smile.gif) )?

Hahaha padłem ;D

Btw, PHP ma już wbudowany mechanizm sesji korzystający z memcache (IMG:style_emoticons/default/wink.gif) Ja sobie piszę coś na APC, bo z tego akceleratora korzystam.
Co do przechowywania na dysku a nie w ram, można zrobić tak:

Kod

mount -t tmpfs -size=128M,nr_inodes=1M tmpfs /tmp

I sesja jest już przechowywana w RAMie (IMG:style_emoticons/default/wink.gif)

Kolejny raz ewangelizuję: Sesja to mechanizm kojarzący konkretnego użytkownika z jego konkretnymi danymi przechowywanymi na serwerze.
Jako, że HTTP to protokół bezstanowy, najlepszym i najbezpieczniejszym rozwiązaniem jest kojarzenie na podstawie losowo utworzonego klucza przechowywanego w ciastku użytkownika z flagą httpOnly (i jeśli się da - SSL).

Ten post edytował greycoffey 6.05.2012, 18:45:23

[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

[tehaha]

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

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?

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

Dokładnie i w tym momencie sam doszedłeś do wniosku, który próbowaliśmy Ci wytłumaczyć jak napisałeś:

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

Przy odpowiedniej logice systemu manipulacja danych w sesji nie jest w takim przypadku groźna, więc koszyk można spokojnie o to oprzeć. Ale podmiana danych to tylko jeden z możliwych ataków na sesje, 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.

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

,bo te dane siedzą w relacyjnej bazie danych

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

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

Amen, napisali i my też piszemy: "nie przechowuje się haseł w sesjach !", a nie: "nie używaj sesji", w bazie danych tak samo nie przechowuje się haseł, ani w plikach i ramie też nie.

Ogólnie z tematu zrobił się już trochę śmietnik, a chodzi o jedną prostą rzecz: napisałeś, że sesji nie używasz bo są niebezpieczne ale właśnie to co opisujesz to jest mechanizm sesji i go używasz, a jak używasz to go zabezpiecz. pozdro

[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

[aachi]

Przepraszam, że się wtrącam w waszą dyskusję, ale kilka razy sam zbytnio się zagalopowałem na innych forach i byłem wdzięczny, gdy postronne osoby pomogły mi ochłonąć.

Więc Niktoś... Nie masz racji. Greycoffey ma - CAŁKOWITĄ. Przeczytaj uważnie co Ci napisał, wiele się nauczysz, bo on na prawdę gada z sensem.

Wydaje mi się Niktoś, że dla Ciebie pojęcie sesji oznacza tylko i wyłącznie session w PHP (czyli session_start(), tablica $_SESSION itd.). Jest to pojęcie błędne. Sesja, jak greycoffey i tehaha tłumaczył, to każdy mechanizm pozwalający w bezstanowym protokole jakim jest HTTP, zidentyfikować kolejne połączenia od tego samego użytkownika. I też się pod tym podpisuje, a kompletnie nie znam tych dwóch panów.

Rozumiem, że dane "co kto trzyma w koszyku" zapisujesz w bazie, a do identyfikacji użytkownika używasz wbudowanego mechanizmu sesji PHP. Z tego co mówisz nadal jednak wynika, że te dane w bazie to dane sesyjne (bez względu czy do ich przechowywania używasz mechanizmu wbudowanego w PHP, czy innego - w tym wypadku swojego własnego).

Więc jeszcze raz: Niktoś zagalopowałeś się i zaczynasz coraz bardziej bełkotać. I kolejna osoba stara się Ci to wytłumaczysz (JA). Tylko od Ciebie zależy, czy zignorujesz te wiele osób i będziesz dalej upierał się przy swoim odosobnionym zdaniu. W tym wątku to greycoffey ma rację.

Przepraszam, że się wtrąciłem.

[Niktoś]

A niech to odpalę troszeczkę kodu ,mam nadzieję ,że ktoś go zrozumie bo to c#.NET:
Nawiązuje połączenie z nierelacyjną bazą danych (klient-serwer),może być połączenie szyfrowane lub nie:

[CSHARP] pobierz, plaintext 
if (((Session["SSID_SESJI"] == null) || &&(!Page.IsPostBack))
        {
            Session["SSID_SESJI"] = HttpContext.Current.Session.SessionID;
            HttpCookie Cuzytk = new HttpCookie("UZ");
            Cuzytk.Expires.AddMinutes(20);
            Cuzytk.Secure = true;
            Cuzytk.HttpOnly = true;
            Cuzytk.Value = Session["SSID_SESJI"].ToString();
            Response.Cookies.Add(Cuzytk);
        }
        else {
            Session["SSID_SESJI"] = Request.Cookies["UZ"].Value;
 
        }
 
If(IsPostback){
TupleSpace ts = new TupleSpace("localhost", PORT, "INSTANCJA", "", new String[] { "NazwaPołączenia" });
 string Dane_Z_Inputa = Request["input1"];
string Dane_Z_Inputa1 = Request["input2"];
string Dane_Z_Inputa2 = Request["input3"];
string Dane_Z_Inputa3 = Request["input4"];
Field a = new Field(Dane_Z_Inputa );
Field b = new Field(Dane_Z_Inputa1);
Field c = new Field(Dane_Z_Inputa2);
 Field d = new Field(Dane_Z_Inputa3);
Field e= new Field(Session["SSID_SESJI"].ToString());
 Collide.SQLSpaces.Tuple tup = new Collide.SQLSpaces.Tuple(new Field[] { a, b, c, d,e});
TupleID id = ts.write(tup);
}
[CSHARP] pobierz, plaintext 

Wyszukiwanie w że tak powiem w "rekordach" bazy danych:

[CSHARP] pobierz, plaintext 
Collide.SQLSpaces.Tuple templates = new Collide.SQLSpaces.Tuple(new Field[] { new Field(typeof(string)), new Field(typeof(string)), new Field(typeof(string)), new Field(typeof(string)),HttpContext.Current.Session["SSID_SESJI].ToString())) }); //zapis ten odczytuje wszystkie rekordy,które zawierają Session["SSID_SESJI]-to jest właśnie powiązanie użytkownika z koszem
            Collide.SQLSpaces.Tuple[] tup2 = ts.readAll(templates);
[CSHARP] pobierz, plaintext 

Tup2 zawiera wszystkie rekordy użytkownika Session["SSID_SESJI]-Żadnych danych do sesji nie pchałem,oprócz jej SID.

Z tego co mówisz nadal jednak wynika, że te dane w bazie to dane sesyjne (bez względu czy do ich przechowywania używasz mechanizmu wbudowanego w PHP, czy innego - w tym wypadku swojego własnego).

Tak tylko i wyłącznie SID jak przykład wskazuje.
Zresztą ta implementacja bazy danych również jest dostępna dla języka PHP-link wyżej.

Ten post edytował Niktoś 6.05.2012, 22:26:36

[Fifi209]

Niktoś robisz straszny burdel w kodzie. Czemu dane z inputa nie są tablicą ? Tylko 1,2,34 ? Tak samo Field nie wiem czy wiesz ale możesz tworzyć tablice obiektów, listę danego typu etc.

Poziom kodu równie niski co dyskusji, którą śledzę cały czas.

Ten post edytował Fifi209 6.05.2012, 22:31:40

[tehaha]

To co pokazałeś to jest sesja oparta o bazę.

Tak tylko i wyłącznie SID

No i właśnie na tym SID opiera się sejsa i ono ma tutaj fundamentalne znaczenie...bo teoretycznie dalej przy pomocy xss czy też session sidejacking, można podszyć się pod użytkownika, więc wcale się przed tym nie zabezpieczyłeś tylko założyłeś, że jak zaimplementowałeś własny mechanizm sesji to wyeliminowałeś wszystkie możliwości ataku na sesje, co jest niestety błędnym założeniem. Tyle w temacie. Dziękuję dobranoc.