Loginproblem - Sessioner och IP

Min site använder sig av sessionsvariabler för inloggningen. Om uppgifterna stämmer i databasen, så sätts några sessionsvariabler, inklusive IP-nr för den som loggar in. Funktionen som kollar om man är inloggad kollar bl.a. att det IP-nr man har NU stämmer med det IP-nr man loggade in med.

Nu har jag en medlem som (enligt uppgift) bara är inloggad på själva inloggningssidan. Om hon surfar vidare till något roligare inom siten, anses hon inte längre inloggad! Tar hon sig tillbaka till inloggningssidan så är hon det! :q Det hör till saken att jag har en 70-80 medlemmar och det är bara hon som har problem (så vitt jag vet). (Och jag vet säkert att det funkar för en hel del.) Så jag vet inte riktigt var jag ska felsöka... Några tips? :q

Ni som kan det här med sessioner, vad händer om:

* Hon inte tillåter sessionscookies att lagras? (Hon tror att hon gör det, men... )
* Hennes anslutning hela tiden skickar ett nytt IP-nr? Jag har skäl att tro att hon ansluter via AOL ( x( ) och det är väl så den anslutningen funkar?

Skulle något av det kunna förklara fenomenet? :q Alla tips mottages tacksamt!

RED: Det här borde kanske postats i ett annat forum? Ursäkta, i så fall! :r Siten är skriven i PHP, så...

Re: Loginproblem - Sessioner och IP

aasah skrev:

* Hennes anslutning hela tiden skickar ett nytt IP-nr? Jag har skäl att tro att hon ansluter via AOL ( x( ) och det är väl så den anslutningen funkar?

Efter lite googlande, visst kan det vara så. Uppenbarligen ändrar AOL ip-adress hela tiden medan man fortfarande är uppkopplad. Jag hittade följande tråd som bekräftar det: http://www.webmasterworld.com/forum48/2159.htm

Jag tror att problemet skulle försvinna om du struntade i att kolla ip. Åtminstone om hon verkligen tillåter cookies, och det har vi ju i nuläget ingen anledning att betvivla.

Tack, UlfT! Då vet jag vad problemet är... få se hur jag löser det...

Jag vill helst inte skippa ip-kollen rakt av, aftersom jag blivit rekommenderad att ha den av säkerhetsskäl. (Av andra wF:are.) Så jag får se hur jag gör.

aasah skrev:

Jag vill helst inte skippa ip-kollen rakt av, aftersom jag blivit rekommenderad att ha den av säkerhetsskäl. (Av andra wF:are.) Så jag får se hur jag gör.

Jag kan ju inte påstå att jag har särskilt stora kunskaper rörande säkerhet. Men en tanke kan ju vara att skriva cookies som högst osannolikt kan reproduceras av någon annan användare. Det torde ju vara där som säkerheten annars brister om man skippar en ip-koll. Jag funderar också över om https skulle kunna vara någon hjälp för ditt problem: http://www.ietf.org/rfc/rfc2818.txt
Det är ju något som används i många situationer där det ställs höga krav på säkerhet. Fast jag är osäker på exakt hur det skulle kunna passas in i just ditt fall. I vilket fall, jag föreställer mig att en https-anslutning i sig själv håller någon slags koll på vem det är som är uppkopplad (någon mer kunnig får rätta mig om jag har fel).

UlfT skrev:

aasah skrev:

Jag vill helst inte skippa ip-kollen rakt av, aftersom jag blivit rekommenderad att ha den av säkerhetsskäl. (Av andra wF:are.) Så jag får se hur jag gör.

... Men en tanke kan ju vara att skriva cookies som högst osannolikt kan reproduceras av någon annan användare. Det torde ju vara där som säkerheten annars brister om man skippar en ip-koll. Jag funderar också över om https skulle kunna vara någon hjälp för ditt problem: http://www.ietf.org/rfc/rfc2818.txt...

Tack för tipsen. :) https är inte aktuellt, SÅ viktig är inte säkerheten. Men jag kan på rak arm komma på minst en idiot som gärna skulle hacka sidan, så jag vill inte ta alltför lätt på det heller...

Problemet med cookies är vad som händer om användaren vägrar att ta emot dem. Plus att då måste man verkligen veta vad man gör i säkerhetsvägen eftersom användaren kan läsa och manipulera dem själv.

Men jag funderar på att pröva med att bara matcha de tre första bitarna av ip-nummret för folk som ansluter via AOL. Kan de inte logga in vanliga vägen lär jag ju få veta det... OM det funkar så är det kanske trots allt tillräckligt bra för att fungera? :q

aasah skrev:

Men jag funderar på att pröva med att bara matcha de tre första bitarna av ip-nummret för folk som ansluter via AOL. Kan de inte logga in vanliga vägen lär jag ju få veta det... OM det funkar så är det kanske trots allt tillräckligt bra för att fungera? :q

När du skriver om bitar, menar du de tre första bitarna i det fyra byte långa ord, som en ip-adress faktiskt är? Eller menar du de tre första siffergrupperna? Eller kanske bara de tre första siffrorna? Nåväl, förmodligen har AOL en drös olika subnät, inom vilka alla nya ip-adresser står att finna. I mitt BBB-abbonemang, är jag på ett subnät som rymmer 254 olika adresser (alla adresser med enbart 0 eller 1 i den sista byten, är ej tillåtna). Det framgår av min nätmask, som är 255.255.255.0. Du kan läsa mer om detta här: http://www.johnscloset.net/primer/subnet.html

I vart fall, att gå på den första byten, eller rentav två eller tre bytes av ip-adressen, borde ge en rimlig säkerhetsnivå. Försöker någon hacka sig in, måste han vara hos samma isp som offret, vars konto han försöker hacka. Och gör han det under den förutsättningen, då vet du vilken ip-adress han hackade från, och kan lämna in en abuse-anmälan till hans isp. Därför är det troligare att en hacker väljer att gå via en anonym proxy. Och den lär knappast vara inom samma subnät, om inte offrets isp har strulat med sitt nätverk, och råkat lämna en proxy-server öppen av misstag. men säkerhet i all ära, det finns ju gränser för hur långt det är rimligt att gå i ett system som inte hanterar stora pengasummor, etc. Går hackern via en anonym proxy som inte finns hos offrets isp, vilket är det troliga, då kommer han inte lyckas, just därför att du ser att han är på ett helt annat subnät. Därmed anser jag att du har uppnått en relativt hög säkerhetsnivå. Kanske inte acceptabelt för en internetbank. Men definitivt acceptabelt för mindre kritiska siter, som ett forum, eller vad det nu är du har.

Men alltså, sessioner är väl helt säkert? Även om de använder cookies för att hålla reda på vilken session som hör till vem så finns det väl ingen chans för användaren själv eller någon annan person att läsa eller ändra sessionsvariablerna?

M@rtin skrev:

Men alltså, sessioner är väl helt säkert?

Tja, ingenting är väl helt säkert. ;) Men det är fullt möjligt att du har rätt i att sessioner är tillräckligt säkra. Vi får se om "andra wF:are" kan hoppa in och förklara varför det är nödvändigt att kolla ip utöver att hantera sessioner. :)

Jag antar servern ger användaren en cookie med typ ett id. Varje gång en sida laddas sedan så avläses id't och rätt värden sätts på variablerna. Användaren har ingen chans att se eller påverka variablerna. Men om man sätter typ en session online till true när personen loggat in så skulle någon annan kunna ändra sin cookie till det id som personen som loggat in har och sedan på så vis ta sig in på den personens konto. Och det är ju faktiskt en inte allt för obetydande risk. Men först och främst måste man ju gissa rätt id och sen antar jag att det inte är så enkelt att det är en siffra utan jag hoppas att sessioncookiesarna krypteras på något sätt.

Som jag själv konstaterade i början, har jag inte särskilt stora kunskaper i datorsäkerhet. Hur sessionshantering fungerar, har jag ingen aning om. Du antar att servern skriver ner ett id. Frågan är då vilket id. Om det är primärnyckeln i användartabellen i systemet, är det säkert rätt enkelt att knäcka det. I många olika fora, framgår detta id rätt tydligt. Jag kan tex se att M@rtin har id=49 i wF:s databas. Om nu sessionshanteringen skrev just detta id till en cookie, skulle jag alltså kunna redigera min cookie-fil så att det står 49 där, och därmed kunna leka M@rtin om jag ville. Men själv tror jag inte att sessionshanteringen är så korkat konstruerad. Jag föreställer mig att sessionshanteringen bygger på att man slumpar fram något nytt, unikt tal, för varje ny session. Om det är så, skulle det bli oerhört svårt att kapa någon annans session genom att redigera sin cookie-fil. Hackern har helt enkelt ingen möjlighet att veta vilket sessions-id det tilltänkta offret har. I ett sådant läge bedömmer i vart fall jag att det är onödigt med en ip-kontroll. Men, som sagt, jag vet inte hur sessionshantering fungerar.

Tog temporärt bort beteckningen "löst" eftersom vi fortfarande diskuterar intressanta saker.

UlfT skrev:

aasah skrev:

Men jag funderar på att pröva med att bara matcha de tre första bitarna av ip-nummret för folk som ansluter via AOL. Kan de inte logga in vanliga vägen lär jag ju få veta det... OM det funkar så är det kanske trots allt tillräckligt bra för att fungera? :q

När du skriver om bitar, menar du de tre första bitarna i det fyra byte långa ord, som en ip-adress faktiskt är? Eller menar du de tre första siffergrupperna? Eller kanske bara de tre första siffrorna?....

I vart fall, att gå på den första byten, eller rentav två eller tre bytes av ip-adressen, borde ge en rimlig säkerhetsnivå.

Jag menade de tre första siffergrupperna. Alltså 255.255.255 i ditt exempel (255.255.255.0) . Det du menar räcker, är det mindre än detta? Räcker det att kolla första 255:an? :q

Och ja, självklart finns det gränser för hur långt man går. https är tex inte aktuellt, och ev öppna proxy-anslutningar är nog också över huvudet på mig.

UlfT skrev:

M@rtin skrev:

Men alltså, sessioner är väl helt säkert?

Tja, ingenting är väl helt säkert. ;) Men det är fullt möjligt att du har rätt i att sessioner är tillräckligt säkra. Vi får se om "andra wF:are" kan hoppa in och förklara varför det är nödvändigt att kolla ip utöver att hantera sessioner. :)

Jag hittade den gamla fil i vilken jag fick detta råd. Tror dock att det kommenterats av fler personer än tydal i någon annan tråd som jag inte hittade i hastigheten. Jag läste praktiskt taget allt wF har om sessioner och inloggningsaspekter innan jag skrev min kod. Men den sökningen gör man inte om i en handvändning!! Det tog några dagar att läsa igenom allt som fanns. Därmed inte sagt att jag inte kan ha missat något väsentligt eller missförstått något. Jag vet inte heller hur sessioner fungerar rent tekniskt.

aasah skrev:

UlfT skrev:

aasah skrev:

Men jag funderar på att pröva med att bara matcha de tre första bitarna av ip-nummret för folk som ansluter via AOL. Kan de inte logga in vanliga vägen lär jag ju få veta det... OM det funkar så är det kanske trots allt tillräckligt bra för att fungera? :q

När du skriver om bitar, menar du de tre första bitarna i det fyra byte långa ord, som en ip-adress faktiskt är? Eller menar du de tre första siffergrupperna? Eller kanske bara de tre första siffrorna?....

I vart fall, att gå på den första byten, eller rentav två eller tre bytes av ip-adressen, borde ge en rimlig säkerhetsnivå.

Jag menade de tre första siffergrupperna. Alltså 255.255.255 i ditt exempel (255.255.255.0) . Det du menar räcker, är det mindre än detta? Räcker det att kolla första 255:an? :q

De tre första siffergrupperna, motsvarar totalt tre bytes, så det ska alltså inte tolkas som att jag menar att det räcker med den första 255:an, eftersom det bara är en byte. Siffergrupperna står alltså för vardera en byte. Därför ser du aldrig ip-adresser i stil med 312.456.666.285. Vill man göra en någorlunda säker koll på ip-numret, bör det räcka med att kolla att användaren håller sig inom samma subnät, vilket alltså är de tre första siffergrupperna i mitt exempel.

aasah skrev:

och ev öppna proxy-anslutningar är nog också över huvudet på mig.

Med en ip-koll på några av siffergrupperna, har du direkt uteslutit flertalet öppna proxy-servrar. Men du har ingen garanti för att det inte råkar finnas en öppen proxy-server inom samma subnät. Det är inte så mycket att göra åt, mer än att abuse-anmäla de ip-nummer som du i efterhand vet har använts av hackare. Har de gått via en sådan proxy-server, är den på något vis kopplad till den isp som du skickar din abuse-anmälan till. Då är det de som får se till att fixa till denna proxy-server. Abuse-anmälan skulle du ju i alla fall ha gjort, för det kan ju lika gärna vara hackerns egna ip-adress, och då är han uppkopplad via denna isp.

aasah skrev:

UlfT skrev:

M@rtin skrev:

Men alltså, sessioner är väl helt säkert?

Tja, ingenting är väl helt säkert. ;) Men det är fullt möjligt att du har rätt i att sessioner är tillräckligt säkra. Vi får se om "andra wF:are" kan hoppa in och förklara varför det är nödvändigt att kolla ip utöver att hantera sessioner. :)

Jag hittade den gamla fil i vilken jag fick detta råd. Tror dock att det kommenterats av fler personer än tydal i någon annan tråd som jag inte hittade i hastigheten. Jag läste praktiskt taget allt wF har om sessioner och inloggningsaspekter innan jag skrev min kod. Men den sökningen gör man inte om i en handvändning!! Det tog några dagar att läsa igenom allt som fanns. Därmed inte sagt att jag inte kan ha missat något väsentligt eller missförstått något. Jag vet inte heller hur sessioner fungerar rent tekniskt.

Tydal kan betydligt mer än mig om detta. Men jag kan ge mina reflektioner runt en del han skrev:

AOL kör förmodligen med DHCP, dvs när man går ut på nätet så får man en ledig IP-adress ur poolen. När personen sedan stänger av datorn blir hans/hennes tidigare IP-adress tillgänglig för andra. På det viset kan du alltså inte samtidigt ha två personer med samma IP, men det är fullt möjligt att någon annan kommer in med IP-adress som tidigare använts av någon annan. Adresserna återanvänds liksom. Kallas för dynamiska IP-adresser.

Där har vi ju redan konstaterat att AOL tycks ha betydligt mer dynamiska ip-adresser än andra. De ändrar sig ju till och med under samma session.

Sessioner funkar så att när den skapas så slumpas ett tal fram som ska identifiera användaren.

Det tycker jag bör borga för en hög säkerhet genom att endast kontrollera sessioner. Då borde det vara onödigt med ip-koll.

Får man tag på någon annans cookie kan man alltså ta över den personens session genom att använda den cookien själv. Kallas session hi-jacking. Men det kan du alltså begränsa genom att kolla IP:t.

Men hur får man egentligen tag på en annans cookie? Det är ju bara din site som kan läsa de cookies som just din site har skrivit till användaren. Hackern kan inte läsa dem på något annat vis än genom att ha fysisk tillgång till datorn. Och skulle han nu på något vis verkligen komma över cookie-filen på den lokala datorn, är det sannolikt så att sessionen i alla fall har hunnit avslutas innan han har någon chans att utnyttja cookien för att kapa sessionen. Nästa gång det tilltänkta offret loggar in, är det en helt ny cookie som gäller. Då kommer inte hackern långt med den gamla cookien. Utöver det är det inte särskilt troligt att hackern verkligen har någon fysisk tillgång till offrets dator.

Tack för förtydligandet om ip-adressen! :birp

UlfT skrev:

Får man tag på någon annans cookie kan man alltså ta över den personens session genom att använda den cookien själv. Kallas session hi-jacking. Men det kan du alltså begränsa genom att kolla IP:t.

Men hur får man egentligen tag på en annans cookie? Det är ju bara din site som kan läsa de cookies som just din site har skrivit till användaren. Hackern kan inte läsa dem på något annat vis än genom att ha fysisk tillgång till datorn. Och skulle han nu på något vis verkligen komma över cookie-filen på den lokala datorn, är det sannolikt så att sessionen i alla fall har hunnit avslutas innan han har någon chans att utnyttja cookien för att kapa sessionen. Nästa gång det tilltänkta offret loggar in, är det en helt ny cookie som gäller. Då kommer inte hackern långt med den gamla cookien. Utöver det är det inte särskilt troligt att hackern verkligen har någon fysisk tillgång till offrets dator.

Jag håller med om att det låter overkligt. Men just eftersom jag eg inte behärskar det här själv, och det är odiskutabelt att folk gillar att hacka siter tycker jag det är bättre att kolla onödigt mycket än för litet. Sedan, vad folk ser och inte ser i andras datorer,... tja. Trojaner, spyware och allt elakt som cirkulerar kan nog ställa till en del. En som hade problem hade kopplat ur brandväggen för den var "i vägen"!!! (Som svar på om den kunde blockera sessionscookien.) Vad svarar man på sånt!?! Det finns så mycket okunskap och missbedömningar att jag tror att det är bättre att vara överdrivet försiktig. Inom rimliga gränser naturligtvis. Och det är klart att det går att diskutera var den gränsen går. :)

Jag har också för mig att det finns någon gammal "säkerhetstråd" här någonstans där man bl.a. diskuterar risken av att få tag i andras sessioner eller cookies... Kommer inte i håg vilket. Den ledde i alla fall till att wF gjorde om systemet med "Mina filer", så helt riskfritt är det nog inte. (Fast det behöver inte vara relevant för det jag gör alls, minns bara diskussonen lite vagt.)

Du antar att servern skriver ner ett id. Frågan är då vilket id. Om det är primärnyckeln i användartabellen i systemet, är det säkert rätt enkelt att knäcka det.

Ja nej jag menar inget databas-id för man behöver ju inte hålla på med databaser för att skapa sessioner, utan jag menar typ ett id som användaren tilldelas av servern när den laddar en sida. T.ex. ett slumptal. Så ja vi menar nog samma :)

Jag googlade lite på begreppet session hijacking, och hittade följande intressanta sida: http://www.imperva.com/application_defense_center/glossary/session_hijacking.html

Tydligen kan det gå att få tag på session-id utan att ha tillgång till cookie-filen.

In a "referrer" attack, the attacker entices a user to click on a link to another site (a hostile link, say https://www.hostile.com):

GET /index.html HTTP/1.0
Host: <https://www.hostile.com>
Referrer: <https://www.mywebmail.com/viewmsg.asp?msgid=438933&SID=2343X32VA92>

The browser sends the referrer URL containing the session ID to the attacker's site - www.hostile.com, and the attacker now has the session ID of the user.

Se upp för detta. Det är bara alltför enkelt för en hacker att lägga upp en länk till sin egna site på din site. Sedan kan han bara fiska i loggarna för att samla in session-id. Detta förutsätter att du faktiskt har session-id i url:en, vilket du alltså inte bör ha.

Tack igen, UlfT! :)

En sak som jag inte förstår är hur dessa sessionsid:n genereras? Inte är det väl de enskilda siterna som genererar dem? Jag skickar i alla fall inte iväg någon icke-persistent cookie till klienten handgripligen. Så nog måste det skötas av PHP, servern eller något? Så hur vet man hur de ser ut? Och huruvida de skickas i klartext eller ej?

Fast slutsatsen är i alla fall klar: ipkollen behövs!

Det är servern som kapar sessionsid:t i samband med att sessionen/sessionsfilen skapas.
Servern skickar sedan iväg en header till webbläsaren, för att sätta en cookie där sessionsid sparas.

Tack, matte! :)

Sessionsvariabler skickas antingen med GET eller ur en cookie från användaren beroende på om användaren accepterar cookies.
Då GET är osäkrare brukar en del sajter kräva att man använder cookies.

Tinwëlint skrev:

Sessionsvariabler skickas antingen med GET eller ur en cookie från användaren beroende på om användaren accepterar cookies.
Då GET är osäkrare brukar en del sajter kräva att man använder cookies.

Ett förtydligande här.

Sessionsvariabler/värden lagras och används alltid på servern. Det som skickas med GET/cookie är sessionsid som knyter användaren till en viss session/sessionsfil.