De flesta produkter du köper är inriktade på nätverks- och slutpunktsäkerhet. Dessa kommer inte att vara särskilt effektiva mot webapplikationsbrister. Så i det här inlägget belyser vi de vanligaste problemen vi ser i vårt arbete, från svaga nätverk till användaruppräkning. Förståelse för dessa utmaningar är inte bara viktigt för IT-proffs, utan även för individer och organisationer som strävar efter att förbättra sin säkerhetsställning i en alltmer sammankopplad värld.
När du använder en applikation är en av de första sakerna du stöter på någon form av autentisering. Detta är vanligtvis en kombination av användarnamn och lösenord. Och naturligtvis skiljer sig kraven avsevärt från webbplats till webbplats, det är vanligt att se krav på versaler och gemener, plus kanske några siffror och specialtecken. Längden är också en viktig faktor. En bra riktlinje att följa är att hålla den tillräckligt lång för att förhindra brute force-attacker och tillräckligt komplex för att den inte ska dyka upp i ett ordlista. En bra, rekommenderad längd är minst 10 tecken. Helst mycket mer.
Vi har stött på många applikationer där det enda kravet var en längd på sex tecken, så ett lösenord som "111111" skulle vara helt acceptabelt. Till och med en lågpresterande dator skulle kunna knäcka detta lösenord. För att inte tala om att det förmodligen finns i en ordlista så skulle brute force vara helt möjligt. Mer om lösenord här.
Ett praktiskt verktyg för att utvärdera den nuvarande statusen för SSL-implementeringen är SSL Labs, som är snabbt, enkelt att använda och omfattande. Det finns också verktyget SSL Checker, en mer förenklad version som är lättare för en icke-teknisk person att förstå. Det erbjuder dessutom en extra fördel genom att kontrollera SSL Security Headers. Vi kommer inte att gå in på alla detaljer kring SSL/TLS-implementeringen nu, då det skulle kräva flera sidor till. Vi får istället återkomma med en separat artikel om det. Men om du vill veta mer redan nu finns det ett annat praktiskt verktyg. Det kallas Google – vi tror att det börjar bli populärt! Eller känn dig fri att kontakta oss så ser vi till att du får rätt information.
Det finns flera vanliga sätt som applikationer kan avslöja giltiga användare på. Ett av de vanligaste och enklaste sätten är genom inloggningsfunktionen. Ett exempel: Du försöker logga in på en applikation. Om du anger rätt användarnamn men ett felaktigt lösenord och svaret blir "Lösenordet är felaktigt", är detta en ledtråd om att användaren faktiskt existerar. Om du däremot provar ett annat (ogiltigt) användarnamn och svaret blir "Inte en giltig användare", kan du nu enkelt avgöra att den första användaren är en giltig användare.
För en angripare skulle detta vara en bra möjlighet att försöka sig på brute force-attacker mot användarna i applikationen, eftersom applikationen avslöjar om en användare är giltig eller inte.
De största säkerhetsproblemen under 2017 och 2018 har varit olika typer av injektioner. Så, vad kan injiceras? SQL-frågor, OS-kommandon, HTML-innehåll, hela sidor av innehåll och skript. Var kan detta injiceras? Överallt där användarinmatning krävs eller där användare kan ändra data, t.ex. textfält, användarnamn/lösenordsfält, sökfunktioner, feedback- och kommentarsfält, URL:er, etc.
Uppladdade filer kan medföra allvarliga konsekvenser för både applikationen och dess filsystem. Det är ofta så att det saknas filter för vilka filtyper som får laddas upp. Om endast en eller två filtyper behövs bör alla andra hamna på den svarta listan.
Föreställ dig en applikation skriven i PHP där användare kan ladda upp en profilbild. Du skulle anta att denna funktion endast tillåter bildfiler (JPG & PNG) att laddas upp. Men om andra filformat också tillåts kan det innebära en stor säkerhetsrisk. Eftersom PHP kan interagera direkt med operativsystemet, kan en angripare ladda upp en skadlig PHP-fil som ger direkt åtkomst till serverns filsystem. Detta kan leda till allvarliga konsekvenser, såsom informationsläckor och vidare intrång i nätverket.
Detta problem uppstår när korrekta behörighetskontroller inte appliceras på hela webbplatsens struktur. Det kan leda till att en användare får åtkomst till information som dennes behörigheter egentligen inte tillåter, eller till och med helt utan autentisering.
Föreställ dig att du använder ett tidsrapporteringssystem med ett lågprivilegierat konto. Det enda som hindrar dig från att godkänna din egen tidrapport är rent kosmetiskt – knappen för godkännande är dold för ditt konto och synlig endast för administratörer. Men om du känner till det korrekta begärandedatat, skulle du ändå kunna godkänna rapporten själv.
I samma applikation har ditt företag lagrat interna dokument med känslig information. Om du laddar ner ett dokument efter att ha loggat in är det normalt, men om du loggar ut och fortfarande kan komma åt samma dokument genom dess URL, är det ett tydligt bevis på bristande åtkomstkontroller.
Platta användar- och grupprättigheter. Det vore trevligt att leva i en värld där alla är lika, men när det gäller IT är detta en absolut "no-go" – trots att det fortfarande är mycket vanligt. Alla konton i en applikation eller ett nätverk har samma behörigheter, vilket leder till kaos, särskilt om dessa inloggningsuppgifter skulle hamna i händerna på en angripare. Det är i princip som att ge angriparen nycklarna till kungariket, vilket ofta kallas "en dålig idé".
Frågan man bör ställa är: Behöver Janice från ekonomi verkligen tillgång till de topphemliga dokumenten som är avsedda för Leann och Kurt? Användarroller bör alltid tilldelas enligt principen om minsta privilegium – det du inte behöver veta, ska du helt enkelt inte ha tillgång till.
Ett utmärkt exempel på detta problem är WannaCry/EternalBlue-utbrottet den 12 maj 2017. Infrastruktur över hela världen drabbades av denna sårbarhet, och företag i alla storlekar fick sina servrar och datorer infekterade med en krypteringsskadlig kod. Enligt IBM X-Force rapporterades de totala skadorna uppgå till över 8 miljarder dollar i 150 länder – enbart från WannaCry-incidenten.
Detta talar för sig själv – om du hanterar din egen data och dina egna servrar, har du full kontroll över när och vad som ska patchas. Men om du använder en tredjepartsleverantör har du ingen aning om deras åtgärder och rutiner. Därför är det en viktig fråga att ställa till alla tredjepartsleverantörer du överväger att anlita.
Vi har vid flera tillfällen fått höra att nätverket eller databasen är korrekt segmenterad – åtminstone enligt de personer vi pratat med. När vi senare följt upp saken har vi dock kunnat bevisa att så inte är fallet. I vissa fall har vi sett applikationer där både pre-produktions- och produktionsversioner lagras på samma server som den "korrekt segmenterade" databasen. Den faktiska segmenteringen visade sig endast bestå av två separata grenar inom samma databas.
Detta innebar att en SQL-injektion i pre-produktionsapplikationen ledde till fullständig kompromettering av produktionsdatabasen. Liknande brister har även identifierats i multi-tenant-system där flera företags data lagras i en och samma databas.