Konflikt sesji PHP z AJAX

Jeśli dobrze rozumiem, wygląda na to, że ustawiasz token dla każdego żądania. Domyślam się, że stara strona nadal ma stary token. Chciałbym sprawdzić, czy token jest ustawiony, zanim automatycznie go wyrzucę.

 if (isset($_SESSION['token'])){
    //do nothing
 } else{
   $_SESSION['token'] = md5(rand());
 }

Edytuj Aby odpowiedzieć na Twoje pytanie.

Zamiast używać tylko jednego klucza „token”, utwórz klucz dla każdej sesji przeglądarki.

$_SESSION[$sessionId] = md5(rand());

Sztuczka oczywiście polega na ustaleniu, kiedy to się stanie, ponieważ jeśli nie możesz użyć sesji, tak naprawdę nie będziesz wiedział, czy żądanie pochodzi z nowej, czy ze starej karty. Możesz użyć ciągu zapytania do przekazania tego parametru. Zasadniczo wszystkie żądania musiałyby mieć ten parametr, w przeciwnym razie nie powiążesz z nimi sesji.

np.

http://www.yoursite.com/somepage.php?sessionid=<some generated id>

Ostatecznie użytkownik mógłby się z tym bawić, ale nie jestem pewien, czy można to obejść.

Edytuj 2 Ok, oto moja myśl, jak to zrobić. Eksperci od bezpieczeństwa, nie krępuj się, jeśli się pomylę, jak powiedziałem wcześniej, nie jestem ekspertem, ale nie wygląda na to, że wyjdę z tego bez sugerowania czegoś;-)

Problem z CSFR polega na tym, że jakiś złośliwy użytkownik, Bob, może utworzyć element w innej witrynie, który powoduje, że przeglądarka Alicji wysyła żądanie do innej witryny, a ponieważ Alicja była wcześniej zalogowana, a informacje te są przechowywane jako plik cookie lub Alicja jest rozpoznawany przez sesję, witryna wykonuje żądanie tak, jakby zażądała tego Alicja. Na przykład, jeśli bank Alicji to http://www.mybank.com , wówczas Bob może utworzyć post na forum zawierający

<img srg="http://www.mybank.com/transferfunds.php?amount=1000&receiver=Bob" />

Bank Alicji rozpoznałby, że jej przeglądarka wysyła żądanie, myśląc, że to ona. Jest kilka kluczowych rzeczy, które muszą się wydarzyć (razem każda z tych niepowodzeń spowoduje niepowodzenie ataku), aby ten atak był wykonalny (są to kluczowe elementy, które pozwalają zrozumieć, jak temu zapobiec):

1. Alice musiała zalogować się na stronie swojego banku, aby bank ją zapamiętał. Może się to zdarzyć w pliku cookie („zapamiętaj mnie”) lub podczas sesji. Jeśli jednak zamknie przeglądarkę (zakończy sesję) lub wyczyści swoje pliki cookie, nie ma zagrożenia, ponieważ strona banku jej nie rozpozna i odrzuci żądanie.
2. Bob musi być w stanie dostarczyć wszystkie niezbędne parametry do żądania, w przeciwnym razie strona banku odrzuci żądanie.

Aby zapewnić pewne pojęcie „stanu” na szczycie protokołu bezstanowego (HTTP), naprawdę nie można obejść ryzyka w (1). O ile nie sprawisz, że ludzie zawsze klikną „wyloguj się” lub zamkną okno itp., nic nie możesz zrobić, aby obejść przechowywanie informacji w przeglądarce lub sesji. Możesz jednak zapobiec sytuacji, w której (2) będzie problemem. Moim rozwiązaniem tego problemu (a jestem pewien, że jest ich mnóstwo) jest wygenerowanie skrótu, tak jak robisz, i zapisanie go w sesji.

Na przykład

$_SESSION['token'] = md5(rand());

Następnie dołączasz ten token do wszystkich wewnętrznych linków.

http://www.mysite.com/secure.php?token=giuwnrefviunslfghahgliuwnvwrgbaasd a>

//note, you'll want to sanitize user input, I'm just being brief
if ($_GET['token'] != $_SESSION['token']){
   //User either attempted to enter a link on their own or it's a CSRF attack
   header('HTTP/1.1 403 Forbidden');
 }else{
 //do whatever needs to be done
 }