6 svar · 1 605 visningar · startad av Mattias Nordin
Enligt många artiklar så finns det nu ett verktyg som kan sniffa och kopiera cookies i publika nätverk.
http://www.idg.se/2.1085/1.348645/inte-bara-facebook-hotat
Har jag missat något? Varför sparar man inloggningsuppgifter i en Cookie? Eller pratar det om server sessions?
Det jag har sett i googles fall är att de har flera databaser med flera olika inloggningsförfaranden där en *nödlösning* är att använda cookies för att föra över inloggningen från system a till b. Naturligtvis inte säkert.
Ja, det är sessions-id som sänds via en cookie. Denna cookie skickas okrypterat på en del större webbsidor, även om annat innehåll på sidan är krypterat. Det betyder att någon annan kan ta över sessionen.
Det bästa vore om cookien bara skickades över https, man kanske måste göra hela webbsidan i https då.
Verktyget kan sniffa all http-trafik som sänds i klartext, inte bara cookies. Det gör visserligen inte att man kan "kapa" ett FB-konto i meningen att man kan ändra lösenordet och ta över det (för att göra det måste man känna till lösenordet, och det skickas över https just på FB) men i övrigt kan man göra i princip vadsomhelst med kontot (kolla vänner, PM etc) mha sessionskakorna. Skickas de över http en enda gång så kan någon sniffa dem. Andra sidor har så klart inte stöd för https alls.
De nätverk som är sårbara är helt öppna nätverk, WEP och möjligen WPA1. Och även trådade nätverk som är anslutna till en alltför dum hub (!)
Det finns ett sätt att undvika denna typ av attack från en site-ägares sida:
Känns ju som en dum lösning med sessionshanteringen från början. Hur fungerar det konkret?
Jag vet inte riktigt hur stor skillnad det gör men jag brukar lägga in en krypterad nyckel med info som ip-adress, webbläsarinformation, salt, och lösenord i olika kombinationer. Sen ska den nyckeln valideras. Visst, det går att fejka ip-adress mm. men det blir ju ändå lite svårare att kapa sessionen.
Jag vet inte riktigt hur stor skillnad det gör men jag brukar lägga in en krypterad nyckel med info som ip-adress, webbläsarinformation, salt, och lösenord i olika kombinationer. Sen ska den nyckeln valideras. Visst, det går att fejka ip-adress mm. men det blir ju ändå lite svårare att kapa sessionen.
Men om du sitter på samma McD som attackeraren och alltså sitter bakom samma NAT så är ju det problemet redan löst för dennes del. :)
Och resten av sakerna är ju i princip lätta att fixa. Bara spoofa user agent samt de cookies som finns på sidan.
Känns ju som en dum lösning med sessionshanteringen från början. Hur fungerar det konkret?
Det är en kompromiss. SSL använder en del CPU, så stora som små siter måste väga in huruvida den extra CPU-kraften är värd nyttan. SSL enbart för själva inloggningen är en kompromiss i det att man visserligen kan stjäla kakor och komma åt saker på kontot, men inte stjäla kontot permanent. Och inte heller snappa upp lösenordet, som offret skulle kunna använda på andra sidor.
Nästan alla sidor använder sessions-cookies. Det är ofta en inbyggd komponent i "server-sessioner" som programmeraren inte alltid ser. Förlitar sig sedan programmet på verifiering via sessionen så är det lätt att kapa om man sitter på samma nätverk. Tyvärr finns det inte många vägar runt det förutom just kryptering av all trafik till servern.
Själv är jag paranoid när jag är ute och kör en SSH-tunnel till min egen proxy-server, därmed går ingen trafik okrypterad på det öppna nätverk jag befinner mig. Man är osäker nog av att vara utelämnad till datorns egna brandvägg för att försvara sig inom ett offentligt nätverk. Sannolikheten att de ska läsa av min trafik hemma är i alla fall mindre än att de läser av den på en offentlig plats.
