ASP: Filter for SQL injections

[Redak Tøren]

Jeg har skrevet disse to funksjonene, men lurer på om dem er holdbare for å forhindre injections i databasen?

 

'sRequest er navnet på query. Eks: "URL="

'strQuery, intQuery er verdien. Eks: "URL=12"

'ilen er standardverdien som skal erstatte input hvis input ikke er gyldig

 

Luke ut alt som ikke er tall:

Function filterRequest(sRequest,intQuery,ilen)

if Request.QueryString(intQuery) <> "" then

	sRequest = Request.QueryString(intQuery)

	if isNumeric(sRequest) then
		sRequest = CLng(sRequest)
	else
		sRequest = ilen	
	end if
else
	sRequest = ilen
end if
filterRequest = sRequest
end function

 

Luke ut alt som ikke er ønsket i tekststrengen:

 

Function filterTextRequest(sRequest,strQuery)

if Request.QueryString(strQuery) <> "" then
	sRequest = Request.QueryString(strQuery)
	sRequest = replace(sRequest, """",""") 'Stoppe HTML-koder og SQL-koder
	sRequest = replace(sRequest, "'","'") 'Stoppe SQL-koder
	sRequest = replace(sRequest, "<","<") 'Stoppe HTML-koder
	sRequest = replace(sRequest, ">",">") 'Stoppe HTML-koder
	sRequest = replace(sRequest, "&","&") 'Stoppe ASP-koder
	sRequest = replace(sRequest, "%","") 'Stoppe SQL-koder og ASP-koder
end if
filterTextRequest = sRequest
end function

 

Funksjonene kalles slik:

 

Dim intValue
intValue = filterRequest(intValue,"URL",0)

 

Dim strValue
strValue = filterTextRequest(strValue,"KEY","Ugydlig streng")

Endret 29. mai 2008 av atomtissetasen

[FrodeNilsen]

Begynner å bli litt sengetid nå, men dette klarer jeg ikke å la være å svare på.

 

Du kan jo konsekvent benytte xml til å lagre informasjon i databasen. Du kan jo utvide dette til numeriske entiteter for for eks. "%".

 

Nå benytter jeg MySql og har enda ikke fått på det rene hvordan den databasen håndterer numeriske entititeter som  & #160;

 

I henhold til xml definisjonen så er det ingen forskjell på en numerisk entitet og bokstaven/tegnet den representerer. Hvis SQL versjonen tålker xml på samme måte så nytter det ikke å erstatte tegn med deres numeriske entitet, uten om xml entitetene.

 

XML definerer apos, quot, amp, gt, og lt.(Fritt etter hukommelsen.)

 

Det å lagre som xml gir også store problemer med størrelsen på tekstfelt, da entitene er vesentlig lengre enn tegnet de representerer. De vil oppta vesentlig større plass enn ett tegn.

 

Frode

[Redak Tøren]

Ja, det tar større plass. Men å tillate tegnene <'%& osv gir langt større problemer siden jeg ikke kan programmering bedre enn at jeg putter variabelen direkte i SQL-setningen.

Muligens kan jeg lage et mer avansert filter som luker ut det som er direkte koder, men da blir filteret enormt og det vil sakke prosessen.

 

Finnes det funksjonsbiblioteker på nettet som har filter mot SQL injections?

[FrodeNilsen]

Ja, det tar større plass. Men å tillate tegnene <'%& osv gir langt større problemer siden jeg ikke kan programmering bedre enn at jeg putter variabelen direkte i SQL-setningen.

Muligens kan jeg lage et mer avansert filter som luker ut det som er direkte koder, men da blir filteret enormt og det vil sakke prosessen.

 

Finnes det funksjonsbiblioteker på nettet som har filter mot SQL injections?

 

Hvis databasen du benytter tillater bruk av numeriske entiteter og ikke tolker slike entiteter som tegnene de representerer, så er dette en rimelig god metode til å kverke det meste av injections. Du bare erstatter tegn som har funksjon i SQL.

 

Hvis du i tillegg erstatter stor og liten "r" og "e" blir det umulig å injisere: Drop, select, alter, update, like, user, table, og where. Listen er selvfølgelig lenger enn dette, men du tar sikkert tegninga.

 

Problemet er den økte og uoversiktelige lagringsmengden, så du vil ende opp med mye bolb. Dette vil gå utover ytelsen, men hvis databasen ikke er så stor så trenger ikke dette ha noen betydning.

 

Jeg har enda igjen å se noen injeksjon som kommer forbi en slik omskrivning.

 

Frode

[Redak Tøren]

Jeg har en veldig stor database og et omfattende system, men dagens filter belaster den ikke stort. Jeg opplevde dog en SQL injection hvor noen klarte å legge til <script src="http://banner32.com/et eller annet"></script> i starten og slutten på ekstremt mange felt (ca. 100.000 stykk), men tror jeg hadde et hull et sted uten filter. Bygger nytt system med konsekvente regler og semantikk. Det gamle systemet er bygd opp klattvis.

 

Leste en gang at noen klarer å omgå slike erstanings-filter. Kan det faktisk være mulig?

[kaffenils]

Den enkleste måten å beskytte seg mot SQL injections er å bruker parameteriserte spørringer.

 

Dette er FEIL:

sql="select * from artikler where artikkel_id=" & artikkelId

 

Dette er RIKTIG (ved bruk av ADO og klassisk ASP):

dim cmd
dim param
dim rs

set cmd=createobject("ADODB.Command")
set cmd.ActiveConnection=conn 'conn er et objekt av type ADODB.Connection
cmd.CommandType=1 '=adCmdText, klassisk ASP sucks
cmd.CommandText="select * from artikler where artikkel_id=?"
set param=cmd.CreateParameter(,3,1,,artikkelId) 'ASP S.U.C.K.S   3=adInteger, 1=adInputParam
cmd.Parameters.Add param
set rs=cmd.execute

' Les data fra rs

rs.close

 

Dette beskytter selvsagt ikke mot innsetting av HTML o.l. hvis du har en webside hvor input fra brukere skriver til databasen.

[Manfred]

parametriserte spørringer, parametriserte spørringer, parametriserte spørringer, parametriserte spørringer, parametriserte spørringer, parametriserte spørringer!

[FrodeNilsen]

parametriserte spørringer, parametriserte spørringer, parametriserte spørringer, parametriserte spørringer, parametriserte spørringer, parametriserte spørringer!

 

Jeg forstår at dette skal være nøkkelen, og dessverre kan jeg ikke ett ord ASP, så jeg forstod pent lite av den koden som er gitt over. Jeg skulle gjerne forstå poenget med parametriserte spørringer.

 

Jeg hadde satt stor pris på om du kunne kort forklare hva dette er for noe. Gode lenker som forklarer prinsippene i parametriserte spørringer blir tatt imot med stor takknemlighet.

 

Frode

Endret 30. mai 2008 av FrodeNilsen

[Redak Tøren]

Tusen takk for gode svar.

 

Nå har jeg god erfaring med de klaisske metodene, men parametriserte spørringer har jeg ikke vært borti før.

 

cmd.CommandText="select * from artikler where artikkel_id=?"

I den setningen her vil det altså være umulig å bryte opp og sette inn ny kode selv om jeg ikke filtrerer bort visse tegn fra variabelverdien?

 

? =;INSERT... bla bla

 

Jeg lurer også på hvor jeg skal plassere resten av spørringene. Er dette basert på at jeg må bruke stored procedures?

Endret 30. mai 2008 av atomtissetasen

[kaffenils]

? =;INSERT... bla bla

 

Jeg lurer også på hvor jeg skal plassere resten av spørringene. Er dette basert på at jeg må bruke stored procedures?

 

Det beste er å bruke stored procedures. Flere grunner til det. De to viktigste i mitt sy er for første så slipper du å endre ASP kildekoden hvis du vil endre i SQL batchen, og for det andre at SQL Server cacher eksekveringsplanen slik at spørringer vil kjøre litt raskere siden det ikke er nødvendig å generere ny plan hver eneste gang.

 

Du kan selvfølgelig også parameterisere inline SQL med flere statements.

 

dim cmd
dim param
dim rs

set cmd=createobject("ADODB.Command")
set cmd.ActiveConnection=conn 'conn er et objekt av type ADODB.Connection
cmd.CommandType=1 '=adCmdText, klassisk ASP sucks
cmd.CommandText="select * from artikler where artikkel_id=?;insert into tabell99(tittel) values(?)"
set param=cmd.CreateParameter(,3,1,,artikkelId) 'ASP S.U.C.K.S   3=adInteger, 1=adInputParam
cmd.Parameters.Add param
set param=cmd.CreateParameter(,200,1,100,"I am an evil hax0r';drop table artikler--") ' 200=adVarchar, 1=adInputParam, 100=lengden på varchar parameter
cmd.Parameters.Add param
set rs=cmd.execute

' Les data fra rs

rs.close

 

Så du ser så har jeg lagt inn et forsøk på SQL Injection i parameter 2, men siden vi bruker parameteriserte spørringer så vil selvfølgelig ikke SQL Server eksekvere DROP statementet.

Endret 30. mai 2008 av kaffenils

[Redak Tøren]

kaffenils: insert-koden min er en injection. Hvordan stoppes den i Parameters?

[Manfred]

Hvis det ikke er en kjempegod grunn til at du bruker asp/vbscript, så bør du ABSOLUTT se på asp.net (VB, C# eller noe annet du føler naturlig)

[kaffenils]

kaffenils: insert-koden min er en injection. Hvordan stoppes den i Parameters?

 

Bruk SQL Server Profiler og se hvordan parameteriserte spørringer i ADO oversettes til Transact-SQL.