Testing for SQL Injection Vulnerabilities

SQL-injeksjonsangrep utgjør enorme farer for webapplikasjoner som er avhengig av en databasebygging for å generere dynamisk innhold. I denne typen angrep manipulerer hackere et webprogram i et forsøk på å injisere sine egne SQL-kommandoer i de som er utgitt av databasen. For eksempel, se artikkelen SQL Injection Attacks på databaser. I denne artikkelen tar vi en titt på flere måter du kan teste webapplikasjonene dine for å avgjøre om de er sårbare for SQL-injeksjonsangrep.

Automatisert SQL Injeksjonsskanning

En mulighet er å bruke en automatisert sårbarhetsskanner for webprogrammer, som HPs WebInspect, IBMs AppScan eller Cenzic's Hailstorm. Disse verktøyene tilbyr alle enkle, automatiserte måter å analysere webapplikasjonene på for mulige SQL-injeksjonsproblemer. Men de er ganske dyre, kjører opp til $ 25 000 per sete.

Manuelle SQL Injeksjonstester

Hva er en dårlig programutvikler å gjøre? Du kan faktisk kjøre noen grunnleggende tester for å evaluere webapplikasjonene dine for SQL Injection-sårbarheter, bruk ikke noe mer enn en nettleser. For det første, et forsiktig ord: de tester vi beskriver, ser bare etter grunnleggende SQL-injeksjonsfeil. De vil ikke oppdage avanserte teknikker og er noe kjedelig å bruke. Hvis du har råd til det, gå med en automatisert skanner. Men hvis du ikke klarer å håndtere denne prislappen, er manuell testing et godt første skritt.Den enkleste måten å vurdere om et program er sårbart, er å eksperimentere med uskadelige injeksjonsangrep som ikke vil skade databasen din hvis de lykkes, men vil gi deg bevis for at du må rette et problem. For eksempel, anta at du hadde et enkelt webprogram som ser opp et individ i en database og gir kontaktinformasjon som et resultat. Den siden kan bruke følgende URL-format:

http://myfakewebsite.com/directory.asp?lastname=chapple&firstname=mike

Vi kan anta at denne siden utfører en databaseoppslag, ved hjelp av en spørring som ligner på følgende:

VELG telefon

FRA katalogen

Hvor etternavn = 'chapple' og fornavn = 'mike'

La oss eksperimentere med dette litt. Med vår antagelse ovenfor kan vi gjøre en enkel endring til nettadressen som tester for SQL-injeksjon angrep:

http://myfakewebsite.com/directory.asp?lastname=chapple&firstname=mike'+AND+(select+count(*)+from+fake)+%3e0+OR+'1'%3d'1

Hvis webapplikasjonen ikke er riktig beskyttet mot SQL-injeksjon, kobler den ganske enkelt dette falske fornavnet til SQL-setningen som utføres mot databasen, noe som resulterer i:

VELG telefon

FRA katalogen

Hvor etternavn = 'chapple' og fornavn = 'mike'

OG (velg telle (*) fra falsk)> 0

ELLER '1' = '1'

Du vil legge merke til at syntaksen ovenfor er litt annerledes enn den i den opprinnelige nettadressen. Vi tok friheten til å konvertere URL-kodet variabel for sine ASCII-ekvivalenter for å gjøre det lettere å følge eksemplet. For eksempel er% 3d URL-kodingen for '=' tegnet. Vi har også lagt til noen linjeskift for lignende formål.

Evaluering av resultatene

Testen kommer når du prøver å laste inn nettsiden med nettadressen som er oppført ovenfor. Hvis webapplikasjonen er friskoppført, vil den fjerne de enkelte sitatene fra inngangen før de sender forespørselen til databasen. Dette vil ganske enkelt resultere i et merkelig oppslag for noen med et fornavn som inneholder en haug med SQL. Du får se en feilmelding fra programmet som ligner på den nedenfor:

Feil: Ingen bruker funnet med navn mike + AND + (velg + telle (*) + fra + falsk) +% 3e0 + OR + 1% 3d1

Chapple!

På den annen side, hvis søknaden er sårbar for SQL-injeksjon, vil den passere setningen direkte til databasen, noe som resulterer i en av to muligheter. For det første, hvis serveren din har detaljerte feilmeldinger aktivert (som du ikke bør), ser du noe slikt:

Microsoft OLE DB Provider for ODBC-drivere feil '80040e37'

Microsoft ODBC SQL Server Driver SQL Server Ugyldig objektnavn "falsk".

/directory.asp, linje 13

På den annen side, hvis webserveren ikke viser detaljerte feilmeldinger, får du en mer generisk feil, for eksempel:

intern server feilServeren oppstod en intern feil eller feilkonfigurasjon og kunne ikke fullføre forespørselen din.

Ta kontakt med serveradministratoren for å informere om tidspunktet feilen oppstod, og om alt du kanskje har gjort som kan ha forårsaket feilen.

Mer informasjon om denne feilen kan være tilgjengelig i serverfeilloggen.

Hvis du mottar en av de to feilene ovenfor, er søknaden din sårbar for SQL-injeksjonsangrep. Noen trinn som du kan ta for å beskytte dine applikasjoner mot SQL Injection-angrep, er:

• Implementer parameterkontroll på alle applikasjoner. Hvis du for eksempel spør noen om å legge inn et kundenummer, må du kontrollere at inngangen er numerisk før du utfører spørringen.
• Begrens tillatelsene til kontoen som kjører SQL-spørringer. Regelen med minst privilegium gjelder. Hvis kontoen som brukes til å utføre spørringen, ikke har tillatelse til å utføre den, vil den ikke lykkes.
• Bruk lagrede prosedyrer (eller lignende teknikker) for å hindre brukere i å interagere direkte med SQL-koden.