Session hijack

<ole>

Nej, der er næppe nogen, der får logget ind på nogen sider med den kode - så på den måde er du nok helt sikker. Prøv at test den  *o)

Derudover er der nok ikke nogen grund til at lade Boris læse evt. fejlbeskeder.

/mvh
</bole>

Hej Ole

Hvorfor vil det ikke virke? Jeg glemte godt nok at nævne, at systemet kun har een bruger, så INSERT ændres til en UPDATE af det samme felt... Ved flere brugere, vil det naturligvis ikke fungere, da sessions og id i database ikke vil stemme overens meget hurtigt.

Angående fejlbeskeder, er det jo underordnet. Fejlbeskeder er kun imens jeg selv sidder og programmerer :-)

"Angående fejlbeskeder, er det jo underordnet. Fejlbeskeder er kun imens jeg selv sidder og programmerer" >> Ja, hvis det bare forholdt sig sådan, men det, viser al erfaring, ikke er tilfældet. Uanset ambitioner vil du et eller andet sted alligevel glemme det, og bare ét sted er potentielt katastrofalt. Prøve at kikke på denne guide, som prøver at give en idé til en bedre tilgang.

Hvorfor prøver du ikke bare at teste din kode? Så vil du få et par fejlmeddelelser, der tydeligt vil fortælle dig, hvad du laver af fejl. Hvis du af uransagelige grunde hellere vil gætte end teste, skal du ikke lede efter noget kompliceret. Det er såmænd så grundlæggende, som det kan være i PHP  =)

Så har jeg fået kigget på det. Havde kun skrevet det i hånden uden at teste det, da resten ikke var klart (og jeg var lidt doven og ikke gad oprette en database/tabel til det. Ups :o)). Men er gjort nu. Var jo nok nødvendigt for at teste det.

Angående fejlbeskeder, så er det klart man skal huske at fjerne dem igen. Det er nu en udemærket guide du har smidt. Skal igang med et nyt projekt om snart, hvor jeg nok vil overveje at gøre brug af den metode eller en lignende ... :) Selvom det går mig en smule på med de mange ekstra if sætninger der kommer ... ini_set("display_errors", "0"); vil ikke give det samme resultat?

Angående det kodemæssige jeg postede, var det en enkelt fejl der gjorde det ikke fungerede. Havde glemt at ændre "i" til "s" efter jeg md5-hashede indholdet af sessionen. Bevares der var nogle andre skønhedsfejl. Ved ikke lige hvordan mysql_error havde sneget sig ind, eftersom jeg benytter mig af mysqli. Det giver ikke en fejl, men det er selvfølgelig fjernet alligevel. Send_long_data er også unødvendigt. Stringen fylder ikke så meget. Desuden står den med et 1 tal, så den har ikke indflydelse på noget, da den starter fra 0 ...

Opbygningsmæssigt ville du selv gøre det anderledes? Jeg er lidt i tvivl om det er måden at gøre det. Forslag til forbedringer skal der altid være plads til :-)

ini_set("display_errors", "0"); har jo ingen indflydelse på fejlmeddelelser, du selv skriver ud i dine egne betingelsesstrukturer. Og når vi har if-strukturer fremme, så må det skyldes grundlæggende programmeringsmæssige misforståelser, at det går dig på.

"Angående det kodemæssige jeg postede, var det en enkelt fejl der gjorde det ikke fungerede" >> Så har du teste en anden kode end den, du viser på pastebin. I dén kode har du to lokale variabler i funktionen tjek_login: $conSesCheck og $conUrl, som aldig er erklæret og derfor ikke kan anvendes. At du sætter dem udenfor funktionen har ingen indflydelse indenfor funktionen, da de her hverken er erklæret som globale - eller er medsendt som argumenter til funktionen.

Når du tester med:


- så tjekker du jo bare på, om disse to strenge/tal er skrevet i den sessionfil, som brugerens session cookie peger på. Jeg kan ikke se, det skaber nogen somhelst øget sikkerhed.

Guiden er hermed rettet:

En bruger har i en tråd gjort opmærksom på, at han er ked af alle de nødvendige if-strukturer, dette medfører. Løsningen kunne være at oprette en funktion displayError til at håndtere fejlene:

Og når vi har if-strukturer fremme, så må det skyldes grundlæggende programmeringsmæssige misforståelser, at det går dig på.

Det kan da godt være. Det skal jeg ikke kunne sige? Men som udgangspunkt går jeg efter så lidt kode som muligt :) Og dermed typisk også så lidt arbejde for serveren som muligt. If sætninger som de omtalte trækker ikke mange resourcer, men de trækker flere end hvis de slet ikke var der :o) Der kan så laves en funktion som du har vist, hvilket jeg personligt synes er smartere istedet for de mange gentagelser.

I dén kode har du to lokale variabler i funktionen tjek_login: $conSesCheck og $conUrl, som aldig er erklæret og derfor ikke kan anvendes.

Korrekt, de er ikke sat inde i funktionen. Det er et rent tilfælde det virker med redirect, da den ligger i en mappe, som gør at stien stadig passer selvom variablen er tom. Kunne det tyde på i hvert fald.

Ideen er jo at sessionen opdateres efter hver forespørgsel. Det giver kun en 3. part et kort tidsrum at operere i. Meningen er så, at nøglen i sessionen skal passe med den i databasen. Det vil sige, at en 3. part ikke kan skabe en session med en tilfældig værdi, da den ikke vil stemme overens med databasens. Men jeg er nu i tvivl om det virker eller om det egentlig bare er fyld, fordi sessionen og databasen vil altid stemme overens, og det er bare den anden session, som skal "fakes", så vil personen være inde.

Måske det vil være bedre at have en fast værdi i databasen. Fx saltet fra login, som man sammenligner en session op imod. Og så samtidig have en session ved siden af, som skifter værdi ved hver forespørgsel?

"Men som udgangspunkt går jeg efter så lidt kode som muligt :) Og dermed typisk også så lidt arbejde for serveren som muligt" >> Det var præcis, hvad jeg mente. At spare en linje eller to medfører ofte langt værre ting.

Fra sætningen: "Ideen er jo at sessionen opdateres efter hver forespørgsel" - omtaler du noget helt andet end det, du viser i din kode. Du tjekker jo netop aldrig, hvad der står i databasen. Gjorde du, som du tænker, ville det, som du selv er inde på, ikke hæve sikkerheden.

Meget mere væsentligt vil det f.eks. være at overveje din brugers forskellige roller - og sætte hendes rettigheder herefter.

Mon ikke jeg ville kunne blive en meget rig mand, hvis jeg 'går all in' på, at den bruger, som bare kikker sider - og altså henter tekster, m.m. fra databasen - også har rettigheder til at opdatere, slette og måske endda bruge kommandoer som DROP og ALTER? Den slags ting er langt mere oplagte emner for din opmærksomhed.

Så er jeg tilbage efter nogle travle dage ... Beklager.

Det var præcis, hvad jeg mente. At spare en linje eller to medfører ofte langt værre ting.

Det er klart, at man skal vide, hvornår man kan/bør gå på kompromis med dette. Der er jo ingen kvaler i at spare disse linjer i forbindelse med fejlbeskeder ...

Du tjekker jo netop aldrig, hvad der står i databasen.

Jeg ved ikke, hvordan du kommer frem til dette?
Det er præcis det som jeg gør. Eller også misforstår jeg dig :-)

Mon ikke jeg ville kunne blive en meget rig mand, hvis jeg 'går all in' på, at den bruger, som bare kikker sider - og altså henter tekster, m.m. fra databasen - også har rettigheder til at opdatere, slette og måske endda bruge kommandoer som DROP og ALTER? Den slags ting er langt mere oplagte emner for din opmærksomhed.

Enig og uenig. Enig i, at SQL injections også kræver opmærksomhed. Der benytter jeg mig udelukkende af prepared statements, hvilket er en fordel der. Jeg mener dog ikke at kæden er stærkere end det svageste led, så derfor er session hijacking stadig nødvendigt at fokusere på.

At bygge det op omkring rettigheder er en god måde. Dog også en lidt "voldsom" måde. Men det er nok hvad det kræver, hvis man ønsker en forholdsvis sikker løsning.

Det er ikke en metode, jeg har benyttet fuldt ud før.
Så der bliver en smule læsning omkring måden det hænger sammen, før det programmeres :o) Er der noget bestemt materiale omkring emnet du kan anbefale? På nettet eller som køb i hardcopy fx?

Du kan i øvrigt også smide et svar :)

Fortsat god weekend.

"Jeg ved ikke, hvordan du kommer frem til dette?
Det er præcis det som jeg gør. Eller også misforstår jeg dig :-)" >> Det er præcis det, du ikke gør. Der tror jeg ikke, du misforstår mig - jeg tror, du misforstår din egen kode  =)

"At bygge det op omkring rettigheder er en god måde. Dog også en lidt "voldsom" måde. Men det er nok hvad det kræver, hvis man ønsker en forholdsvis sikker løsning." >> Det er ikke en spor 'voldsom' måde, men en absolut tvingende nødvendighed!

Hvis den bruger, som får hijacket sin session ikke har rettigheder til at gøre andet end at læse, sker der intet. En god brugerstyring er det allerførste trin i en sikker applikation. Ovenpå det kan du bygge alt muligt - men styringen af, hvad en bruger må og ikke må er helt essentielt.

Det er ikke det indtryk, du får, når du læser tutorials, men det er vigtigt at huske, at langt de fleste tutorials og artikler er skrevet af folk, som aldrig har lært noget somhelst om programmering - andet end, hvad de har læst i ubrugelige tutorials.

Søg på emner som ACL (Access Control Lists) og RBAC (Role Based Access Control), hvis du vil vide mere om emnet.

Jeg vil kigge nærmere på det hurtigst muligt.
Og det er præcis derfor jeg spørger, da der bliver lagt en masse møg op med misvisende informationer rundt omkring.

Jeg kan dog ikke lade være med at tænke over, hvad du skriver;

Hvis den bruger, som får hijacket sin session ikke har rettigheder til at gøre andet end at læse, sker der intet.

Det er naturligvis rigtig nok. Men - nu er dette til et CMS system, hvor der kun er een bruger og denne bruger er administrator og netop derfor formentlig også har brug for at have rettigheder til at slette. Som minimum til at tilføje og rette i hvert fald. Er der så nogen mulighed for rollefordeling i princippet? (Det kan være det fremgår, når jeg studerer emnet nærmere :o) )

Jamen, det er netop dét, der er problemet. Enhver bruger, som 'bare' kikker sider, henter data fra dabasen med samme DB-bruger som Admin - og sikkert også som udvikler og DB-arkitekten (som sikkert er én og samme person). Det må aldig ske!  *o)

Nu forstår jeg din tankegang og problematikken i det :-)
Det vil jeg undersøge nærmere! :)

Tak for hjælpen! Hvis du ønsker points, smider du bare et svar.
Ellers kan jeg vidst godt lukke tråden :)

Selvtak ... og du lukker bare  *o)

Okay :)