PHP-session er i konflikt med AJAX

Hvis jeg forstår dette rigtigt, lyder det som om du angiver tokenet for hver anmodning. Mit gæt vil være, at den gamle side stadig har det gamle token. Jeg ville tjekke om tokenet er indstillet, før jeg automatisk blæser det væk.

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

Rediger For at besvare dit spørgsmål.

I stedet for blot at bruge én nøgle af "token", skal du oprette en nøgle for hver browsersession.

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

Tricket vil selvfølgelig være at finde ud af, hvornår de sker, for hvis du ikke kan bruge session, vil du virkelig ikke vide, om anmodningen kommer fra en ny fane eller en gammel. Du kan bruge forespørgselsstrengen til at videregive denne parameter. Grundlæggende ville alle anmodninger skulle have denne parameter, ellers forbinder du ikke en session med dem.

f.eks.

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

I sidste ende kunne brugeren abe med dette, men jeg er ikke sikker på, at der er nogen vej udenom.

Rediger 2 Ok, her er min tanke for, hvordan du skal gøre dette. Sikkerhedseksperter derude, du er velkommen til at flame mig, hvis jeg har det forkert, som jeg sagde før, jeg er ingen ekspert, men det ser ikke ud til, at jeg kommer ud af det her uden at foreslå noget;-)

Problemet med CSFR er, at en ondsindet bruger, Bob, kunne oprette et element på et andet websted, der får Alices browser til at sende en anmodning til et andet websted, og fordi Alice tidligere var logget ind, og disse oplysninger gemmes enten som en cookie eller Alice. genkendes via session, udfører webstedet anmodningen, som om Alice havde anmodet om det. For eksempel, hvis Alices bank er http://www.mybank.com , så kunne Bob oprette et forumindlæg, der indeholder

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

Alices bank ville genkende, at hendes browser fremsatte anmodningen, og troede, det var hende. Der er et par vigtige ting, der skal ske (sammen vil en af ​​disse fejl få angrebet til at mislykkes) for at gøre dette til et levedygtigt angreb (disse er nøglen til at forstå, hvordan man forhindrer det):

1. Alice skal have logget ind på sin bankside, så banken husker hende. Dette kan ske enten i en cookie ("husk mig") eller via session. Men hvis hun lukker sin browser (afslutter sessionen) eller rydder sine cookies, er der ingen trussel, fordi bankens websted ikke genkender hende og vil afvise anmodningen.
2. Bob skal være i stand til at levere alle de nødvendige parametre til anmodningen, ellers vil bankens websted afvise anmodningen.

For at give en forestilling om "tilstand" oven på en statsløs protokol (HTTP), kan du virkelig ikke komme uden om risikoen i (1). Medmindre du får folk til altid at klikke på "log ud" eller lukke deres vindue osv., er der intet, du kan gøre uden om at gemme information i browseren eller sessionen. Du kan dog forhindre (2) i at blive et problem. Min løsning på dette (og jeg er sikker på, at der er tonsvis af andre) er at generere en hash, som du gør, og gemme den i session.

For eksempel,

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

Derefter, hvad du gør, er at tilføje det token til alle dine interne links.

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

Du ALDRIG gem dette token i browserens hukommelse:dvs. en cookie. Når der fremsættes anmodninger, kontrollerer du tokenet, før du gør noget.

//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
 }

Nøglen til dette er, at alle links på dit websted vil inkludere tokenet. Bob har dog ingen mulighed for at vide, hvad det token er, fordi det ikke er gemt i en cookie i browseren. Hvis han forsøger at lave et link til en af ​​dine sider, vil det enten indeholde den forkerte nøgle, eller også vil det ikke indeholde nogen nøgle, og du kan afvise det. (For at være retfærdig er der en chance for, at han korrekt kan gætte tokenet for en specifik bruger, der tilfældigvis ser hans kode, men han er sandsynligvis mere tilbøjelig til at bryde i flammer.)

Det er heller ikke nødvendigt at tildele en timeout til tokenet, da tokenet vil blive udslettet, når browseren lukkes, og skal genskabes, når brugeren besøger siden.