Effekten av SQL-injektion
SQL-injektion (SQLi) tillåter en angripare att störa de frågor som ett program gör till sin databas [S1]. Den primära effekten inkluderar obehörig åtkomst till känsliga uppgifter som användarlösenord, kreditkortsuppgifter och personlig information [S1].
Utöver datastöld kan angripare ofta ändra eller ta bort databasposter, vilket leder till bestående förändringar i programbeteende eller dataförlust [S1]. I allvarliga fall kan SQLi eskaleras för att äventyra back-end-infrastrukturen, möjliggöra överbelastningsattacker eller tillhandahålla en ihållande bakdörr till organisationens system [S1][S2].
Rotorsak: Osäker indatahantering
Grundorsaken till SQL-injektion är felaktig neutralisering av specialelement som används i ett SQL-kommando [S2]. Detta inträffar när en applikation konstruerar SQL-frågor genom att sammanfoga externt påverkad indata direkt i frågesträngen [S1][S2].
Eftersom indata inte är ordentligt isolerad från frågestrukturen kan databastolkaren köra delar av användarinmatningen som SQL-kod istället för att behandla den som bokstavlig data [S2]. Denna sårbarhet kan manifestera sig i olika delar av en fråga, inklusive SELECT-satser, INSERT-värden eller UPDATE-satser [S1].
Betongfixar och begränsningar
Använd parametriserade frågor
Det mest effektiva sättet att förhindra SQL-injektion är att använda parametriserade frågor, även kända som preparerade satser [S1]. Istället för att sammanfoga strängar bör utvecklare använda strukturerade mekanismer som tvingar fram separationen av data och kod [S2].
Principen om minsta privilegium
Applikationer bör ansluta till databasen med de lägsta privilegier som krävs för sina uppgifter [S2]. Ett webbapplikationskonto bör inte ha administrativa rättigheter och bör begränsas till de specifika tabeller eller operationer som krävs för dess funktion [S2].
Ingångsvalidering och kodning
Även om det inte ersätter parametrering, ger indatavalidering ett försvar på djupet [S2]. Applikationer bör använda en strategi som är godkänd och som validerar att indata matchar förväntade typer, längder och format [S2].
Hur FixVibe testar det
FixVibe täcker redan SQL-injektion genom den gated active.sqli skannermodulen. Aktiva skanningar körs endast efter verifiering och bestyrkande av domänägande. Kontrollen genomsöker GET-slutpunkter med samma ursprung med frågeparametrar, upprättar ett baslinjesvar, letar efter SQL-specifika booleska anomalier och rapporterar endast ett fynd efter timingbekräftelse över flera fördröjningslängder. Förvarsskanningar hjälper också till att fånga grundorsaken tidigare genom code.web-app-risk-checklist-backfill, som flaggar råa SQL-anrop byggda med mallinterpolation.