WN - Login på webbsida, vad tänka på

WN (https://www.wn.se/forum/index.php)

- Serversidans teknologier (https://www.wn.se/forum/forumdisplay.php?f=4)

- - Login på webbsida, vad tänka på (https://www.wn.se/forum/showthread.php?t=26147)

Glömde tillägga att du bör använda moment som är unika för varje gång man loggar in.

Citat:

Det kan du ju inte såvida du inte kan köra egen kod på servern

Session Hijacking...

Hittade denna precis som jag tyckte var rätt värd att läsa
http://www.brainbell.com/tutors/php/php_my..._hijacking.html
Dock cookies

Tack för alla synpunkter. Men nu börjar det bli många bollar i luften.

"Vad har det för betydelse om det är klartext då all sessionsdata lagras på serversidan?"

Stämmer det att sessionsvariablen körs enbart på serversidan i ASP.NET ? för isf är det ju inget probelm alls. Eller?

Den ska enbart köras på serversidan... men om man som hackare registrerar sig själv på din sida och öppnar sin session (på något sätt) kan han ju ändra sina uppgifter till dina... dvs om han har id '10', kan han ju prova att ändra till '11' osv...

kass på ASP.NET, vet inte alls hur det fungerar. Men jag kan tycka att det är bra praxis att aldrig köra med saker i klartext.

Citat:

Originally posted by Brazzan@Jan 9 2008, 22:12
Spoofa ip går hur bra som helst.. ger liten säkerhetsökning. Det hela handlar om att göra allt svårare för "hackaren". Det är sant att det inte ger någon säkerhet på det sättet.

Låt oss säga att du ska du kör i klartext och du har en session som innehåller id't på personen som är inloggad, och man kan som användare ta bort saker i databasen som är kopplade till detta id't. Då har du möjligheten att spamma ut id'n till scriptet som raderar data beroende på id't, vilket resulterar i att databasen töms. Om man istället kör med allt hashat/krypterat kan han bara rensa datan som är kopplad till sessionen, samt att man inte kan gissa sig till andra id'n.

Tänk dig "DELETE FROM tabell WHERE id='$id' LIMIT 1";

$id innehåller då '10' i klartext...

Om du istället hashar/krypterar detta id så att du får "adsdP(912314FA)FA)" eller liknande, då kan sedan göra en säker select som inte är baserad på vad scriptet får in, och du plockar ut id'n och konverterar dem till samma hash/kryptering på servern, och sen matchar du och deletar.

Finns mkt bättre sätt att lösa säkerheten på dock.

Well, jag delar inte din uppfattning om att det skulle ge en ökad säkerhet. :)
Du bör ju designa alla SQL-frågor så att dom är i stil med "DELETE FROM tabell WHERE user = '" . $_SESSION['id'] . "' LIMIT 1".

absolut :) alltså jag skrev '10' som exempel, vilket $_SESSION['id'] innehåller.

Alla har sina egna sätt att programmera :) så är det bara. Personligen kör jag aldrig i klartext på något.

Citat:

Originally posted by Brazzan@Jan 9 2008, 22:18
Glömde tillägga att du bör använda moment som är unika för varje gång man loggar in.

Citat:

Det kan du ju inte såvida du inte kan köra egen kod på servern

Session Hijacking...

Hittade denna precis som jag tyckte var rätt värd att läsa
http://www.brainbell.com/tutors/php/php_my..._hijacking.html
Dock cookies

Kryptering av sessionsdata skyddar inte mot kapning av sessioner.
Kommer en person över din sessions-cookie eller på annat sätt får reda på ditt sessions-id så kommer han att kunna ta över din session, såvida den inte är knuten till IP-adressen.

IP är osäkert, men bättre än inget... går dock att spoofa ip adresser.

EDIT* Klippt bort vissa delar pga feltänk av mig.

Citat:

Originally posted by Brazzan@Jan 9 2008, 22:34
IP är osäkert, men bättre än inget... går dock att spoofa ip adresser. Det skyddar inte just den kapade sessionen, men det skyddar från att kunna gissa sig till hur andras sessions data ser ut.

Istället för att kapa en session och ta bort 100 konton, måste man kapa 100 sessioner för att ta bort 100 konton.

Hehe, du missar poängen.
En användare kan aldrig ändra sitt värde i sessionen, och kommer alltså aldrig kunna radera något annat än sin egen data.
Såvida inte personen lyckas köra egna SQL-satser via något annat hål som inte har med sessionshantering att göra.

ajajaj... ignorera delar av vad jag skrivit. Har suttit med POST och GET i huvudet medans det handlade om sessioner. Dessa kan du ändra hejvillt och på så sätt själv bestämma vad som ska skickas till SQL-satsen.

Jag står dock fast vid att aldrig köra något i klartext.

Citat:

Originally posted by Brazzan@Jan 9 2008, 22:41
ajajaj... ignorera delar av vad jag skrivit. Har suttit med POST och GET i huvudet medans det handlade om sessioner.

Jag står dock fast vid att aldrig köra något i klartext.

Hehe... När det gäller att skicka diverse ID via querystringen så håller jag med om att det ger en ökad säkerhet genom att man inte kan "gissa sig fram" via 1, 2, 3 o.s.v.
Men den grundläggande säkerheten ska ändå vara att SQL-frågan matchar på både user (sessions-id) och databas-raden som kommer via GET.
Gör man det så behövs ingen kryptering av datan på querystringen.
Kryptering av "GET-värden" kan skydda om du t.ex. inte skyddat dig mot SQL-injections överallt.