Bezpieczeństwo skryptów PHP opratych na sesji Opcje

[Michael2318]

Zastanawiam się nad bezpieczeństwem skryptów opartych o php-owskie sesje oraz bazę MySQL. Załóżmy, że przy logowaniu, wyszukuję w bazie czy istnieje user o podanym haśle i nicku. Jeśli istnieje to tworzę sesję. No i właśnie... Do sesji nie powinno się przypisywać żadnych haseł/nicków, ale czy można przypisać ID danego usera? Co jeśli przypiszę sesję tak:

[PHP] pobierz, plaintext 
$_SESSION['login'] = $user_id;
[PHP] pobierz, plaintext 

gdzie $user_id to np. 1, czyli admin? Czy to jest 100% bezpieczne rozwiązanie? No bo jeśli w jakiś sposób dałoby się zmienić zawartość sesji i ktoś przypisze sobie do swojej sesji 1 to automatycznie jest na koncie admina i robi co chce. Pytanie czy tak się da?

No i druga sprawa - dostęp do Panelu Admina (PA). Czy wystarczy, jeśli do PA będę wpuszczał osoby, które w bazie mają przypisane user_level (pole tinyint(1) default 0) == 1 ? Teoretycznie nikt sobie nie zmieni sam tej wartości bo musiałby mieć dostęp do bazy, a jesli już miałby dostęp do bazy to może wszystko, wiec czy taka alternatywa wytarczy, czy raczej trzeba dorzucić jakieś oddzielne logowania, cuda wianki?

[netmare]

To w jednym się zgadzamy. Ale to z refererem... słów mi brakło, jaka w tym wypadku jest różnica między bezpieczeństwem cookie vs url?? albo masz dostęp do maszyny albo snifujesz nic więcej nie zrobisz. Warto czytać ze zrozumieniem zamiast się gadać, że się ryzyko nie opłaciło bo to stwierdzenie Tobie się nie opłaciło. Dajesz tutaj scenariusz ataku na url, który przy tych samych założeniach nie powiedzie się na cookie, nie ma wstawianej treści na stronę i nie ma linków na zewnątrz.

Edit: Co gorsza wydaje mi się że url będzie bardziej odporne na CSRF (IMG:style_emoticons/default/wink.gif)

Ten post edytował netmare 4.02.2013, 08:36:06

[pyro]

To w jednym się zgadzamy. Ale to z refererem... słów mi brakło, jaka w tym wypadku jest różnica między bezpieczeństwem cookie vs url?? albo masz dostęp do maszyny albo snifujesz nic więcej nie zrobisz. Warto czytać ze zrozumieniem zamiast się gadać, że się ryzyko nie opłaciło bo to stwierdzenie Tobie się nie opłaciło. Dajesz tutaj scenariusz ataku na url, który przy tych samych założeniach nie powiedzie się na cookie, nie ma wstawianej treści na stronę i nie ma linków na zewnątrz.

Edit: Co gorsza wydaje mi się że url będzie bardziej odporne na CSRF (IMG:style_emoticons/default/wink.gif)

To samo mi mówili ludzie, dla których aplikacji wykonywałem pełen audyt bezpieczeństwa na umowę. Zarzucono mi, że na siłę pakuję nieznaczące błędy do raportu, bo niby chcę więcej zarobić w ten sposób. Jak za jakiś czas wysłałem screenshot, w którym jestem zalogowany jako administrator z nowym nickiem, osoby te nigdy więcej nie zarzuciły mi próby naciągactwa. Mało tego nazwano mnie geniuszem, a nie trzeba być wcale geniuszem ("Ale jakto? Przecież był sprawdzany referer i user-agent!"), tylko znajomość działania danych technologii.

To w jednym się zgadzamy. Ale to z refererem... słów mi brakło, jaka w tym wypadku jest różnica między bezpieczeństwem cookie vs url??
...
Warto czytać ze zrozumieniem zamiast się gadać

No widzisz - zarzucasz mi nieczytanie ze zrozumieniem, a sam nie czytasz tego co piszę, a dodatkowo wciskasz mi jeszcze coś na usta, czego nigdy nie powiedziałem. Nigdy nie twierdziłem, że przy sprawdzaniu referera jest większe bezpieczeństwo przy sesjach stricte cookie. Według mnie w obu przypadkach sprawdzanie referera to słabe zabezpieczenie (tak naprawdę to tylko niewielkie utrudnienie), a nie tylko w jednym z nich.