Virkningen av SQL-injeksjon
SQL-injeksjon (SQLi) lar en angriper forstyrre spørringene som en applikasjon gjør til databasen [S1]. Den primære konsekvensen inkluderer uautorisert tilgang til sensitive data som brukerpassord, kredittkortdetaljer og personlig informasjon [S1].
Utover datatyveri kan angripere ofte endre eller slette databaseposter, noe som fører til vedvarende endringer i applikasjonsatferd eller tap av data [S1]. I alvorlige tilfeller kan SQLi eskaleres for å kompromittere back-end-infrastrukturen, muliggjøre tjenestenektangrep eller gi en vedvarende bakdør inn i organisasjonens systemer [S1][S2].
Grunnårsak: Usikker inngangshåndtering
Grunnårsaken til SQL-injeksjon er feil nøytralisering av spesialelementer som brukes i en SQL-kommando [S2]. Dette skjer når en applikasjon konstruerer SQL-spørringer ved å sette sammen eksternt påvirket input direkte i spørringsstrengen [S1][S2].
Fordi inndata ikke er riktig isolert fra spørringsstrukturen, kan databasetolkeren kjøre deler av brukerinndata som SQL-kode i stedet for å behandle det som bokstavelige data [S2]. Dette sikkerhetsproblemet kan manifestere seg i ulike deler av en spørring, inkludert SELECT-setninger, INSERT-verdier eller UPDATE-setninger [S1].
Betongrettinger og reduksjoner
Bruk parametriserte spørringer
Den mest effektive måten å forhindre SQL-injeksjon på er bruken av parameteriserte spørringer, også kjent som forberedte setninger [S1]. I stedet for å sette sammen strenger, bør utviklere bruke strukturerte mekanismer som fremtvinger separering av data og kode [S2].
Prinsippet om minst privilegium
Applikasjoner bør koble til databasen med de laveste rettighetene som kreves for oppgavene deres [S2]. En nettapplikasjonskonto skal ikke ha administrative rettigheter og bør begrenses til de spesifikke tabellene eller operasjonene som er nødvendige for funksjonen [S2].
Inndatavalidering og koding
Selv om det ikke er en erstatning for parameterisering, gir inndatavalidering et dybdeforsvar [S2]. Applikasjoner bør bruke en akseptert-kjent-god strategi, som validerer at input samsvarer med forventede typer, lengder og formater [S2].
Hvordan FixVibe tester for det
FixVibe dekker allerede SQL-injeksjon gjennom den gatede active.sqli-skannermodulen. Aktive skanninger kjøres bare etter bekreftelse og attestering av domeneeierskap. Sjekken gjennomsøker GET-endepunkter med samme opprinnelse med spørringsparametere, etablerer et grunnlinjesvar, ser etter SQL-spesifikke boolske anomalier og rapporterer bare et funn etter bekreftelse av timing over flere forsinkelseslengder. Lagringsskanninger hjelper også med å fange opp årsaken tidligere gjennom code.web-app-risk-checklist-backfill, som flagger rå SQL-kall bygget med malinterpolasjon.