[ASP] Voorkomen van SQL Injection Attacks

[DeverauX]

Zoals velen heb ik in mijn QueryString een ID staan voor een bepaald record wat uit een db gehaald moet worden.
Werkt allemaal prima, alleen laatst kwam ik een artikel tegen over SQL Injection Attacks en dit deed me toch een beetje schrikken hoe makkelijk het is de boel te verzieken, maar ja verder geen problemen: het script een beetje aangepast zodat van alle variabele die gebruikt worden in de query de single quotes worden gewijzigd in een dubbele, alle "gevaarlijke" woorden zoals: DROP, DELETE, INSERT,(,), (--), en xp_ automatisch worden verwijderd. ook wordt er gechecked of de variabele wel echt een integer of een long integer is.
Risico hopenlijk dus aanzienlijk verminderd of althans dat wil ik graag geloven. Maar is dit ook zo? Dat is dus eigenlijk de vraag. Zijn er meer dingen die ik moet doen om de beveiliging op dit vlak te verbeteren? En zo ja welke?

HEt is trouwens ook zo dat er nu, wanneer iemand de ID van de QueryString veranderd (bijvoorbeeld incl een singel quote ) er een foutmelding wordt gegenereerd met de melding dat de typen niet overeenkomen, het werkt dus.
Maar echt gebruikersvriendelijk vindt ik dit niet dus ben ik eigenlijk op zoek naar een oplossing om alle niet numerieke waarden te verwijderen uit de queryString en zo dus wel gewoon het record weer te geven.
Ben nog een beetje een rookie met ASP dus eigenlijk heb ik geen idee of dit kan en zo ja hoe ik dit moet doen.

Iemand een suggestie?

thnx

[Scharnout]

Je kan natuurlijk voorwaardelijk controleren of het een integer is (if then else enzovoort). Als ie daaraan niet voldoet geef je dat weer of je forward die persoon naar een andere pagina.

Denk er ook aan om bv "<" af te vangen. ivm cross site scripting (stond in hetzelfde artikel bij 4guys from rolla). Ik zie ook dat je alleen maar het wijzigen van je databast (DROP, INSERT etc) afvangt. Waarom geen select? Of denk je dat mensen je database gegevens niet leuk vinden ofzo? Ik heb gewoon ";" ook gereplaced.

[DeverauX]

";" heb ik inderdaad ook afgevangen. < en > had ik al voor het lezen van het artikel gedaan! (was trouwens op devarticles dacht ik )
Select heb ik eigenlijk niet bij stil gestaan omdat het minder erg is dan delete of drop bijvoorbeeld. Maar toch een idee deze ook af te vangen!

Het voorwaardelijk controleren is idd iets waar ik ook aan zat te denken maar dan moet ik de persoon forwarden naar een andere pagina ipv de pagina die eigenlijk opgevraagt moet worden, en dit is juist hetgeen wat ik probeer te voorkomen...

[EfBe]

'@' verwijderen
' verwijderen (single quotes)
; verwijderen
" verwijderen

Maar beter is stored procedures te gebruiken of parametrized queries (dus een command gebruiken en een query met '?' op de plaatsen van de variables zie ADO docs voor details)

[Unipuma]

Uhmm, mischien kun je je website aanpassen, om POST ipv GET te gebruiken. Bij een POST gaat alle data in de body, en zie je dus ook niet van die lange (aanpasbare) URLs.
De enige reden om via een GET te werken is als je de gebruiker de gelegenheid wilt bieden om een bookmark te maken van de (gegenereerde) pagina. POST is sowieso handiger, omdat een header-request (via GET) maar een beperkte lengte mag hebben, en daarnaast problemen veroorzaakt met bijzondere tekens (zoals + en &).

[Verwijderd]

Afgelopen vrijdag was er een congres in Ede van de SDGN (Software Developer Group Nederland). Hier was het thema 'security' en werd bovenstaande dus ook behandeld. Deze link is daarom sowieso erg interessant: http://www.madison-gurkha.com/publications/SDGN.pdf

Verder inhoudelijk wat commentaar:
Form field zal je altijd inhoudelijk moeten controleren! Verwacht je een integer, dan check je hier eerst op. Let erop dat het getal 6467457823876592354 ook een integer is, maar dat je code hier onherroepelijk op stukloopt.

Vang dit soort input daarom ook niet alleen client-side af (d.m.v. javascript ofzow). Altijd server-side doen!

SQL Injection is 'levensgevaarlijk' dus filter input op tekens als: ; ' | / # % . .. - (mits je een van deze tekens verwacht natuurlijk)

Unipuma heeft helemaal gelijk: gebruik geen GET maar POST. Aanvullend worden de URL's die je op deze manier gebruikt ook nog eens overal gelogd. Op deze manier kunnen hackers leuk hun gang gaan.

Oh ja, de standaard foutpagina's van IIS geven een ontwikkelaar leuke debuginfo, maar hackers nog leukere hackinfo. En dat terwijl een onnozele internetter hier niks mee kan. Verander daarom de standaard foutpagina in een nette boodschap o.i.d.

[stylee]

Check hier maar eens onder counter-measures

[Verwijderd]

Oh ja, ook een hele goede remedie:

GEBRUIK STORED PROCEDURES ipv van queries in je code op te bouwen...

[4of9]

Als je op ID's op iets dergelijks selecteerd, convert die ID's dan naar Lng met Clng, zo voorkom je dat er text in mag staan.

[DeverauX]

Ik check nu bij de ID of het wel daadwerkelijk een numerieke waarde is, zoniet dan redirecten naar de mainpage van die sectie. Is eigenlijk niet wat ik wilde maar als er niet geknoeid wordt met de URL dan komt het ook niet voor.
Dat converten met Clng of Cint was in eerste instantie een optie, alleen genereerd een foutmelding dat de type niet overeenkomen wanneer er een niet numerieke waarde wordt ingevuldt. Dan is het redirecten toch een beter alternatief denk ik. (in ieder geval gebruiksvriendelijker)

Maak met forms ook altijd gebruik van de methode Post ipv Get, idd om security redenen maar ook omdat er beperkingen zijn met mbt tot de hoeveelheid data die je ermee kan verzenden.

Stored Procedures? Klinkt interessant maar daar zal ik me dan toch eerst verder
in moeten verdiepen

Thnx voor de tips!

[Gert]

Je kan ook kijken of de referrer pagina wel eentje van jouw is.

[Crazy D]

Gert schreef op 20 December 2002 @ 19:51:
Je kan ook kijken of de referrer pagina wel eentje van jouw is.

Die is niet heilig (is te faken), en ook dan moet je nog steeds _alle_ input valideren voordat je deze gebruikt.

[klinz]

Unipuma schreef op 19 December 2002 @ 14:08:
Uhmm, mischien kun je je website aanpassen, om POST ipv GET te gebruiken. Bij een POST gaat alle data in de body, en zie je dus ook niet van die lange (aanpasbare) URLs.

Een POST is ook te faken, weliswaar iets lastiger. Ik heb een browser gemaakt waarin je alle cookies, querystring- en formvariabelen ziet en desgewenst kunt aanpassen. En neen, die ga ik niet releasen.

[Bosmonster]

Wat ikzelf in PHP/MySQL doe en altijd prima werkt is de complete binnengekomen string voorzien van slashes voor gekke tekens en vervolgens in de query ook tussen quotes zetten. Hierdoor kunnen ze nooit gekke dingen doen, want om de query aan te passen zullen ze de quotes moeten sluiten, maar dit gaat niet doordat al hun eigen quotes voorzien worden van slashes.

Dus ook al is het een integer ID, alsnog zoiets doen:

... WHERE ID='".addslashes(ID_uit_querystring)."' ...

En vullen ze gekke dingen in dan wordt de record gewoon niet gevonden. Ik weet dat het idee PHP is, maar lijkt me het zelfde werken voor ASP

[ Voor 7% gewijzigd door Bosmonster op 21-12-2002 19:46 ]

[Verwijderd]

wat beter is, is om niet de

code:

select * from tabel where ID = " & Reuest.Querstring("ID")

te gebruiken, maar het command opject en daar parameters aan toevoegen.
weet niet 100% of dat ook werkt voor access databases, maar wel voor stored procedures in MS SQL Server

[Verwijderd]

Bosmonster schreef op 21 December 2002 @ 19:46:
Wat ikzelf in PHP/MySQL doe en altijd prima werkt is de complete binnengekomen string voorzien van slashes voor gekke tekens en vervolgens in de query ook tussen quotes zetten. Hierdoor kunnen ze nooit gekke dingen doen, want om de query aan te passen zullen ze de quotes moeten sluiten, maar dit gaat niet doordat al hun eigen quotes voorzien worden van slashes.

Dus ook al is het een integer ID, alsnog zoiets doen:

... WHERE ID='".addslashes(ID_uit_querystring)."' ...

En vullen ze gekke dingen in dan wordt de record gewoon niet gevonden. Ik weet dat het idee PHP is, maar lijkt me het zelfde werken voor ASP

Qua strings ben ik het helemaal met je eens. Het is later ook gewoon weer terug te zetten naar de originele string. Als je zoals de topicstarter zulke 'rare' dingen gaat doen als woorden uit een string halen omdat ze mogelijk gevaarlijk zijn, dan overdrijf je behoorlijk.

Integers kun je uiteraard ook eerst expliciet naar een integer casten. Is het iets raars, dan komt er 0 uit, ook vrij onschadelijk in een query.

[Verwijderd]

Kan er nu iemand kort en bondig uitleggen hoe het nu moet?, uitleg dmv. hoop codes?

Is dit goed?

ASP:

naam = request.querystring("naam")

naam = replace(naam,"delete","")
naam = replace(naam,"drop","")
naam = replace(naam,"insert","")
naam = replace(naam,"_xp","")

'SQL string:
............ WHERE tblTabel2.naam='" & naam & "';"

óf?

ASP:

naam = request.querystring("naam")

if instr(naam,"delete","") then response.redirect("SQL_error.asp")
if instr(naam,"drop","") then response.redirect("SQL_error.asp")
if instr(naam,"insert","") then response.redirect("SQL_error.asp")
if instr(naam,"_xp","") then response.redirect("SQL_error.asp")

'SQL string:
............ WHERE tblTabel2.naam='" & naam & "';"

Is dit goed, of snap ik het nu nog niet

[ Voor 43% gewijzigd door Verwijderd op 22-12-2002 10:54 ]

[Verwijderd]

Nee, het is gewoon belachelijk. Jij stuurde toch ook zojuist een string met het woord 'delete' de database van dit forum in? Dat moet ook gewoon kunnen.
Doe wat Bosmonster beschrijft: escape enkele quotes en procenttekens, en zet tot slot enkele quotes om een string.

Jij laat nu nog ruimte over om het volgende als string op te geven:
pietje' OR tblTabel2.naam='henk

[ Voor 6% gewijzigd door Verwijderd op 22-12-2002 12:19 ]

[DeverauX]

Ik heb nu trouwens ook zoveel mogelijk proberen te vermijden variabelen te gebruiken in de Query. Dus niet meer zoiets van:

Dim category
category = Request.QueryString("category")

SELECT * from table WHERE category=" & category

maar gewoon een voorwaardelijke expressie:

If category="..." Then
SELECT * from table WHERE category='...' "

ElseIf category="..." Then
SELECT * from table WHERE category='...' "


End If

Nu werkt dit nog wel wanneer je een beperkt aantal verschillende soorten categoriën hebt, alleen wanneer je er tientallen hebt wordt de boel toch een beetje onoverzichtelijk.

Wat ik trouwens bij de ID doe is:

'Secure Query
If isnumeric(item)=false then
Response.Redirect "resources.asp?cat=articles"
End If

Voor digidude;

bij Instr moet je doen:

If Instr(naam, "DROP") > 0 Then
Response.Redirect ("SQLerror.asp")
End If

Het heeft echter zoals Cheetah zei geen zin dit te doen, zorg er gewoon voor dat alle squotes eruit gefilterd worden.

[Verwijderd]

Verwijderd schreef op 22 december 2002 @ 12:18:
Nee, het is gewoon belachelijk. Jij stuurde toch ook zojuist een string met het woord 'delete' de database van dit forum in? Dat moet ook gewoon kunnen.
Doe wat Bosmonster beschrijft: escape enkele quotes en procenttekens, en zet tot slot enkele quotes om een string.

Jij laat nu nog ruimte over om het volgende als string op te geven:
pietje' OR tblTabel2.naam='henk

Neej, maar dat vervangen etc. doe je toch ook alleen bij de querystring waar de database in moet zoeken???

Hier bij GOT geef je ook een topic ID op, zodat de DB weet waar hij hem moet bij schrijven, maar "mijn script" hoeft dan natuurlijk niet gebruikt te worden bij normale bijschrijvingen in de database...

Het heeft echter zoals Cheetah zei geen zin dit te doen, zorg er gewoon voor dat alle squotes eruit gefilterd worden.

Dus zoiets???:

ASP:

ID = replace(ID,"'","")

[ Voor 31% gewijzigd door Verwijderd op 22-12-2002 12:46 ]

[DeverauX]

Als je ID een numerieke is dan hoef je alleen te checken of dit ook daadwerkelijk het geval is, zo niet dan redirecten.
Is het een alfa-numerieke waarde dan moet je inderdaad de "gevaarlijke" tekens eruit halen.

[gorgi_19]

Verwijderd schreef op 22 december 2002 @ 12:43:
[...]

Dus zoiets???:

ASP:

ID = replace(ID,"'","")

Eerder:

ASP:

ID = replace(ID,"'","''")

[Verwijderd]

Bedankt!