[asp] uitschakelen query

[Verwijderd]

Ik heb het volgende probleem

Het is nu mogelijk om direct vanuit de adresregel een query te laten uitvoeren op de sql-database. Dit mag onder geen enkel beding.

Voorbeeld:

http://www.voorbeeld.nl/d...Y%20KEY%20%20(dit));%20--

Kan ik dit in asp uitschakelen of via de datebase?
zoja hoe of wat moet ik doen?

[faabman]

ff op www.aspfaqs.com / google zoeken naar sql-injection
of parameterized queries gebruiken (en daarover is recent een topic van intrix voorbij gekomen)

dit is overigens het topic van intrix (gaat specifiek in op asp vbscript, de tutorial is voor .NET)
[rml][ sql] parametrized UPDATE?[/rml]

[ Voor 35% gewijzigd door faabman op 07-04-2004 16:15 ]

[gorgi_19]

* gorgi_19 gooit dit maar in de strijd en bindt whoami vast, niet weer beginnen over je stokpaardje..

Trouwens, leuke URL, je hebt nog geluk gehad dat dit het enige was wat ze hebben gedaan..

Ow ja, als je gaat Googlen op SQL Injection, zoek dan ook gelijk op Cross Site Scripting attacks.

[ Voor 43% gewijzigd door gorgi_19 op 07-04-2004 16:15 ]

[whoami]

* whoami gooit dit ook in de strijd en schopt drm die de FAQ dringend moet updaten.

[P_de_B]

offtopic:
Wat doen jullie als je een site ontdekt die kwetsbaar is voor dit? Meld je het, of doe je juist niks?

/P_de_B meldt het meestal en heeft er al verschillende bedankjes aan over gehouden, o.a. een home cinema set .De meeste bedrijven reageren wel positief iig.

[gorgi_19]

P_de_B schreef op 07 april 2004 @ 16:23:

offtopic:
Wat doen jullie als je een site ontdekt die kwetsbaar is voor dit? Meld je het, of doe je juist niks?

/P_de_B meldt het meestal en heeft er al verschillende bedankjes aan over gehouden, o.a. een home cinema set .De meeste bedrijven reageren wel positief iig.

offtopic:
Mja, meestal ga ik er eik niet naar op zoek.... Maar zou het iig wel melden...
De %20Or%201=1 zegt meestal wel voldoende over de aanvalbaarheid.

[P_de_B]

gorgi_19 schreef op 07 april 2004 @ 16:24:
[...]

offtopic:
Mja, meestal ga ik er eik niet naar op zoek.... Maar zou het iig wel melden...
De %20Or%201=1 zegt meestal wel voldoende over de aanvalbaarheid.

offtopic:
op zoek niet echt, maar ik wil nog wel eens een ' in de querysting of een invoerveldje gooien....

[TeeDee]

Wat is eigenlijk de beste/makkelijkste/snelste manier om dit te checken zonder schade aan te richten?

Er draaien hier intern ook wel eens kleine "appjes" die door stagiares zijn gemaakt, en die wil ik op de een of andere manier toch checken zonder eerst de hele code door te spitten.

[gorgi_19]

TeeDee schreef op 07 april 2004 @ 16:30:
Wat is eigenlijk de beste/makkelijkste/snelste manier om dit te checken zonder schade aan te richten?

Er draaien hier intern ook wel eens kleine "appjes" die door stagiares zijn gemaakt, en die wil ik op de een of andere manier toch checken zonder eerst de hele code door te spitten.

In 9 van de 10 gevallen zit de oorzaak in de querystring of in een zoek functionaliteit. Heel makkelijk te controleren (querystring iig) mbv die OR 1=1 of een ' invullen.

[P_de_B]

Als je een zoals ik zei een ' in een invoerveld gooit en er komt een foutmelding is de site in principe kwetsbaar. Hoever je het lek kunt exploiten is dan maar de vraag.

Ik zal even op zoek naar 2 intressante whitepapers

edit: gevonden kijk hier maar eens tussen.

[ Voor 19% gewijzigd door P_de_B op 07-04-2004 16:34 ]

[gorgi_19]

P_de_B schreef op 07 april 2004 @ 16:33:
Als je een zoals ik zei een ' in een invoerveld gooit en er komt een foutmelding is de site in principe kwetsbaar. Hoever je het lek kunt exploiten is dan maar de vraag.

Ik zal even op zoek naar 2 intressante whitepapers

Ach, gewoon iedereen dwingen om parametrized queries te gebruiken, en je hebt het probleem ook opgelost.

[P_de_B]

gorgi_19 schreef op 07 april 2004 @ 16:34:
[...]

Ach, gewoon iedereen dwingen om parametrized queries te gebruiken, en je hebt het probleem ook opgelost.

/me eens is

[TeeDee]

Stapje verder dan:
Ik gebruik nu zelf ook PQ's. Is het daarbij zo dat je in principe "alles" in je submit kan zetten en de db het uit laat zoeken?

Bijvoorbeeld:
- datum
- id's?

edit: thanks gorgi_19.

Om het e.e.a. te checken is het dus zo dat als je achter de url ' or 1=1-- (of iets in die trend) moet zetten.

Dit is allemaal opgelost mbv PQ's.

* TeeDee toch goed bezig is dan

edit2:
In het verleden deed ik alleen maar checken op het ; teken. Niet bij stilgestaan dat de ' or 1=1-- etc. etc. ook een probleem op kon leveren.

[ Voor 66% gewijzigd door TeeDee op 07-04-2004 16:40 ]

[gorgi_19]

TeeDee schreef op 07 april 2004 @ 16:35:
Stapje verder dan:
Ik gebruik nu zelf ook PQ's. Is het daarbij zo dat je in principe "alles" in je submit kan zetten en de db het uit laat zoeken?

Bijvoorbeeld:
- datum
- id's?

Ja, of het geeft een foutmelding, maar is geen exploit.
Stel je wilt een ongeldige datum invoeren; dan geeft het een foutmelding, maar levert het geen exploit op.

[P_de_B]

TeeDee schreef op 07 april 2004 @ 16:35:
In het verleden deed ik alleen maar checken op het ; teken. Niet bij stilgestaan dat de ' or 1=1-- etc. etc. ook een probleem op kon leveren.

Wat dacht je van

' shutdown --, of

' xp_cmdshell 'c\format c:' --

Bij de site van een bekend bedrijf was dit tot voor kort mogelijk.

[gorgi_19]

P_de_B schreef op 07 april 2004 @ 16:46:
[...]


Wat dacht je van

' shutdown --, of

' xp_cmdshell 'c\format c:' --

Bij de site van een bekend bedrijf was dit tot voor kort mogelijk.

Werden die commando's niet uitgevoerd in de security context van de ingelogde SQL Server User of werden die uitgevoerd in de context van het system account?

Maar erhm.. best leuk topic zo, maar.. Waar is de topicstarter gebleven?

[ Voor 13% gewijzigd door gorgi_19 op 07-04-2004 16:50 ]

[P_de_B]

gorgi_19 schreef op 07 april 2004 @ 16:49:
[...]

Werden die commando's niet uitgevoerd in de security context van de ingelogde SQL Server User of werden die uitgevoerd in de context van het system account?

System account, die blijkbaar lokaal rechten had.


trouwens ' SELECT CURRENT_USER -- gaf dbo als resultaat.

[gorgi_19]

P_de_B schreef op 07 april 2004 @ 16:53:
trouwens ' SELECT CURRENT_USER -- gaf dbo als resultaat.

Erhm.. Ja? Je kan toch een SQL Server user dbo maken? Wil niet zeggen dat hij veel rechten had op de XP_- of SP_- procedures.

[P_de_B]

gorgi_19 schreef op 07 april 2004 @ 16:55:
[...]

Erhm.. Ja? Je kan toch een SQL Server user dbo maken? Wil niet zeggen dat hij veel rechten had op de XP_- of SP_- procedures.

dbo is toch standaard lid van de groep sysadmin en die groep heeft standaard rechten op xp_cmdshell (en wordt xp_cmdshell uitgevoerd in de security context van het sql server service account)

[Verwijderd]

Hier ben ik weer,

Was aan het spitten met de links die jullie gaven, maar wordt nog niet veel wijzer.
Ik neem aan de dit probleem wel vaker is voorgekomen. Wat was toen de oplossing.????

[Verwijderd]

Ik ga off-line eten en dan weg.

modbreak:
Je kan ook de edit-knop gebruiken (zeker voor 'nutteloze' replies zoals deze).
Daarnaast is de oplossing al gegeven in de form van hints en tips waar je zeker eens moet naar kijken.

[ Voor 79% gewijzigd door whoami op 08-04-2004 08:28 ]

[P_de_B]

Verwijderd schreef op 07 april 2004 @ 17:03:
Hier ben ik weer,

Was aan het spitten met de links die jullie gaven, maar wordt nog niet veel wijzer.
Ik neem aan de dit probleem wel vaker is voorgekomen. Wat was toen de oplossing.????

De oplossing staat in de links die gorgi_19 en whoami hebben gegeven.

[BCC]

Toch maar even snel overal op mijn website Request.QueryString + 0 ingevoerd (gebruikte alleen maar een paar Where ID=''). Niet zo netjes.. maar het werkt wel Zal het volgende week eens herschrijven.. zo leer je nog eens wat

[ Voor 11% gewijzigd door BCC op 07-04-2004 18:45 ]

[gorgi_19]

BCC schreef op 07 april 2004 @ 18:37:
Toch maar even snel overal op mijn website Request.QueryString + 0 ingevoerd (gebruikte alleen maar een paar Where ID=''). Niet zo netjes.. maar het werkt wel Zal het volgende week eens herschrijven.. zo leer je nog eens wat

Dan nog ben je in gevaar van SQL Injection attacks...

[djluc]

Hebben jullie niet gewoon een standaardfunctie die je aanroept zodra je iets in je sql mikt? Ik heb een functie ui(INPUT, TYPE). Deze functie UserInput zorgt er voor dat de gegevens altijd alleen de toegestane gegevens bevatten en zorgen er voor dat slashes worden escaped e.d.

[gorgi_19]

djluc schreef op 07 april 2004 @ 19:56:
Hebben jullie niet gewoon een standaardfunctie die je aanroept zodra je iets in je sql mikt? Ik heb een functie ui(INPUT, TYPE). Deze functie UserInput zorgt er voor dat de gegevens altijd alleen de toegestane gegevens bevatten en zorgen er voor dat slashes worden escaped e.d.

Ja; die van parametrized queries.. Doet in principe hetzelfde, maar dan een stuk efficienter.

[BCC]

gorgi_19 schreef op 07 april 2004 @ 19:52:
[...]
Dan nog ben je in gevaar van SQL Injection attacks...

Nee.. de enige parameter moet een int zijn, anders klapt hij eruit omdat je geen int bij een string mag optellen.. En hoe wou je een hele SQL Query in een int drukken?

[ Voor 18% gewijzigd door BCC op 07-04-2004 22:00 . Reden: Clarify ]

[gorgi_19]

BCC schreef op 07 april 2004 @ 21:55:
[...]


Nee.. de enige parameter moet een int zijn, anders klapt hij eruit omdat je geen int bij een string mag optellen.. En hoe wou je een hele SQL Query in een int drukken?

Geen idee hoe de rest van je code er uit ziet... Als je

SQL:

Select * FROM tabelnaam WHERE ID = " & Request.Querystring("id") + 0 

doet ben je nog steeds aanvalbaar.

[faabman]

gorgi_19 schreef op 08 april 2004 @ 01:03:
[...]

Geen idee hoe de rest van je code er uit ziet... Als je

SQL:

Select * FROM tabelnaam WHERE ID = " & Request.Querystring("id") + 0 

doet ben je nog steeds aanvalbaar.

ja, maar, als je

code:

dim intID
  intID = Request.Querystring("ID")

If IsNumeric(intID) = False Then intID = 0
  intID = CInt(intID)

sqlquery = "SELECT foo FROM tbl_foo WHERE ID=" & intID

doet dan is dat probleem opgelost... imho is het ook bij het gebruik van parameterized queries onoverkombaar om iets dergelijks (als in het met je script controleren van je datatypes) te doen... met alleen pq's scherm je dan wel je database af, maar, wanneer een gebruiker een verkeerd datatype invoert dan ontstaat er nog steeds een fout

[gorgi_19]

een fout is imho minder erg dan een exploit. Nette errorpage maken en dan klaar.

[Verwijderd]

Hoi, hier ben ik weer.

Ik heb het jbf opgelost en het werkt.

in alle prog gebruik ik dezelfde include.
in deze include vraag ik nu de querystring op en scan deze op schadelijke componenten (gereserveerde woorden voor sql). Komt de prog die tegen dan response.end

Einde programma en niets geen problemen meer

[faabman]

Verwijderd schreef op 08 april 2004 @ 10:08:
Hoi, hier ben ik weer.

Ik heb het jbf opgelost en het werkt.

in alle prog gebruik ik dezelfde include.
in deze include vraag ik nu de querystring op en scan deze op schadelijke componenten (gereserveerde woorden voor sql). Komt de prog die tegen dan response.end

Einde programma en niets geen problemen meer

daarmee beperk je dus wel je app... wanneer je param. quer. gebruikt hoef je de gebruiker in ieder geval geen response.end te geven wanneer er iets wordt ingetypt wat niet mag... gebruikers / bezoekers hebben niets aan een response.end...

[Yoeri]

offtopic:
Heb hier ook wel een gerelateerd vraagje over...
Een hele tijd geleden zat ik op een site waar ik wat zaken in de catalogus wou opzoeken, en kreeg regelmatig resultaten als:

bij zoeken naar bestaatniet: Product met "bestaatniet" werd niet gevonden in onze database

dus telkens een melding: "dit product bestaat niet"

plots typte ik echter als zoekopdracht een % en toen kreeg ik volgende melding:
Resultaat van zoeken voor "ÿLM/W3SVC/1/Root/ttttt"
(die ttttt heb ik zelf even vervangen omdat de site anders makkelijk herkenbaar is)

is zoiets nu exploitable of niet? een 'or 1=1 achter de zoekterm zetten resulteert gewoon in 'gezochte product niet beschikbaar'

wil dergelijke zaken best wel melden als ik ze tegenkom, maar wil die betreffende site nu ook niet gaan lastigvallen voor iets wat geen probleem inhoudt

[ Voor 5% gewijzigd door Yoeri op 08-04-2004 11:46 ]