Search for: sig security

12 juni, 2019

Dessa vilda dagar

Pratade tillsammans med Mattias med Marcus Murray från TrueSec och han sa att ”Ondskan har mognat”. Det slog an en klang och jag har funderat på det en hel del. Sanningen är att det känns som innan nästan inte hinner reagera mellan att man får veta att en viss typ av attacker blir vanligare och man ser att det händer i ens närhet.

Förut kunde attacker hanteras utan allt för mycket svett. Ett totalt övertagande av en miljö hände ju även då, men det vanligaste var att man hanterade enstaka datorer med skadlig kod eller läckta uppgifter. Idag är det mer och mer vanligt att man helt plötsligt har hundratals servrar och klienter som är krypterade eller på annat sätt övertagna. Ett litet ”nålstick” dödar hela organisationen.

Attacker blir allt mer riktade och det har vi ju talat om många gånger tidigare. Vad blir det av detta i framtiden, kan man undra? Hur många system måste tas över innan någon form av smärtgräns är nådd. Baltimore hålls gisslan, men när hör vi att även New York, Seattle och Washington råkar ut? Är det framtiden? Att i princip alla är drabbade och det blir standard att återställa allt från början eller punga ut med miljoner dollar till hackare för att få tillbaka viktigt data. Det kommer till sist bli som en form av hackar-skatt. Kanske blir det ett system med beskyddarpengar för att man inte ska bli drabbad. Och om man nu spenderar pengar på security operations centers som hela tiden övervakar allting, blir det ju ändå en ökad kostnad för att kunna försätta driva sin verksamhet. Detta i sig är också en form av ”hackarskatt” för alla. En kostnad som man anting betalar till attackerare eller till de som ska skydda mot dem.

Är Zero Trust Networks ett hopp för framtiden eller tar sig allt mer organiserade hackers förbi även detta? Det är inte utan ett visst mått av frustration som jag ser hur det blir allt mörkare på säkerhetsfronten.

Men kanske måste man även se ljuset. Vi blir allt mer säkerhetsmedvetna och fler och fler utbildar sig i säkerhet, vare sig de vill jobba inom området eller bara förstå hur saker fungerar.

28 mars, 2019

Misstag med sessionshanteringen i webbapplikationer

Låt oss vara lite tekniska för en stund. Autentisering, auktorisering och sessionshantering är en svår konst. Man vill att användaren ska loggas in på ett säkert sätt och att man inte ska kunna ta sig in i sessionen. Här är några vanliga misstag som görs av programmerare.

Session fixation

När man bygger en webbapplikation är det ganska vanligt att man använder sessions-id. Dessa är till för att man ska kunna hålla en användare inloggad. Det är en mycket känslig del av det hela rent säkerhetsmässigt. Den korrekta metoden är att logga in en användare och sedan sätta ett sessions-id därefter. Detta ska leva tills användaren loggar ur eller tills en viss tid uppnåtts. När jag utför pentester, stöter jag ofta på webbapplikationer som sätter sessions-id INNAN användaren loggar in och sedan använder samma sessions-id EFTER att du loggat in. I ett sådant scenario går det ofta att ta över användarens hela session med ett mail och lite social engineering.


Man skriver ett mail med en länk till applikationen som man ska hacka. Detta mail anger ett sessions-id som man själv hittat på. Användaren klickar på länken och loggar in som vanligt. Nu vet du denna användares sessions-id efter du själv bestämt det. Då kan du på din egen webbläsare ange samma sessions-id och gå in som användaren utan att behöva logga in.

cookies utan secure-flaggan

Ofta realiseras sessions-ids med cookies. Om man inte sätter flaggan ”secure” på dessa, kan man övertala applikationen att skicka dem över en klartextförbindelse. Genom att använda ett verktyg som sslstrip, kan en attackerare på det lokala nätverket få tag i giltiga sessionscookies.

sessions-id i get-metoden

Om man tillåter sessions-ids i address, som tillexempel www.sårbarsite.se/app?SESSION=235234532556768, kan en användare av misstag råka ge bort sin session via mail. Man bör också undvika att ta in variabeln via både get och post.

Sessionen tar aldrig slut

En session måste ha en klocka som räknar ner och avslutar sessionen när användaren varit inaktiv en viss tid. En del webbapplikationer byter även sessions-id när sessionen varit igång en viss tid. Men många webbapplikationer låter sessionerna lever i all evighet, eller har extrema värden som gör att en session kan vara inaktiv i veckor och fortfarande vara aktiv.
cookie utan httponly-flaggan

Mindre allvarligt, men ändå. En sessionscookie bör vara satt httponly, för att hindra att man på klientsidan kan manipulera den med javaskript-kod.

Ingen webcookie

En webcookie är ett värde som läggs till jämte session-id. Den måste finnas i anropen för att användaren ska kunna göra ändringar i webbapplikationen. En session är nämligen giltig i alla flikar i en webbläsare (Om man inte köra i inprivate mode). Detta gör att elak kod som körs i en annan flik kan göra ändringar i den webbapplikation du använder. Ofta saknas denna webbcookie, vilket gör webbapplikationen sårbar för en cross site request forgery-attack. Med en webcookie kan du bara göra ändringar i webbapplikation från den fliken du loggade in i webbapplikationen med. Detta kan skydda dig om du är inne och ändrar inställningarna i en routers webbinterface medan du surfar i en annan flik (Inte att rekommendera, dock!)

Ingen HSTS (HTTP Strict Transport Security)

HSTS är en HTTP Header som säger åt en webbläsare att ALLTID använda HTTPS mot en sida. Denna enkla mekanism gör verktyg som sslstrip verkningslösa. Tillsammans med secure-flaggan på sessionscookie, ökar de säkerheten enormt.
Ingen HTTPS

Detta borde inte vara ett problem idag, men det är det. Siter som hanterar inloggningar men inte har HTTPS finns fortfarande. Detta är ganska självklart ett problem. Men det finns fortfarande de som lever i det förgågna.
Så för att sammanfatta: det finns ett antal metoder man kan använda för att se till att användaren kan lita på att deras interaktioner mot din webbsida är säker. Använd dessa!

Scroll to top