Technisch gezien, zelfs als de inhoud van de cookie zou worden versleuteld, als cookies correct naar de nieuwe browser worden gekopieerd en de nieuwe browser dezelfde HTTP-headers verzendt (dezelfde user-agent-string, verwijzende URL is zoals verwacht, computer heeft hetzelfde IP-adres adres, en alle andere headers die de server eerder had kunnen opslaan en vergelijken), zou de server in theorie niet in staat zijn om onderscheid te maken tussen de oorspronkelijke browser en de nieuwe browser .

Ik neem aan dat u de cookie (s) probeert te kopiëren van een site die u automatisch aanmeldt telkens wanneer u uw browser opent en u niet bent uitgelogd.

Sommige sites kunnen andere manieren gebruiken om te detecteren of dit een gestolen cookie / sessie is, maar het is een verloren strijd omdat ze allemaal nog steeds kunnen worden vervalst. Bijvoorbeeld:

• Controleer of het IP-adres is gewijzigd
• Is de User-Agent hetzelfde
• Controleer of de verwijzer zinvol is
• Eventuele andere HTTP-headers die de browser stuurt

Om je vraag te beantwoorden, zou je het moeten kunnen laten werken als je te maken hebt met een auto-login site en je bent niet uitgelogd. Zorg ervoor dat alle HTTP-headers die uw nieuwe browser verzendt dezelfde zijn, dat het IP-adres hetzelfde is en dat de verwijzende URL de verwachte, dezelfde user-agent is.

Merk op dat de service die u gebruikt misschien ook een 2e cookie gebruikt die u bent vergeten te kopiëren, en dus een anomalie creëert en u eruit schopt.

De inhoud van een cookie is toepassingsgedefinieerd en er zijn allerlei manieren om ze te gebruiken. Hier is een korte lijst met enkele van de mogelijke redenen waarom uw poging is mislukt.

1. De cookie is gebonden aan het IP-adres, de vingerafdruk van het apparaat of andere niet-cookiegegevens die u niet hebt vastgelegd .
2. De originele cookie bevat een vervaldatum en is verstreken.
3. De cookie is voor eenmalig gebruik, dwz de server roteert de waarde bij elk verzoek / antwoord en maakt elke cookiewaarde ongeldig die is al gebruikt.
4. De cookie is gebonden aan een sessie die niet langer op de server bestaat (mogelijk omdat je bent uitgelogd).
5. De cookie is gekoppeld aan een verborgen element binnen de pagina (bijv. een CSRF-token) en je hebt die waarde niet vastgelegd of opnieuw gemaakt.
6. De server is load-balanced, met de sessiestatus in proc en een tijdelijk sessie-stickiness-mechanisme dat wordt afgedwongen door de load-balancer. In uw nieuwe sessie kreeg uw cliënt een ander knooppunt toegewezen binnen de farm waar de sessie niet bestaat.
7. De webserver gebruikt een regelsengine om verdachte activiteit te detecteren, en uw vervalste cookie werd gepresenteerd buiten volgorde of op een onverwacht moment.
8. De cookies waren prima, maar je hebt een ander detail verknoeid, zoals de verwijzende koptekst.

1. De cookies zelf zijn mogelijk ondertekend of gecodeerd, niet de verbinding die ze heeft afgeleverd.
2. De server heeft mogelijk de sessie uit de database verwijderd toen je uitlogde.

Zoals gezegd heeft de server de cookie die je zojuist hebt gestolen ongeldig gemaakt toen je je afmeldde, waardoor het waardeloos werd om te doen alsof je jezelf was.

Dus als je echt wilt testen of je je cookies probeert te stelen om te testen wat er nodig is om uw sessie van deze specifieke webservice te stelen, moet u uw cookies exporteren en ze importeren in een nieuwe browser / incognitomodus zonder uit te loggen op uw oorspronkelijke browsertabblad.

Maar Let op: cookies worden ook vaak gecontroleerd aan de hand van een hele reeks andere criteria. We kunnen controleren op IP, user-agent, enz. https://wingsdream.wordpress.com/tag/mitigating-http-session-hijacking/

We zouden ook kunnen bedenken nog slimmere strategieën, zoals een systeem van voortdurende verversing van tokens of browser-vingerafdrukken, om te controleren of de persoon die in het bezit is van deze cookie de persoon is aan wie we die cookie hebben gegeven en dat deze niet is gestolen. Dus zelfs als u de authenticatiecookies 'steelt', kunt u mogelijk nog steeds niet verifiëren met hen.

De sessie is ongeldig gemaakt op de server. Beveiligde websites doen dit om precies het soort aanval te voorkomen dat u beschrijft. Wanneer u zich afmeldt, verwijdert de server de sessie uit zijn eigen database, zodat zelfs als dezelfde sessiecookies opnieuw worden gebruikt, ze niet door de server worden geaccepteerd. Daarom is het belangrijk om correct uit te loggen bij de website in plaats van gewoon uw browser te sluiten, zelfs als uw browser de cookies niet bewaart.

Onveilige websites kunnen de sessie op de server laten rondslingeren, zodat zelfs als u eenmaal bent "uitgelogd" (dwz de cookies uit uw browser hebt verwijderd), kunnen dezelfde sessiecookies later nog steeds worden gebruikt.

Probeer uw experiment te herhalen, maar log deze keer niet uit vooraf. Log in op de website en verwijder de cookies vervolgens handmatig uit uw browser. Als u de website opnieuw bezoekt zonder de cookies, bent u niet ingelogd. Herstel nu de cookies en probeer de website opnieuw te bezoeken, en u zou opnieuw moeten zijn ingelogd.

Voor eenvoudige sites zou het kopiëren van cookies voldoende moeten zijn. Een meer "veilige" site pint uw sessie vast zoals anderen al noemden op andere factoren, zoals IP.

Er is ook de mogelijkheid dat er een JavaScript-code is die andere permanente waarden controleert, zoals Local / Session Storage, IndexDB enzovoort. Aan. Probeer ze eens te bekijken. Het zou ook kunnen dat dit een single site applicatie is waarbij alle data wordt geladen via ajax en oAuth samen met een vorm van persistent storage. Geen cookies nodig omdat het geheim ergens anders wordt opgeslagen.

In veel gevallen is het stelen van cookies IS voldoende om te authenticeren, de kans is groot dat je iets verkeerd hebt gedaan.

Let op: TLS / encryptie is hier niet relevant. Tegen de tijd dat u de cookie uit de header leest, is het verkeer al gedecodeerd. Alles wat Chrome u laat zien, is al gedecodeerd, codering is volledig transparant.

Om de vraag te beantwoorden. Authenticatieschema's variëren. Soms gebruiken ze alleen cookies, in dat geval is stelen voldoende. Soms gebruiken ze helemaal geen cookies. Soms gebruiken ze een combinatie van cookies en andere gegevens.

Er zijn oneindig veel cookieschema's. Er is geen eenvoudig antwoord voor alle.