[PHP] bezpieczenstwo komunikacji z baza Opcje

[szymonstawi]

witam wszystkich!
mam strone gdzie mozna dodawac artykuly (index.php) i strone moderacji (edycja, usuwanie - admin.php). do komunikacji z baza mam plik baza.php i tam sa funkcje add, edit, delete. wejscie do admina jest oczywiscie zabezpieczone prawami dostepu zrobionymi na sesjach i teraz mam pytanie. czy takie zabezpieczenie wystarczy? plik baza.php tez powinienem zabezpieczyc sesja? tylko czy sesja wystarczy?

[desperat666]

mowisz ze baza.php zawiera funkcje, wiec co da wykonanie pliku baza.php? nic.

[szymonstawi]

ok, dzieki, a samo zabezpieczenie na podstawie sesji wystarczy w pliku admin.php? tam sa linki do usuwania, wiec poza tym adminem i tym kto potrafi ukrasc sesje trzeba sie jeszcze jakos zabezpieczyc?

[wNogachSpisz]

Sesje bazujące na mechanizmach php mająj uroczą skłonność do trzymania plików z numerami sesji w katalogu tymczasowym dostępnym do odczytu/zapisu dla każdego użytkownika hostingu współdzielonego.

Bezpieczne to to nie jest...

[szymonstawi]

wiec jak najlepiej zrobic sesje?

a poza tym to ify w plikach gdzie sa linki do usuwania itp wystarcza?

moze ktos cos o tych sesjach napisac? skoro nie uzywac domyslnych to jakie mam uzywac?

[Fifi209]

session handler

[szymonstawi]

dzieki, ale strasznie malo materialow o tym. poza tymi z php.pl to nic konkretnego nie znalazlem, nawet za granica. czemu, skoro te zwykle sesje zle dzialaja?

[wNogachSpisz]

Sesje działają źle (czyt. niebezpiecznie), ponieważ niedbała konfiguracja współdzielonych serwerów hostingoweych powoduje, że każdy kto posiada konto na takim serwerze może przejąć Twoją sesję.

Polecam implementację mechanizmu sesji bez korzystania z funkcji session_*
Ta w CodeIgniterze jest całkiem spoko, domyślnie szyfruje dane sesji i trzyma w COOKIE, działa to dobrze póki nie wrzucisz do sesji zbyt wiele danych, czego skutkiem będzie utrata sesji.
Na szczęście jest wersja pracująca z bazą danych, poszukaj na CI-wiki.

Ten post edytował wNogachSpisz 6.04.2011, 23:33:22

[Fifi209]

Polecam implementację mechanizmu sesji bez korzystania z funkcji session_*

Przecież można ustawić swojego handlera session_set_save_handler

[wNogachSpisz]

Fajne, tylko jak tego użyć gdy pracujesz wyłącznie wewnątrz obiektów w modelu MVC i nie chcesz "śmiecić" pluginami, hookami i innymi helperami?

Jest tego obiektowy wariant, jak np. stream_wrapper_register() ?

Ten post edytował wNogachSpisz 6.04.2011, 23:38:17

[szymonstawi]

http://php.pl/Wortal/Artykuly/PHP/Architek...I/Implementacje

a tutaj jest uzywane session_ jakby ktos mial jakis prosty i dobry przyklad to poprosze:)

[bugmenot]

A nie można tego zrobić przez .htaccess i .htpasswd?

[szymonstawi]

czyli jak?

[nekomata]

Przecież można ustawić swojego handlera session_set_save_handler

Fajne, tylko jak tego użyć gdy pracujesz wyłącznie wewnątrz obiektów w modelu MVC i nie chcesz "śmiecić" pluginami, hookami i innymi helperami?
Jest tego obiektowy wariant, jak np. stream_wrapper_register() ?

Tak się zastanawiam , własny handler (cool!) dla sessji byłby fajną sprawą , ale nie wystarczy np.

[PHP] pobierz, plaintext 
session_save_path(__DIR__.'\sessions');
session_start();
[PHP] pobierz, plaintext 

Sesje są zapisywane wtedy w katalogu sessions , wywołanego pliku (ja wszystkie swoje sesje załączam zapomocą jednego include więc to nieproblem) , no i mam na myśli to że jak już nam ktoś po plikach(z naszego katalogu public_) może szperać to czy mamy sesje normalnie czy np. za pomocą własnego handlera w mysqli albo jeszcze inaczej i tak jest to nieważne bo wszystkie pliki są dostępne.Więc czy naprawdę warto bawić się we własnego handlera?

[wNogachSpisz]

Sesje są zapisywane wtedy w katalogu sessions

Jest to niewątpliwie rozwiązanie problemu bezpieczeństwa..
Problem w tym, że dla mnie jest to struganiem protezy.
Najlepiej pozbyć się problemu sesji obsługiwanych przez PHP przez własną implementację
Nie znam ani jednego racjonalnego argumentu przeciwko, jeśli ktoś jest w stanie taki wysunąć, to chętnie przeczytam.
Własna implementacja sesji daje odporność na sytuacje nieprzewidzane,
jak np. blokada funkcji session_save_path() czy session_set_save_handler()...

Ten post edytował wNogachSpisz 7.04.2011, 19:43:10

[nekomata]

Ja mam namyśli , że właśnie z folderem sessions , jeśli ktoś nam przegląda to (nawet innym plikiem php na swoim koncie itd.) może utworzyć sobie duplikat plików serwisu , przejrzeć jak działa twój własny handler , i uzyskać dostęp .Jeśli session_save_path() niedziałający to ja bym po prostu brał zwrot pieniędzy i zmieniał serwer.

[wNogachSpisz]

Ja mam namyśli , że właśnie z folderem sessions , jeśli ktoś nam przegląda to (nawet innym plikiem php na swoim koncie itd.) może utworzyć sobie duplikat plików serwisu , przejrzeć jak działa twój własny handler , i uzyskać dostęp .Jeśli session_save_path() niedziałający to ja bym po prostu brał zwrot pieniędzy i zmieniał serwer.

Kopczyk problemów których można uniknąć stosująć własną implementację sesji.
Kolejny argument 'Za'.

Ten post edytował wNogachSpisz 7.04.2011, 19:59:54

[nekomata]

Tylko ... jeśli jakaś funkcja która jest zaimplementowana może nie działać równie dobrze możemy spekulować co zrobić gdy nie-zadziała echo (tak wiem echo nie jest funkcją , przykład).

[Fifi209]

wNogachSpisz skoro tak bardzo polecasz pisanie własnego systemu sesji, swojej implementacji, dajesz tak dużo argumentów "za" to z pewnością chciałbyś się podzielić swoimi doświadczeniami, bo zapewne pisałeś nie jeden mechanizm sesji lub masz już swój jeden idealnie dopracowany. Z przyjemnością oglądniemy Twoją implementację systemu sesji, w końcu tak sobie zachwalasz.

Jeżeli masz tyle argumentów "za" to poprzyj swoimi kodami! Ba! Więcej, daj do ocen i zobaczymy jakie komentarze i oceny dostaniesz.

[potreb]

Jestem za, a zresztą po co własny mechanizm sesji bo nigdy nie stosowałem. Czy naprawdę defaultowe sesje są tak kiepskie, że trzeba pisać własny session handler?

Ten post edytował potreb 7.04.2011, 21:41:08