De flesta produkter du köper är inriktade på nätverks- och slutpunktssäkerhet. Dessa är inte särskilt effektiva mot sårbarheter i webbapplikationer. I det här inlägget belyser vi därför de vanligaste problemen vi stöter på i vårt arbete, allt från svaga nätverk till användaruppräkning. Att förstå dessa utmaningar är inte bara viktigt för IT-proffs, utan även för privatpersoner och organisationer som strävar efter att förbättra sin säkerhet i en alltmer sammankopplad värld.
När man använder en applikation är en av de första sakerna man stöter på någon form av autentisering. Detta sker vanligtvis genom en kombination av användarnamn och lösenord. Och naturligtvis varierar kraven kraftigt från webbplats till webbplats. Det är ganska vanligt med krav på både stora och små bokstäver, kanske även några siffror och specialtecken. Längden är också en viktig faktor. En bra riktlinje är att se till att lösenordet är tillräckligt långt för att förhindra brute force-attacker och tillräckligt komplext för att det inte ska finnas i en ordbok. En bra, rekommenderad längd är minst 10 tecken. Helst betydligt fler.
Vi har stött på många applikationer där det enda kravet var en längd på sex tecken. Ett lösenord som ”111111” skulle alltså vara helt acceptabelt. Det skulle ta till och med en lågprisdator mycket kort tid att knäcka en hash av detta lösenord. För att inte tala om att det förmodligen finns i en ordbok, vilket innebär att brute force-attacker också skulle vara fullt möjliga. Mer information om hur lösenord knäcks finns här.
Ett smidigt verktyg för att utvärdera det aktuella läget för SSL-implementeringen,SSLLabs, är snabbt, lättanvänt och omfattande. Det finns också verktygetSSLChecker, en mer förenklad version som är lättare att förstå för den som inte är tekniskt insatt. Det erbjuder dessutom den extra funktionen att kontrollera SSL-säkerhetsrubriker. Vi kommer nu inte att gå in på alla detaljer kring SSL/TLS-implementeringen, det skulle kräva åtminstone flera sidor till i det här inlägget. Därför får vi återkomma med ett separat inlägg om detta. Om du verkligen vill veta mer redan nu finns det ett annat smidigt verktyg. De kallar det Google; vi tror att det börjar bli populärt!Ellersåär du välkommen att kontaktaoss så ser vi till att du får rätt information.
Det finns flera vanliga sätt som applikationer låter dig räkna upp giltiga användare på. Ett av de vanligaste och enklaste sätten är via inloggningsfunktionen. Ett exempel: Du ska logga in på en applikation. Om du skriver in rätt användarnamn men anger fel lösenord, och svaret lyder ”lösenordet är felaktigt”. Detta är en ledtråd om att användaren är en giltig användare. Om du provar ett annat användarnamn (som inte är giltigt) och svaret lyder ”Ingen giltig användare”, kan du nu enkelt fastställa att den första användaren faktiskt var en giltig användare.
För en angripare skulle detta vara ett bra tillfälle att försöka använda brute force-metoden mot applikationens användare. Eftersom applikationen svarar och informerar dig om användaren är giltig eller inte.
Det största problemet under 2017 och 2018 har varit olika typer av injektioner. Så, vad kan injiceras? SQL-frågor, operativsystemskommandon, HTML-innehåll, hela sidor med innehåll och skript. Var skulle någon kunna injicera detta? Överallt där användarinmatning krävs, eller där användare kan ändra data, t.ex. i textrutor, fält för användarnamn/lösenord, sökfunktioner, fält för feedback och kommentarer, URL:er osv…
Uppladdade filer kan få allvarliga konsekvenser för både applikationen och filsystemet. Det är vanligt att det saknas filter för vilka filändelser som får laddas upp. Om endast en eller två filtyper behövs bör alla andra finnas på svartlistan.
Tänk dig en applikation skriven i PHP, där användaren kan ladda upp en profilbild. Man skulle förvänta sig att denna funktion endast tillåter uppladdning av bildfiler (JPG och PNG). Men även andra filformat tillåts laddas upp. Eftersom vi i det här fallet har att göra med PHP (och PHP kan interagera direkt med operativsystemet) laddar vi upp lite rolig PHP-kod som ger oss direkt tillgång till serverns eget filsystem. Detta kan i stort sett leda till ännu mer fantastiska saker, såsom informationsläckor och eventuellt att man tar sig längre in i nätverket.
Detta inträffar när korrekta kontroller inte utförs för hela webbplatsens struktur. Detta gör det möjligt för en användare att få tillgång till information som deras behörighet egentligen inte tillåter (eller helt utan autentisering). Tänk dig att du bläddrar i din tidsrapporteringsapplikation med ditt konto med låga behörigheter; det enda som hindrar dig från att godkänna din egen tidsrapport är i princip kosmetiska åtgärder. Godkännandeknappen är inte synlig för ditt konto, utan endast för applikationens administratörer. Men i själva verket, om du kände till begärandedata, skulle du kunna godkänna tidsrapporten själv.
I den här applikationen har du och ditt företag lagrat vissa interna dokument som kan beskrivas som innehållande känslig information. Du öppnar en av PDF-filerna och laddar ner den, efter att ha autentiserats. Om du skulle logga ut från applikationen och sedan öppna samma URL för det dokumentet, och filen är tillgänglig, skulle det återigen vara ett bevis på bristfälliga åtkomstkontroller.
Enhetliga behörigheter för användare och grupper. Det vore trevligt att leva i en värld där alla är jämlika. Men när det gäller IT är detta absolut otänkbart, trots att det fortfarande är mycket vanligt. Alla konton till en applikation eller ett nätverk har samma behörigheter, vilket leder till kaos, särskilt om dessa inloggningsuppgifter skulle komprometteras av en angripare. Det är mer eller mindre som att ge angriparen nycklarna till kungariket och kallas oftast för ”en dålig idé”. Frågan man måste ställa sig här är: Behöver Janice från ekonomiavdelningen verkligen tillgång till de topphemliga dokumenten som är avsedda för Leann och Kurt? Användarroller bör tilldelas enligt principen om minsta möjliga behörighet – det du inte behöver veta ska du helt enkelt inte veta eller ha tillgång till.
Ett utmärkt exempel på detta problem är utbrottet av WannaCry/EternalBlue den 12 maj 2017. Infrastruktur över hela världen drabbades av denna sårbarhet, och företag av olika storlek fick sina servrar och datorer infekterade med en krypteringsmalware. Den totala skadan uppgick enligtIBM X-Forcetill över 8 miljarder dollar i 150 länder, enbart från WannaCry-incidenten. Jag tror att detta talar för sig själv: om du själv sköter dina data och servrar kan du styra när och vilka uppdateringar som ska installeras. Med en extern leverantör har du ingen aning om vad de gör. Därför är detta en viktig fråga att ställa till alla externa leverantörer som du överväger att anlita.
Vi har stött på fall där vi har fått höra att nätverket eller databasen är korrekt segmenterad, åtminstone enligt de personer vi har pratat med. När vi återkommer till dem en stund senare har vi kunnat bevisa att så inte är fallet. Applikationer där pre-produktionsversionen och produktionsversionen lagras på samma server som den ”korrekt segmenterade” databasen. Den faktiska segmenteringen av databasen bestod i själva verket endast av att det fanns två separata grenar i samma databas. Detta innebar att den SQL-injektion som upptäcktes i pre-produktionsapplikationen också ledde till att produktionsdatabasen komprometterades fullständigt. Detta har även observerats i system med flera hyresgäster, där flera företags data lagras i samma databas.