Jag ser SQL injection som en praktisk säkerhetsfråga där tekniken behöver kunna verifieras, inte bara beskrivas. SQL injection förebyggs främst genom att hålla SQL-kod och data separerade; parametriserade queries ska vara normalfallet, inte en specialåtgärd efter ett fynd.
SQL injection i praktiken
Första byggstenen: Prepared statements binder värden utan att tolka dem som SQL-syntax. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
En annan viktig del: Allow-list behövs fortfarande för dynamiska kolumnnamn eller sorteringsfält som inte kan parametriseras som värden. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det tekniska ankaret: Databaskontot bör ha minsta nödvändiga behörighet. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det som ofta avgör kvaliteten: Felmeddelanden ska inte läcka query eller schema till klienten. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Ett arbetsflöde jag skulle använda
- Identifiera alla vägar där input når databasen.
- Ersätt strängkonkatenering med parametrar.
- Allow-lista dynamiska strukturelement.
- Begränsa applikationskontots rättigheter.
- Lägg negativa tester i integrationstest.
För SQL injection håller jag därför införandet i små steg. Då går det att skilja ett säkerhetsproblem från ett rent driftfel och att rulla tillbaka just den ändring som gav ett oväntat resultat.
Ett konkret scenario
Om ett sökfält förväntar sig ett namn ska värdet bindas som parameter. Sorteringsfältet kan däremot behöva väljas från en fast lista eftersom SQL-motorn inte kan parameterisera ett kolumnnamn på samma sätt.
Vanliga sätt att göra kontrollen svagare
- Att försöka escape:a input manuellt.
- Att tro att ORM automatiskt gör råa SQL-fragment säkra.
- Att köra applikationen med databasadministratörsrättigheter.
Vad som måste gå att bevisa
För SQL injection vill jag avsluta med mätbara efterkontroller i stället för att nöja mig med att en statusruta visar ”enabled”. De viktigaste kontrollerna här är:
- Apostrof och SQL-metatecken behandlas som data.
- Lägre privilegierat db-konto kan inte ändra schema.
- Felvägar avslöjar inte intern query.
Ett negativt test hör också till SQL injection: den väg, identitet eller operation som inte ska vara tillåten ska misslyckas på ett förutsägbart sätt. Då kan nästa tekniker upprepa kontrollen och förstå både avsikten och gränsen.
Slutsats
SQL injection – varför parametriserade frågor fortfarande är grundskyddet handlar därför inte om att samla fler säkerhetsinställningar. Det handlar om att minska en konkret risk med en kontroll som har tydligt scope, tydlig ägare och ett verifierbart resultat. När före-läge, förändring och eftertest dokumenteras blir säkerhetsarbetet både säkrare och lättare att förvalta.