[Intet]

Originally posted by Robert@Jan 16 2008, 18:30
Och för att svara på din ursprungliga fråga: ja, ditt user-id som guppar omkring i serverns minne är kopplat till en sessionscookie som webläsaren skickar med vid varje fråga till din server. Det enda sättet det går att hijacka en session skulle vara om någon annan lyckas fejka en redan aktiv cookie och skicka med denna i ett anrop (och så fungerar det väl med alla teknologier?). Detta har egentligen inget att göra med vilket data du lagrar i sessionen (dvs i serverns minne).

Tack Robert för ett mer exakt svar än många andra utsvägningar . Men vad tolkar jag av ditt svar som, att det är "ok" att köra den tekniken ur säkerhetsynpunkt eftersom allt körs på serversidan? Som jag sa i inledningsvis, jag hanterar ingen sekretessbelagd information eller ens personnummer på använadre. Så jag är ute efter om det "duger" som säkerhet och inte är allmänt enkelt för Agda 85 att gå runt säkerheten...

[Lumax]

Intet: Kör på sessioner, men undvik att lagra känsliga uppgifter i sessionsvariabler. Om möjligt så lagrar du bara user-id.

[Intet]

Tack Fredrik, will do.

[Adestro]

Originally posted by Fredrik S@Jan 16 2008, 23:22
Intet: Kör på sessioner, men undvik att lagra känsliga uppgifter i sessionsvariabler. Om möjligt så lagrar du bara user-id.

Det är väl just det man inte ska göra? Hasha som sagt ihop id, ip och e-post åtmindstonde.

[Lumax]

Ursprungligen postat av Adestro

Det är väl just det man inte ska göra? Hasha som sagt ihop id, ip och e-post åtmindstonde.

Helt rätt, tar man med IP så kan man göra en check som gör att sessionen blir låst till sin ursprungliga IP-adress. Och kommer något anrop från en annan IP-adress så dödas t.ex. session. Att hasha ihop userid + ip eller ha dessa i olika sessionsvariabler är väl en smaksak.
Men vad vinner man på att ha med e-postadressen?

[Onkelborg]

Vad spelar det för roll vad ni lägger för något i session? Ingen mer än er egen kod kommer ju kunna läsa vad som står där ändå..

[Lumax]

Originally posted by Onkelborg@Jan 17 2008, 04:03
Vad spelar det för roll vad ni lägger för något i session? Ingen mer än er egen kod kommer ju kunna läsa vad som står där ändå..

Normalt sett, ja. Men rent generellt så bör man jobba enligt principen att all data (speciellt känslig data som lösenord etc.) enbart ska lagras i databasen, inte i sessioner och FRAMFÖR ALLT inte i cookies hos klienten.

Jag har t.ex. varit med om ett flertal gånger att man i delade miljöer/shared hosting har kunnat läsa sessionsfilerna på servern via ASP/PHP-script. Detta är såklart katastrof och en ren konfigurationsmiss, men likväl så bör man vara försiktig med vart man lagrar saker.

Många sidor har en automatisk inloggningfunktion (typ "kom ihåg mig") som bygger på att användarnamn och det hashade lösenordet ligger lagrat i en cookie hos klienten. Detta är en säkerhetsrisk eftersom man vid en XSS-attack kan sno cookie-informationen från besökarna.

Tillägg till mitt tidigare inlägg: Att hasha ihop id + ip funkar nog mindre bra eftersom det blir lite jobbigt att få fram "vem är jag" i så fall
Ska man låsa sessions till ett IP så får man helt enkelt spara IP-adressen separat.

[Robert]

Ursprungligen postat av Adestro

Det är väl just det man inte ska göra? Hasha som sagt ihop id, ip och e-post åtmindstonde.

Men tänk efter nu... det ni säger är att något som körs i serverns minne måste vara krypterat? Va? Ska man kryptera variabler i den körande koden också?

Som någon sa så gick det för honom att läsa sessioner från fil på servern, hmmmm då måste det vara fråga om någon form av persistent sessions eller någon specialare, eller att sessioner hanteras via databas om du kör klustrade webservrar. Men om man inte gör det så spelar det ingen roll vilken info som lagras i sessionen för det finns inget "interface" för en hacker att titta på variabeln även om denna person skulle lyckas hijacka en sessionscookie. Och om cookien (sessionen) blir hijackad så blir det enda resultatet att hackern helt plötsligt befinner sig i samma state som ursprungsägaren till cookien, tex att han helt plötsligt är inloggad på siten. DÅ har vi ett helt annat problem, men det är också en helt annan story.

Många här verkar prata om hur man authentiserar ägaren av en cookie, och visst, man kan lagra besökarens IP i sessionen och sedan kolla så att besökarens IP överenstämmer med det som han använde vid förra requesten, det skulle antagligen hindra en del skurkar då de inte kan uppfinna en befintligt sessionscookie ur tomma intet utan måste även spoofa fram korrekt IP.

Tänk bara på att inte lagra för stort data i sessionen då det kan bli lite trångt i minnen på servern om man har mycket besökare (och har lång sessionstid). Det idealiska ÄR alltså att bara lagra userid i sessionen för det är just det man behöver för att koppla det anonyma webanropet till en befintlig användare i databasen.

[Robert]

Originally posted by Fredrik S@Jan 16 2008, 22:54
En vanligt "komplexitet-policy" i datorvärlden är ju att lösenordet ska innehålla minst tre teckentyper av fyra möjliga (gemener, versaler, siffror och specialtecken) samt vara minst 8 tecken. Jag kan inte se att det skulle hjälpa en "bruteforceknäckare", snarare avskräcka!

Visst, man behöver inte testa kombinationer som inte uppfyller dessa krav, men å andra sidan så blir det väldigt tungt att knäcka lösenorden. Utan en sån policy så är det många som väljer svaga lösenord och dessa blir knäckt alldeles för fort.
Den enda praktiska nackdelen är ju att folk tycker att det blir komplicerat att välja lösenord, speciellt om dom är van att ha "hej" som lösenord.

Jag särskiljer på en dictionaryattack (som tar några sekunder att utföra) jämfört med en brute force attack som kan ta tusentals år. Jag utgick däremot från att bruteforce attacken började med att köra igenom en dictionary innan den ägnar sig åt tokslump!

Det enda som en sådan komplexity policy bidrar till är om Nisse försöker gissa Kalles password genom att skriva in namnet på hans katt i password rutan och trycka submit. För Nisse blir kalles password tusen gånger mer komplext med dessa regler, men för en dator så blir de enklare. Fast det är ju min åsikt förståss...

[Magnus_A]

En liten utvikning: vi lagrar ofta värden i kakor för att identifiera en återkommande användare. Identifieringen syftar till att komma ihåg enklare värden som inställningar, ej känslig data.
Vad är bra praxis (försöker använda svenska ord här)?
Att lagra oskyldig info om användare på ett krypterat sätt i kaka på användarens dator?
Att lagra oskyldig info om användare okrypterat i kaka på användarens dator?
Att endast lagra en unik identifierare i kaka hos användaren i krypterad form. Identifieraren används sedan för att hämta användarens fortfarande oskyldiga uppgifter i en databas.

Jag förutsätter att ingen obehörig har åtkomst till datorn och sitter och går igenom kakburken, och att uppgifterna det handlar om visserligen är personliga men harmlösa ur integritetssynpunkt för användare och säkerhetssynpukt för webbplatsen.