Wątek: Sesje

Cześć Mam chwilę wolnego czasu, trafiłem wczoraj na pewien artykuł odnośnie mechanizmu sesji w PHP. Trochę sobie myślałem przy okazji projektu gry, który czeka do 18. maja i wpadłem na taki oto pomysł:
napisać klasę do obsługi sesji, podpiąć ją, aby zastąpiła standardowy mechanizm odczytu i zapisu. Dane znajdowałyby się w bazie danych MySQL tabeli typu MEMORY, czyli w RAMie. Czy byłoby to ogólnie rozsądne rozwiązanie? Wiem, jakie dane będą tam przetrzymywane i że w przypadku resetu / braku zasilania serwera nie stracę żadnych ważnych danych, bo nie będą one tam przetrzymywane. Ogólnie byłoby to chyba szybsze i bezpieczniejsze (wiadomo trzeba odpowiednio zabezpieczyć się stosując funkcje natywne i własne do filtracji, np. długość ciągów (dawny błąd WordPress, dzięki któremu można było zdobyć szybko hasło administratora)), mógłbym też zrobić system dodatkowego zabezpieczenia przed CSRF, który powinien wtedy dobrze działać nawet przy dużym ruchu. Mógłby on dodatkowo pomóc w innej sprawie (kwestia (link) poruszona przez TorchLight, ale w innym wydaniu )
Czyli podsumowując: chcę w ten sposób osiągnąć większą wydajność i wprowadzając jednocześnie dodatkowe zabezpieczenia.
Co o tym myślicie? Liczę na konstruktywne wypowiedzi

Z tego co zrozumiałem a niedużo zrozumiałem to standardowa sesję chcesz zastąpić mysql'em. Powiem tak po tym co napisałeś chyba wiesz jak to zabezpieczyć i zrobić więc podsumuje. Zrób co uważasz za leprze. Ja nie mam tutaj nic do dodania bo połowy tego co napisałeś nie rozumiem.

Też nie bardzo zrozumiałem o czym piszesz tutaj, jednak co do sesji to czytałem że są niezbyt bezpieczne, jednak nie bardzo rozumiem jak chcesz to zrobić. Jeśli chcesz pomocy z mojej strony to rozpisz to łopatologicznie bo czuję się jakbyś mówił w innym języku

Tak, właśnie o to chodzi, że standardowe miejsce przechowywania sesji chcę zamienić, za pośrednictwem serwera MySQL, z plików na rekordy w bazie danych w konkretnej tabeli. Ta tabela byłaby przechowywana w pamięci RAM serwera, co bardzo przyspieszyłoby operacje na niej Służy do tego funkcja session_set_save_handler();, dzięki której zamiast standardowych funkcji obsługi sesji, możemy podpiąć własne, nawet metody klas.
Czyli efekt dla przykładu byłby taki:
echo $_SESSION['przyklad']; spowoduje pobranie odpowiedniej wartości bezpośrednio z pamięci RAM.
W MySQL mamy możliwy do wybrania typ tabeli MEMORY, która jest właśnie przechowywana w pamięci podręcznej.

Kiedyś przeczytałem o pewnej luce w WordPress, teraz jest to za pewne naprawione, która działała tak:
1. Użytkownik domyślny zawsze ma login admin.
2. Ktoś rejestruje nowe konto o loginie: admin_____________123. Podkreślenia to spacje.
3. Skrypt, widząc, że login jest za duży, ucina zbyt długą część, zostaje admin______
4. Własność MySQL: puste znaki z początku i końca ciągu są obcinane. Tym oto sposobem mamy założone konto o loginie admin, dalej co z tym można zrobić nie będę opisywał, ale jest tylko mały krok do przejęcia kontroli nad serwisem
Ten sposób w zmienionej formie, powiem szczerze, działa nadal działa w innych skryptach, niewiele osób sobie zdaje sprawę, że takie coś istnieje, nawet w niektórych silnikach gier jest skuteczny, a to jeden z prostszych rodzajów ataków - to odnośnie konieczności sprawdzania wszystkiego n-razy. Jest też dużo rzeczy, na które mało kto wpadł i niewiele osób o nich wie, a mogą się okazać groźne, bo akurat ten temat jest oklepany.

Co do CSRF, przykładem może być jakaś akcja w grze, np. adres.pl/gra.php?akcja=kasuj_konto&potwierdzone=tak i ktoś zamieści gdzieś jakiś link, inny gracz w niego wejdzie i jest po koncie. Przykład mocno naciągany, ale wydaje mi się, że dobitnie pokazuje, w czym tkwi problem. W połączeniu z innym udanym atakiem może wyrządzić spore problemy, sam z resztą też bywa bardzo groźny System tokenów, czyli specjalnych kodów zmienianych za każdą akcją i wykorzystany w odpowiedni sposób dobrze (ale nie w 100% zabezpiecza przed problemem, o 100% nie mówi się też do końca nawet w przypadku przesyłania jednorazowych kodów SMS).

W tamtym temacie, co zamieściłem link, TorchLight przedstawił problem w prosty sposób. Pojawiła się też wypowiedź o dodaniu warunku AND kasa > 0, ale on nie rozwiązuje całkowicie problemów, przykład, co gdy kasy jest dużo więcej od zera, a akcja może wykonać się powiedzmy 1 raz na dobę? Warunek, że coś nie zostało wykonane w danym dniu zostanie sprawdzony, wykonywane jest zapytanie odejmujące kasę, w tym czasie w drugim żądaniu sprawdzone jest, że akcja może być wykonana, więc też przychodzimy do odejmowania kasy. Kasa zostanie odjęta za 2 akcje, ale powinna się wykonać tylko raz. Dodam tu, bo może się każdemu przydać, że po stronie użytkownika blokuje się przycisk wysyłający, żeby można było wcisnąć go tylko raz, a po stronie serwera powinno się zrobić dodatkowe zabezpieczenia No i dochodzi do tego rzeczywista wielowątkowość przy procesorach o wielu rdzeniach (w tej kwestii nie jestem specjalistą, ale wydaje mi się, że też mogłoby się to przyczynić do takiego błędu).

Wracając do głównego tematu: chcę wiedzieć, czy ktoś już podchodził do tego problemu w taki sposób jak ja, bawił się tabelami MEMORY i sesjami w ten sposób w jakiś projektach, w których był ruch, nie tylko testował na lokalnym serwerze. Bo może to okaże się ostatecznie głupim rozwiązaniem. Jeżeli nikt nic takiego nie robił, to może będę jednym z pionierów ;D

Rodkan: jak możesz, poszerz temat, co wiesz o tych niebezpieczeństwach Sam znam 6 rodzajów ataków, właśnie za pośrednictwem sesji, ale wiem, że jest tego więcej. W kwestii bezpieczeństwa sesji właśnie nie sięgałem po żadną konkretną literaturę, w jakimś vademecum był poruszony temat, ale średnio obszernie, tyle wiem, co mi nauczyciel opowiadał i co w Internecie znalazłem ;D

http://php.pl/Wortal/Artykuly/PHP/Ar...andler-czesc-I trochę się dowiesz

Ja już to dawno temu czytałem Chodzi teraz o konkretną sprawę przechowywania tego w RAMie, nie mniej dzięki za link, przejrzę, czy coś może zostało tam zaktualizowane

W systemach UNIXowych tam jeszcze coś było z tym prościej zrobione, nie trzeba wykorzystywać bazy, ale już nie pamiętam, praktycznie cały czas siedzę na Windows, czasami mam dostęp tylko, no i Ubuntu przez Wubi, ale nie bawię się tym prawie wcale;p Wrócę do tego, gdyby nadszedł czas na serwer dedykowany - nie da się ogarniać wszystkiego

Jeżeli mam to użyć do celów produkcyjnych, że tak powiem, muszę bardzo dokładnie znać zagadnienie, a póki co mam raczej taką ogólną wizję, nawet nie wiem, czy do końca dobrą, bo jak już wcześniej chyba napisałem, taka implementacja całego systemu może być ogólnie niepoprawna

Ja staram się to zrozumieć, ale coś mi nie wychodzi.
Chcesz zmieniać całą metodę trzymania zmiennych sesyjnych, bo twórca wordpressu nie pomyślał o podstawowym sprawdzeniu danych przy rejestracji?
Moim zdaniem, podstawą poprawnego działania jakiegoś skryptu, czy programu jest brak zaufania do użytkownika. Wiadomo, że na 100 uczciwych znajdzie się 1 kombinator, który może zniszczyć wszystko jednym dodatkowym znaczkiem, ale poprzez odpowiednią funkcję można go wyeliminować lub unieszkodliwić.
Moim zdaniem, przy nazwie użytkownika wolałbym 100 razy powiedzieć użytkownikowi, że błędnie podał nick, niż raz automatycznie wybrać (skrócić do odpowiedniej długości) za niego. Bynajmniej jak nie zrozumie zasad nazewnictwa, to nie wejdzie noob do portalu.

Mówisz też o podaniu linku do np. usunięcia konta. Postać linku: adres.pl/gra.php?akcja=kasuj_konto&potwierdzone=tak. Żeby zapobiec usunięciu własnego konta wystarczy token. Taki token nie zabezpieczy chyba tylko przed matołem, który podąża ślepo według instrukcji znalezionych gdzieś w internecie (takich użytkowników nie szkoda), albo przed bezpośrednim włamaniem na konto. No może się zdarzyć, że ktoś w jakiś magiczny sposób przewidzi jaki będzie token i w cudownym sposobem przekaże do do skryptu, ale osoby z takimi zdolnościami to chyba nic nie powstrzyma. Chyba, że mówisz o trojanie, ale wtedy i tak twórca ma praktycznie nieograniczone możliwości.

Akcja z kasą: dodajesz jedno pole do bazy danych z najmniejszym typem do którego zapisujesz 1 gdy wykonano i cronem resetujesz na 0. Chyba, że ta twoja metoda przetrzymuje zmienne nawet po zniszczeniu sesji i odzyskuje przy nowym utworzeniu, ale wtedy to się chyba kłóci z ideą sesji.

Nie wiem, czy nie chodzi Ci o kradzież identyfikatora sesji, ale przy twojej metodzie też musisz mieć jakiś identyfikator, który można skraść i otrzymać ten sam wynik.

Podsumowując, wszystkie opisane przez Ciebie błędy są co najwyżej z winy programisty, a przy tokenach szukasz dziury w całym. Przy tych argumentach tak naprawdę chcesz sobie utrudnić życie, chyba, że robisz to edukacyjnie, wtedy popieram coś takiego. Warto znać więcej niż 1 metodę na wszystko.

Napisałeś, że znasz co najmniej 9 innych sposobów na atak przez sesję. Czy możesz podać chociaż 2 których każdy powinien się wystrzegać? Może idzie im zapobiec poprzez zwykłą, prostą funkcję tak jak w przypadku błędu wordpress?

Może dzięki temu nabiorę nowych doświadczeń, albo przekonam się do tego sposobu, co ty proponujesz.


@EDYCJA
Tak sobie pomyślałem, że ten Twój pomysł nie ważne jak by nie był genialny i bezpieczny, i tak nie ma prawa bytu. Taką metodę mógłbyś zastosować tylko na serwerach dedykowanych i to chyba z pełną opcją administracyjną. Zauważ, że każdy host na współdzielonym serwerze (nawet płatny) jest ograniczony. W większości tych ograniczeń na najlepszych serwerach się nie zauważa, bo sięgają daleko ponad zdolności przeciętnego programisty, lub nie mamy potrzeby ich używać.

Kasowanie konta:

Dlatego robi się czas ~7 dni czy coś, ewentualnie potwierdzenia na email, do tego za pomocą _POST a nie _GET.

Imperator_Edi - ja to wszystko wiem, wspomniałem tu nawet o tokenach Nie rozumiesz o co mi chodzi. Zamiast przechowywać dane sesji w plikach trzymam je w pamięci RAM. Utrata tych danych oczywiście powoduje koniec sesji i konieczność ponownego logowania. Ponieważ to jest w pamięci RAM można zrobić ciekawy system tokenów.
I pamiętaj, zwykłe żądanie POST nie zawsze może wystarczyć, to też nie gwarantuje 100% bezpieczeństwa.
I tamto podałem w celu wyjaśnienia istoty ataku CSRF, jeden z najprostszych moich zdaniem przykładów, dobrze wiem, co robić należy
I nie myślałem o żadnym Wordpressie nic, to był mój pomysł który wynikł z faktu iż do tego, co chciałem wtedy zrobić standardowe rozwiązania dają zbyt słabe rezultaty pod względem wydajności (miałem taki jeden ekstremalny pomysł, może kiedyś doczeka się realizacji).

I mylisz się, że nie ma prawa bytu, bo przekonsultowałem mój pomysł ze znajomym a ten z kolei obgadał to w jednym z kół naukowych Politechniki Wrocławskiej no i wiem, że można takie coś stosować, a nawet jest to używane (w dużo innej formie, wręcz całkowicie innej, w większych projektach, ale jest) Lubię eksperymentować, zawsze dodatkowa wiedza, ale można to też użyć w praktyce, wiem, jakie wyzwania w związku z tym mnie czekają. Są dodatkowe zagrożenia, które należy zwalczać, ale też pozwala to rozwiązać pewne problemy ze standardowego mechanizmu sesji.

I nie tylko na serwerach dedykowanych, ale na VPS również, a dodatkowo na współdzielonym też No i jeżeli będę startował projekt gry, nad czym pracuję, to obowiązkowo będę musiał posiadać minimum VPS ze względu na to, że część funkcji będę miał napisanych w C++ jako rozszerzenia PHP zgodne z Zend Engine, którego uroki ciągle odkrywam.

No i te przykłady innych ataków: Session injection do którego można doprowadzić na źle skonfigurowanych serwerach hostingu współdzielonego, a jest to dosyć częste zjawisko, bo nawet dzieci są administratorami.. Właśnie np. ten pomysł jest zabezpieczeniem przed tego typem ataków. No i jak tak myślę atak powiedzmy session modification też może być utrudniony, bo można zbudować pewną zabawkę, która jak tak teraz myślę powinna ukrócić i tę drogę lamerowi.

Może dzięki temu nabiorę nowych doświadczeń, albo przekonam się do tego sposobu, co ty proponujesz.

Pomysł mój, przy dobrze napisanym kodzie powinien być co najmniej równie bezpieczny, jak normalny mechanizm. Owszem pojawia się wiele nowych zagrożeń, wynikających chociażby z faktu wykorzystania bazy danych (pierwotne założenie: tabela MEMORY), ale z drugiej strony można doprowadzić do sporego w moim mniemaniu wzrostu wydajności aplikacji (no nie ma nic za darmo niestety ).


Drikam - bo ktoś Twojemu użytkownikowi wyśle taki link, zamieści na forum gry, parę osób kliknie i konta będą skasowane Potwierdzenie emailem - podstawowe zabezpieczenie przeciwko botom.

Mały update: konsultowałem to z różnymi ludźmi, robiłem testy wydajnościowe, natrafiłem na kwestię sesji w ciekawej książce o zaawansowanym programowaniu obiektowym (+ wykorzystaniu różnych technik manipulacyjnych podczas negocjacji z klientami ;D ) i wszędzie wyszło, że chociażby proponowane przeze mnie rozwiązanie będzie bardziej wydajne niż standardowy mechanizm, może być nawet bezpieczniejsze od sesji standardowych, a jest co najmniej tak samo (chociaż nawet jest tak, nie o tym mi teraz pisać), jeżeli się logicznie myśli. No i jest też wykorzystywane w większych projektach, gdzie standardowy mechanizm obsługi sesji NIE MOŻE (bo nie działa ) być stosowany.
Porobię jeszcze duże testy i opublikuję wyniki, bo na średnich już była zauważalna przewaga mojego mechanizmu, ale jeszcze nie aż taka duża. Z tego co się dowiedziałem, standardowe sesje mogą należeć do tych bardziej obciążających aplikację punktów.