Impact van SQL-injectie
Met SQL-injectie (SQLi) kan een aanvaller zich bemoeien met de zoekopdrachten die een applicatie doet in de database [S1]. De primaire impact omvat ongeautoriseerde toegang tot gevoelige gegevens zoals gebruikerswachtwoorden, creditcardgegevens en persoonlijke informatie [S1].
Naast gegevensdiefstal kunnen aanvallers vaak databaserecords wijzigen of verwijderen, wat leidt tot blijvende veranderingen in het gedrag van applicaties of gegevensverlies. In zeer ernstige gevallen kan SQLi worden geëscaleerd om de back-endinfrastructuur in gevaar te brengen, denial-of-service-aanvallen mogelijk te maken of een permanente achterdeur te bieden naar de systemen van de organisatie.
Hoofdoorzaak: onveilige invoerverwerking
De hoofdoorzaak van SQL-injectie is de onjuiste neutralisatie van speciale elementen die worden gebruikt in een SQL-opdracht [S2]. Dit gebeurt wanneer een toepassing SQL-query's samenstelt door extern beïnvloede invoer rechtstreeks samen te voegen in de queryreeks [S1][S2].
Omdat de invoer niet goed is geïsoleerd van de querystructuur, kan de databaseinterpreter delen van de gebruikersinvoer uitvoeren als SQL-code in plaats van deze te behandelen als letterlijke gegevens [S2]. Dit beveiligingslek kan zich manifesteren in verschillende delen van een query, waaronder SELECT-instructies, INSERT-waarden of UPDATE-instructies [S1].
Concrete oplossingen en oplossingen
Gebruik geparametriseerde zoekopdrachten
De meest effectieve manier om SQL-injectie te voorkomen is het gebruik van geparametriseerde queries, ook bekend als voorbereide instructies [S1]. In plaats van tekenreeksen aan elkaar te koppelen, moeten ontwikkelaars gestructureerde mechanismen gebruiken die de scheiding van gegevens en code [S2] afdwingen.
Principe van de minste privileges
Applicaties moeten verbinding maken met de database met de laagste rechten die vereist zijn voor hun taken [S2]. Een webapplicatie-account mag geen beheerdersrechten hebben en moet beperkt zijn tot de specifieke tabellen of bewerkingen die nodig zijn voor zijn functie [S2].
Invoervalidatie en codering
Hoewel het geen vervanging is voor parametrering, biedt invoervalidatie diepgaande verdediging [S2]. Toepassingen moeten een acceptatie-bekend-goed-strategie gebruiken, waarbij wordt gevalideerd dat de invoer overeenkomt met de verwachte typen, lengtes en formaten [S2].
Hoe FixVibe erop test
FixVibe dekt al SQL-injectie via de gated active.sqli-scannermodule. Actieve scans worden alleen uitgevoerd na verificatie en attestering van het domeineigendom. De controle doorzoekt GET-eindpunten van dezelfde oorsprong met queryparameters, stelt een basislijnreactie vast, zoekt naar SQL-specifieke Booleaanse afwijkingen en rapporteert alleen een bevinding na timingbevestiging over meerdere vertragingslengtes. Repositoryscans helpen ook om de hoofdoorzaak eerder te achterhalen via code.web-app-risk-checklist-backfill, dat onbewerkte SQL-aanroepen markeert die zijn gebouwd met sjablooninterpolatie.