Sessie-ID

Van Wikipedia, de gratis encyclopedie
Spring naar navigatie Spring naar zoeken

Een sessie-ID (ook sessie-ID , sessienummer of sessie-ID , Engelse sessie-ID , korte Engelse sessie-ID ) wordt gebruikt als identificatiefunctie in toepassingen op stateless protocollen om verschillende gerelateerde verzoeken van een gebruiker te herkennen en toe te wijzen aan een sessie . Met name in webapplicaties worden sessie-ID's veel gebruikt.

Op het World Wide Web worden allerlei diensten aangeboden met behulp van het Hypertext Transfer Protocol (HTTP). Deze diensten bestaan ​​vaak uit meerdere gerelateerde verzoeken en antwoorden. Om bijvoorbeeld iets in een webshop te kopen, bladert de gebruiker eerst door de catalogus, kan enkele artikelen in de winkelwagen reserveren en vervolgens de bestelling plaatsen.

Dergelijke gecompliceerde processen worden niet direct ondersteund door HTTP, omdat het een stateloos protocol is. Een HTTP-verzoek retourneert slechts één website en onthoudt niet welke gebruiker erbij hoort. Om meerdere van dergelijke verzoeken te combineren en aan de gebruiker toe te wijzen, wordt bij elk verzoek een sessie-ID meegestuurd. De webapplicatie kan dit onthouden en de individuele verzoeken toewijzen aan een gezamenlijke sessie.

In de regel wordt de sessie automatisch beëindigd ( timeout ) of door uitloggen na een bepaalde tijd en wordt de sessie-ID verwijderd. Het is daarom niet mogelijk om de huidige status van een sessie op te slaan - bijvoorbeeld door een bladwijzer aan te maken - en deze later weer op te roepen. Deze beperking kan ook bedoeld zijn door de exploitant van de dienst om directe koppelingen naar afzonderlijke pagina's van zijn aanbod (" deeplinks ") te voorkomen.

functie

De Sessie-ID wordt aan het begin van een sessie (Engelse sessie) door de server gegenereerd . Het moet met het antwoord van de server naar de client worden verzonden en moet door de client worden verstrekt bij elke verdere toegang tot de server. Met behulp van de unieke sessie-ID kunnen de gegevens die op de server zijn opgeslagen (bijvoorbeeld: winkelwagen) bij elke toegang uniek worden gekoppeld aan een gebruiker.

De sessie-ID moet daarom bij elk antwoord van de server opnieuw naar de client worden verzonden. Een verzoek dat geen sessie-ID bevat, wordt gezien als het eerste verzoek van een nieuwe sessie, dus de gebruiker verliest zijn vorige sessie.

realisatie

Technisch gezien kan de sessie-ID worden verzonden in de context van HTTP met behulp van zogenaamde cookies , die ze in de URI's of onzichtbare formuliervelden invoegen.

Omdat de server de functie van een cookie niet kan overnemen, ondersteunen veel applicaties beide soorten overdracht: bij de eerste reactie wordt de sessie-ID zowel als cookie als in de URI's verzonden. Als het volgende verzoek de sessie-ID als cookie bevat, worden de URI's voor de rest van de sessie niet meer gewijzigd.

Overdracht in de HTTP-header (cookie)

Cookies zijn een uitbreiding van HTTP die is ontwikkeld om dergelijke problemen op te lossen. Met zijn antwoord (HTTP-antwoord) kan de server een klein gegevenspakket naar de browser sturen, dat de browser samen met elk volgend verzoek (HTTP-verzoek) naar dezelfde server stuurt.

De overdracht van de sessie-ID met cookies vereist alleen de eenmalige overdracht van de sessie-ID van de server naar de client; alle volgende verzoeken bevatten de sessie-ID. Een voordeel is dat de sessie-ID behouden blijft, zelfs bij statische websites of afbeeldingen.

Het probleem met deze aanpak is dat cookies kunnen blijven bestaan, zelfs nadat de browser opnieuw is opgestart en door sommige bedrijven worden gebruikt om gegevens over de gebruiker te verzamelen. Om deze reden hebben sommige gebruikers de acceptatie van cookies in hun browser gedeactiveerd. In ruil daarvoor geven sommige webapplicaties expliciet aan dat het accepteren van cookies in de browser moet worden geactiveerd - b.v. B. om in te schrijven.

Transmissie in de URI

Aangezien vervolgvragen van een gebruiker meestal worden gedaan door op een link te klikken of een formulier in te dienen, kan de sessie-ID ook worden verzonden door elke URI binnen een website te wijzigen zodat deze de sessie-ID bevat.

Er zijn twee manieren om dit te doen:

Sessie-ID in een URI

Vraag
http://www.example.com/index?sid=edb0e8665db4e9042fe0176a89aade16
pad
http://www.example.com/edb0e8665db4e9042fe0176a89aade16/index

Het verzenden van de sessie-ID in de URI vereist meer programmeerinspanning en er zijn verschillende situaties die kunnen leiden tot het verlies van de sessie. De sessie-ID wordt ook vastgelegd in het logbestand van de server.

Transmissie in het datagedeelte van een HTTP-verzoek (HTML-formulieren)

Een sessie-ID kan ook - vergelijkbaar met de verzending in het querygedeelte van een URI - naar de server worden verzonden in het gegevensgedeelte van een HTTP-verzoek. Om dit te doen, wordt de sessie-ID overgedragen wanneer een HTML-formulier wordt verzonden met de POST- methode. In de regel wordt de sessie-ID opgeslagen in een verborgen formulierveld ( input van het type " hidden "). Omdat ook de HTML-broncode moet worden aangepast, kan deze methode naast of als alternatief voor de verzending in de URI worden gebruikt.

Opslag van sessie-informatie op de server

De gegevens van een sessie, inclusief zowel de sessie-ID als de gebruikersgegevens (gebruikers-ID, inhoud winkelwagentje, enz.), worden standaard door de webserver opgeslagen in een specifieke map op de harde schijf; dit is vaak de tijdelijke map van het besturingssysteem ( /tmp ) . Zo'n bestand ziet er als volgt uit:

 / tmp / sess_hvb0es1qdv5o91ogspmfk9ck77
Gebruikers-ID | i: 212; inhoud winkelwagentje | a: 2: {i: 0; s: 8: "Artikel1"; i: 1; s: 8: "Artikel2";}

Sessiegegevens kunnen ook op andere (centrale) locaties worden opgeslagen, bijvoorbeeld op netwerkschijven, in een memcached of in een database. De meeste webprogrammeertalen ondersteunen dit.

veiligheid

Welk type verzending ook wordt gekozen voor de sessie-ID, uiteindelijk vertrouwt de server erop dat de client dezelfde ID terugstuurt die naar hem is verzonden. Aangezien een gebruiker echter de client-kant beheert, kan hij elke sessie-ID terugsturen. Als deze sessie-ID overeenkomt met die van een andere gebruiker, is het mogelijk om de gegevens van andere gebruikers te bespioneren en te manipuleren.

Het is dus van het grootste belang dat sessie-ID's niet kunnen worden geraden. Dit wordt meestal bereikt door de sessie-ID willekeurig te selecteren uit een reeks waarden die zo groot is dat deze niet kan worden doorzocht en de kans dat u per ongeluk een sessie-ID tegenkomt die momenteel in gebruik is, extreem laag is.

Mogelijke aanvallen op een bestaande sessie worden beschreven onder Sessiekaping . De benadering om als aanvaller een geldige sessie te creëren en deze door te geven aan een andere gebruiker, wordt sessiefixatie genoemd .

web links