Efter den senaste tidens våg av uppmärksammade IT-säkerhetsattacker, som de mot Colonial Pipeline och Coop, kan det verka som om IT-team agerar lite tafatt när det gäller slutpunktssäkerheten.
Bland utvecklare är det dock allmänt känt att uppkomsten av säkerhetsbrister är ett vidare problem.
Om kod skrivs på fel sätt eller med bristfällig säkerhet så har du med största sannolikhet bäddat för framtida webbattacker.
Sårbarheter i webbapplikationer är något som kan drabba alla, till och med de allra största och mest avancerade teknik- och innovationsföretagen. Fråga bara Tesla som hade en sårbarhet i en tillvalsfunktion 2014, Fortnite som 2019 utsatte 80 miljoner användares information för risk, eller Apple som i förebyggande syfte har betalat 300 000 USD till säkerhetsforskare för att identifiera och flagga brister i deras webbapplikationer.
Sårbarheter i webbapplikationer kan ha sitt ursprung i flera olika typer av kodningsproblem, men exemplen ovan är av en väldigt specifik typ – SQL-injektioner.
Ett zero-trust-tillvägagångssätt
SQL-injektioner är en av de vanligaste och farligaste sårbarheterna. Tack och lov finns det ett antal beprövade metoder som utvecklare kan ta till för att förhindra kryphål i skyddsmuren för SQL-injektioner.
Den första är att se till att inputvalideringen på klientsidan inte är den enda försvarslinjen. Denna validering är ett utmärkt sätt för att förbättra användarupplevelsen, men fungerar tyvärr inte som en säkerhetsmekanism. Det är enkelt att ta bort valideringen på klientsidan genom att ändra javascriptet som laddas i webbläsaren eller göra ett grundläggande HTTP-anrop till backend i en klient-serverarkitektur med en parameter som kan orsaka en SQL-injektion. Utvecklare bör hantera allt som kommer från en klient som potentiellt skadligt och bör därför hantera valideringen på serversidan, helst så nära källan som möjligt.
Utvecklare bör också vara noggranna med privilegierna för databasanvändare. Alla SQL-injektionsattacker är skadliga, men vissa är mer skadliga än andra. Att komma åt användarinformation är en sak, men att ändra eller ta bort den är något helt annat.
För att minimera konsekvenserna av en SQL-injektion bör utvecklare hantera en applikations databasprivilegier på ett strategiskt sätt. Behöver en applikation verkligen kunna läsa, skriva och uppdatera alla databaser? Är det nödvändigt för att den ska kunna trunkera eller droppa tabeller?
Det också oklokt att ha en enda databasanvändare för en applikation. Att skapa flera databasanvändare och med specifika uppgifter eller roller i applikationen fungerar ungefär på samma sätt som en branddörr som begränsar en eldsvåda, nämligen att förhindra att en attack snabbt tar över hela databasen.
Parametrar är det bästa försvaret
För att öka säkerheten bör utvecklare använda prepared statements och frågeparameterisering. Många språk har inbyggda funktioner som hjälper till att förhindra SQL-injektioner, så när du skriver SQL-frågor kan du använda ett prepared statement för att kompilera frågan.
Prepared statements kan användas för att utföra frågeparameterisering, något som begränsar de SQL-satser som kan matas in. När du använder ett bra prepared statement och parameteriserade frågor kommer databasen först att bygga frågeexekveringsplanen baserad på frågesträngen med platshållare och sen skicka (de icke tillförlitliga) parametrarna till databasen. Eftersom frågeplanen redan har skapats påverkar inte parametrarna detta längre, vilket helt blockerar injektion. Prepared statements med frågeparameterisering är därför det bästa försvaret mot SQL-injektioner.
Parameterisering är också avgörande när man arbetar med sparade procedurer. Många tror att det är ett bra sätt att förhindra SQL-injektioner, men så är det inte alltid. Precis som alla SQL-frågor som skapas i en applikation kan en sparad procedur injiceras på ett skadligt sätt. Därför bör utvecklare, precis som med SQL-frågor, parameterisera frågorna i sitt sparade förfarande, snarare än att länka ihop parametrarna för att skydda mot injektion.
Brian Vermeer, Developer Advocate på Snyk
I vissa lägen finns det inga prepared statements. Språket kanske inte stöder det eller så tillåter inte äldre databaser utvecklare att ange användarinput som parametrar. Då är inputvalidering ett alternativ. Utvecklare bör se till att inmatningsvalideringen är beroende av tillåtelselistor och inte blockeringslistor. Naturligtvis är inputvalidering alltid nödvändig, även om förberedda satser finns tillgängliga.
Säkerhet i flera lager
Utöver parameterisering och inputvalidering bör utvecklare använda ett ORM-lager (Object-Relational Mapping) för att skydda mot injektioner. Det kan omvandla data från en databas till objekt och vice versa, vilket minskar specifika SQL-frågor och därmed också riskerna för SQL-injektionsattacker. Det bör dock noteras att sårbarheter fortfarande kan skapas inom ORM-biblioteket om fel eller föråldrade versioner av ”sequelize” och ”hibernate” används.
I slutändan, oavsett vilka säkerhetsstrategier som används, måste ett strikt granskningssystem finnas för att kontrollera kod och flagga eventuella sårbarheter. Kodgranskning och parprogrammering möjliggör detta, men manuella granskningsprocesser är inte vattentäta. För att uppnå de högsta säkerhetsnivåerna bör utvecklare använda specialdesignade skanningsverktyg som med automatik letar efter sårbarheter och svagheter i koden.
SQL -injektionsattacker är ett allvarligt hot, men det går att skydda sig. När cyberbrottsligheten ökar är det viktigare än någonsin att utvecklare kodar in säkerheten i hjärtat av applikationen.
Brian Vermeer, Developer Advocate på Snyk
