jak w temacie.

Poprzez ataki XSS i pochodne, wlamujac sie do cudzego komputera lub inne

można coś na to poradzić w powiązaniu z sesjami oprócz sprawdzania przeglądarki ? Zawsze przecież ktoś może ukraść ciastko i odpalić je na takiej samej przeglądarce.

- nie trzymac w ciastkach nic, czeo ujawnienie mogłoby być szkodliwe
- walidowac dane od użytkownika
- odświeżać identyfikator sesji co 15 minut
- wyłączyć trans_sid w php
- sprawdzić szczelność systemu plików na hostingach współdzielonych (obowiązkowo własny katalog przechowywania zmiennych sesji + sprawdzić, czy nie da się przez php wyjść poza własny zakres katalogów)
- wyłączyć register_globals lub zastosowac funkcję wyrejestrowywania zmeinnych globalnych

o czyms zapomniałem ? acha -> WALIDOWAĆ DANE OD UŻYTKOWNIKA



p.s.
warto tez walidowac dane od użytkownika

To gdzie mam trzymać id sessji ? (pisze właśnie własną sesję)

Mozesz trzymac w sesji ale nie rob uwierzytelnienia userow tylko na podstawie tego id

Albo ja albo Ty nie do końca rozumiesz problem Id sesji jest przecież trzymany w ciastach.

uwieżytelnianie miałem nadzieję obić na podstawie przeglądarki i id sesji. Ale jest problem bo ktoś moze użyć tej samej przeglądarki? Jak jeszcze można rozpoznać usera? Nie chcę stosować IP bo pół polski to neostrada.

Nie tworz po prostu tego serwisu, wtedy nikt nikomu nie ukradnie sesji.
Ew. uzywaj tylko SSL.

Nie chcę pancernych drzwi tylko takie nie otwarte.

Jeżeli boisz się, że ktos może w 15 minut zwinąć ciastko (sessionid w URL) i wykonac atak ... nie używaj sesji , w przeciwnym wypadku:
- odświeżaj ID, tak żeby ID sprzed godziny (komputer pozostawiony w biurze) nie było juz ważne
- dodaj konieczność ponownego wpisania hasła i tokena z obrazka (captcha) przy wykonywaniu waznych czynności administracyjnych
- rozważ opcję drugiego hasła do czynności administracyjnych

Jeżeli masz obsesję, włącz do działania drugi serwer - kontroler (inna domenę), która ustawi drugie ciastko i sprawdzaj oba wymaga to jednak odrobiny kombinacji i dobrej komunikacji między serwerami. To tak jakbyś RELANY stan zalogowania rozpoznawał na podstawie poprawnego zalogowania na domenie głównej i ukrytego (fikcyjnego) zalogowania na kontrolerze. Brak walidacji z kontrolera ma powodować natychmiastowe wylogowanie. Swoje poczucie bezpieczeństwa opierasz w tym momencie na założeniu że atakujący nie wie o istnieniu kontrolera kradnąc ciastko oraz że nie jest w stanie przypuścic ataku XSS na serwer który żadnych danych od usera nie przyjmuje.*

* właśnie to wymyśliłem, nie krępujcie się krytykowac

No dobra. Już nie przesadzam z tym bezpieczeństwem bo nie robię stron dla banków. (Ty chyba pracujesz w jakimś banku prawda ?) Zastanawiam się jeszcze nad tym czy jeśli wykonuję jakąś stronę dla administracji państwowej (np. stronę powiatu) to czy musze spełnić jakieś normy bezpieczeństwa. Czy to jest ustalone gdzies przez prawo?

Nie pracuję w banku

1. Walidacja danych to konieczność, cokolwiek byś nie zrobił brak walidacji wysypie całość. Dobra walidacja = brak ryzyka XSS -> ciastko można ukraśc tylko ręcznie
2. Częsty refresh sesji to szybka dezaktualizacja porzuconego ciastka, dodatkowo względnie krótka żywotnośc sesji to mało czasu na kombinacje dla kradzieja

No ale jednak przy każdej akcji sesja musi się wydłużyć o następne 15 minut.

najlepiej filtrowac dane pochodzace od uzytkownika juz na samym poczatku pliku ^^

tak się zastanawiam po co ci było ciastko na czas działania przeglądarki skoro mogłeś ustawić cookie na time()+800, czyli 15 minut

słuszna uwaga

http://www.beldzio.com/bezpieczenstwo-mechanizmu-sesji.freez sekcja Session fixation