SQL-injeksjon angrep. Spesielt er sårbarheten som finnes i det faktum at brukerundersøkelser brukes til direkte bygge SQLstatement i praksis gjør det mulig for en angriper å kontrollere uttalelse henrettet.
Et eksempel på sårbarheten ville være hvis følgende strengen ble inngått brukernavn /passord-feltene: 'eller' '='. SQL-setningen vil da bli utført som:
SELECT * FROM tblUsers WHERE brukernavn = '' eller '' = '' og passord = '' eller '' = ''
Dette søket vil returnere alle poster fra tblUsers, og scriptet vil fortsette å logge brukeren inn som den første brukeren identifiseres ved første post i tabellen.
En annen variant av SQL-injeksjon angrep eksisterer når du mottar QueryString parametre for å generere dynamiske sider. Nedenfor er et eksempel på en ASP-side som aksepterer en ID gjennom spørrestrengen, og dynamisk genererer sidens innhold basert på ID:
<%
Dim p_lngID, objRS, strSQL
p_lngID = Request ("ID")
strSQL = "SELECT * FROM tblArticles WHERE ID =" &p_lngID
Sett objRS = Server.CreateObject ("ADODB.Recordset")
objRS.Open strSQL, "DSN = ..."
Hvis (Ikke objRS.EOF) Deretter Response.Write objRS ("ArticleContent")
Sett objRS = Nothing
%>
Under normale omstendigheter, dette skriptet vil vise innholdet i artikkelen hvis ID ble vedtatt som en spørrestrengen parameter. For eksempel kan siden bli kalt som: http://www.example.com/Article[dot]asp?ID=1055, og dermed viser det dynamiske innholdet for artikkelen 1055.
Som vår innlogging eksempel denne koden åpner seg for en SQL-injeksjon angrep. En ondsinnet bruker kan erstatte gyldig Artikkel-ID for en uautorisert SQL kommando ved å føre inn i ID noe sånt som: 0 eller 1 = 1 (dvs. http:? //www.example [Dot] com /Article.asp ID = 0 eller 1 = 1).
SQL-spørringen vil returnere alle artikler fra bordet for det ville bli henrettet som:
SELECT * FROM tblArticles WHERE ID = 0 eller 1 = 1
Selvfølgelig, dette eksempelet er kanskje ikke synes å være svært farlig, men angriperen vil da være i stand til å manipulere programmet enda mer ved å sette inn ondsinnede kommandoer, for eksempel DELETE uttalelser. Alt dette kan gjøres ganske enkelt ved å manipulere spørrestrengen! For eksempel kan noen kaller den siden ved hjelp av en spørrestrengen som: http:? //www.example [Dot] com /Article.asp ID = 1055; DELETE FROM tblArticles.
Konsekvenser av SQL Injection
De fulle implikasjonene av dette sikkerhetsproblemet varierer sterkt basert på miljø og konfigurasjon. Hvis databasen tilkoblingen bruker sikkerhetskonteksten dbo, er det mulig å slippe alle tabeller i databasen, opprette nye tabeller, etc. Hvis databasen tilkoblingen bruker sikkerhetskonteksten sa, er det mulig å styre hele SQL Server, og under høyre konfigurasjon med opprette brukerkontoer for å ta kontroll over Windows server hosting databasen.
Beskytte Søknader fra SQL Injection
Det første du må gjøre er å beskytte SQL-spørringer ved å implementere sanitization teknikker for alle innspill data fra de ASP forespørsel objekt (Request, Request.QueryString, Request.Form , Request.Cookies og Request.ServerVariables). Dine sanitization rutiner vil variere basert på dine DBMS, men eksempler for MS SQL Server er gitt nedenfor.
På innloggingssiden eksempel manuset var ventet to variabler (txtUserName, txtPassword) av typen string å bli vedtatt. Når en enkelt sitat er satt inn i en parameter, gir det brukeren å manipulere kommandoen blir utført. For å bekjempe trusselen av SQL-injeksjon, unnslippe apostrof bruke Replace-funksjonen, som så:
p_strUsername = Erstatt (Request.Form ("txtUsername"), "" "," '' ")
p_strPassword = Erstatt (Request.Form ("txtPassword"), "" "," '' ")
I det andre eksemplet, ble manuset forventer en variabel (ID) av type lang heltall å bli vedtatt. Uautoriserte SQL-kommandoer kan utføres ved å føye SQL til ID-parameteren. For å bekjempe denne type SQL-injeksjon, bare begrense innspill til en lang heltall bruker CLng, som så:
p_lngID = CLng (Request ("ID"))
Hvis brukeren prøver å bestå i en streng, vil CLng funksjon genererer en feilmelding.
For ytterligere å redusere risikoen for SQL-injeksjon, sørg for å fjerne noen tekniske opplysninger fra klient levert feilmeldinger. Feilmeldinger ofte avsløre tekniske detaljer som kan gjøre det mulig for en angriper å avdekke sårbare inngangspunkter. Dette inkluderer eventuelle tilpassede meldinger søknaden din genererer samt IIS-generert feil. Du kan implementere dette ved å deaktivere detaljerte feilmeldinger i IIS og ved å skape ikke-tekniske definerte feilsider. (For mer informasjon om å opprette egendefinerte feilsider i IIS må du lese:. Lage Custom ASP feilsider)
Til slutt, for å begrense omfanget av en SQL-injeksjon angrep, begrense tillatelser gitt til databasen brukerkonto Web-programmet bruker. Søknaden generelt trenger ikke DBO eller sa tillatelser. Jo mindre gitt tillatelse til databasen, jo bedre! Vurder å bruke en egen konto for hver komponent med datatilgang evner å isolere sårbarheter. For eksempel, en front-end felles grensesnitt til ditt nettsted trenger mer begrenset DB tilgang enn en intern content management system.
