Geheel dynamische SQL queries maken in ASP

[Verwijderd]

Hoi tweakers,

Ik zit met een probleempje op mijn stage.
Ik moet een soort van zoekpagina maken voor het bedrijf.

Gebruikers kunnen doormiddel van drie listboxjes hun zoekcriteria aangeven.

Die waarden die ze doorgeven bv (listbox1)bedrijf, (listbox2)afdeling, (listbox3)functie worden via de <Option Value"Philips">Philips dan doorgegeven aan een andere ASP pagina via de POST methode. Punt is nu dat ik deze waarden in een SQL querie wil gebruiken.

Hier een voorbeeld:
SELECT Med_ID,Med_nr,Med_naam,Med_roep FROM Medewerker WHERE Med_roep LIKE '" &strnaam &"%'"

Zoals jullie zien heb ik deels al variabelen gebruikt namelijk: strnaam
, hierin zit de waarde Philips.

Punt is nu dat wanneer er meerdere dingen worden opgegeven, dus van listbox 1:Philips en van listbox2: Inkoop dat ik met verschillende tabellen zit te werken, dus de veldnamen worden anders.

Een gebruiker kan zelf kiezen of die alleen maar zoekt op Philips of op Philips en inkoop.

Ik ben niet van plan om alle mogelijke scenario's uit te schrijven in cases want dan heb ik straks wel 80 verschillende SQL statements in mijn ASP scriptje staan.

Is er een manier om ook de veldnamen variabel te maken dus bv:

Select variabele1, variabele2 FROM variabele3 WHERE variabele4 = variabele5

bv:
variabele1= afd_hoofd
variabele2= afd_nr
variabele3= AFDELINGEN
variabele4=afd_naam
variabele5=Inkoop

Ik hoop echt dat jullie een oplossing vinden, want heb er minstens 4 uur op gegoogled.
Bij voorbaat dank.

[Verwijderd]

Tuurlijk kan dat Gewoon

ASP:

query = "SELECT " &var1& " FROM " &var2&" WHERE "&var3&" = "&var4

Zorg wel dat de tabel- en veldnamen bestaan...

[gorgi_19]

Verwijderd schreef op maandag 06 februari 2006 @ 16:10:
Zorg wel dat de tabel- en veldnamen bestaan...

En je geen last hebt van SQL Injection.

[curry684]

Verwijderd schreef op maandag 06 februari 2006 @ 16:10:
Tuurlijk kan dat Gewoon

ASP:

query = "SELECT " &var1& " FROM " &var2&" WHERE "&var3&" = "&var4

Zorg wel dat de tabel- en veldnamen bestaan...

En nou nog een basiscursus SQL/HTML injection.

edit:
* curry684 mept gorgsel

[ Voor 6% gewijzigd door curry684 op 06-02-2006 16:13 ]

[Verwijderd]

gorgi_19 schreef op maandag 06 februari 2006 @ 16:12:
[...]

En je geen last hebt van SQL Injection.

Ja oke, even vergeten

Ik hoop echt dat jullie een oplossing vinden, want heb er minstens 4 uur op gegoogled.

Meen je dat serieus? Ik vind mijn 'oplossing' nou niet echt baanbrekend of zo

[ Voor 33% gewijzigd door Verwijderd op 06-02-2006 16:26 ]

[Verwijderd]

Ja dat meen ik, zodra ik

making dynamic query with ASP in google intypte kreeg ik alleen shit over Stored procedures.

[Verwijderd]

Verwijderd schreef op maandag 06 februari 2006 @ 20:53:
Ja dat meen ik, zodra ik

making dynamic query with ASP in google intypte kreeg ik alleen shit over Stored procedures.

Maar daar kun je dit toch ook prima mee oplossen? En dan is het risico op hacks, zoals hierboven beschreven, ook veel kleiner.

[EfBe]

Verwijderd schreef op maandag 06 februari 2006 @ 23:17:
[...]


Maar daar kun je dit toch ook prima mee oplossen? En dan is het risico op hacks, zoals hierboven beschreven, ook veel kleiner.

SQL fabriceren in een procedure maakt het niet minder onveilig.

Wat TS moet doen is parameterized queries maken. dus:
SELECT Med_ID,Med_nr,Med_naam,Med_roep FROM Medewerker WHERE Med_roep LIKE @likeParam

en dan de value voor likeParam zetten op de pattern string die je wilt gebruiken. Dit kost niet veel moeite, gewoon even een include maken waarin je een method prakt die een parameter creeert voor een meegegeven ADO command object, (waar je ook een utility method voor maakt om die aan te maken), zodoende kun je dus heel simpel heel snel parameterized queries maken zonder last van sql injection en zonder het gezever met procedures.

[Verwijderd]

Wat betekend in godsnaam SQL injection????

[DeverauX]

Verwijderd schreef op dinsdag 07 februari 2006 @ 08:44:
Wat betekend in godsnaam SQL injection????

Zie:
http://www.4guysfromrolla.com/webtech/061902-1.shtml

Verder zou ik, als het even kan (van welke db maak je eigenlijk gebruik?) inderdaad gebruik maken van een stored procedure of in ieder geval een parameterized query.

[Jaspertje]

daarvoor kan je de FAQ gebruiken, kan het ook even kort samenvatten:
Je hebt de volgende query:

SELECT * FROM tabel1 Where waardeX = '"&request.Form("formpost")&"'

Als dan request.Form("formpost") 27 is omdat je gebruiker 27 invult, is er niks aan de hand, dan komt er :SELECT * FROM tabel1 Where waardeX = '27' te staan.
Stel nou eens dat request.Form("formpost"): 27';delete from tabel1 where '1' = '1 is. dan komt er:

SELECT * FROM tabel1 Where waardeX = '27';delete from tabel1 where '1' = '1' te staan

Voer dit maar eens uit op je database, kan je lachen. Als je ervoor zorgt dat de database server de waarde altijd als waarde behandeld en niet als extra SQL, dan kan je dit probleem niet tegenkomen

[kalechinees]

Ik zou gewoon dynamisch je sql string samenstellen. Het veld wordt alleen toegevoegd aan de query wanneer hij niet leeg is.
Sql injection werkt alleen maar achteraan in een query. Om te zorgen dat er geen tweede sql statement achteraan gelaunched kan worden kun je een fake statement achteraan de query plaatsen. maw, maak het lastig om via de querystring een geldige query samen te stellen.

Een aantal verboden woorden filteren uit de querysting kan ook een simpele oplossing zijn.
drop icm table/database
delete icm from
delete icm from
etc
etc

SQL injection is bovendien alleen gevaarlijk op het moment dat je een ID veld uit een querystring direct als ID gebruikt in een query.

code:

if request.form("afdeling") <> "" then
   query_afdeling = "afdeling = ' " & request.form("afdeling") & "'"
end if

if request.form("bedrijf") <> "" then
   query_bedrijf = "bedrijf= ' " & request.form("bedrijf") & "'"
   if query_afdeling <> "" then query_afdeling = query_afdeling & "AND "
end if

sql = "select * " _
    & "from blabla " _
    & "where " _
    & query_afdeling _
    & query_bedrijf
    & "AND not 0=1"

[ Voor 58% gewijzigd door kalechinees op 07-02-2006 09:22 . Reden: shit net te laat :) ]

[NMe]

Verwijderd schreef op dinsdag 07 februari 2006 @ 08:44:
Wat betekend in godsnaam SQL injection????

Is Google stuk bij jou? Dat soort dingen kun je prima zelf opzoeken hoor.

[curry684]

kalechinees schreef op dinsdag 07 februari 2006 @ 09:16:
Sql injection werkt alleen maar achteraan in een query. Om te zorgen dat er geen tweede sql statement achteraan gelaunched kan worden kun je een fake statement achteraan de query plaatsen. maw, maak het lastig om via de querystring een geldige query samen te stellen.

Een aantal verboden woorden filteren uit de querysting kan ook een simpele oplossing zijn.
drop icm table/database
delete icm from
delete icm from
etc
etc

SQL injection is bovendien alleen gevaarlijk op het moment dat je een ID veld uit een querystring direct als ID gebruikt in een query.

Uhmmmm ga jij die basiscursus SQL injection ook even doen want wat je hier allemaal post slaat als een tang op een varken

SQL injection is een gevaar bij iedere vorm van unprotected string concatenation om een query samen te stellen. Verboden woorden filteren is geen oplossing, de enige manier is correct escapen.

[kalechinees]

ehm... sql injection -> invoegen van sql statements wanneer deze dynamisch wordt samengesteld.
Ik zie verder geen andere manieren behalve een form, query, session of cookie request om informatie in een webpagina te laden.
Als deze gecontroleerd worden op sql statements heb je toch een vrij veilige oplossing...
M'n l33t h4xxor skills zijn dan niet om over naar huis te schrijven maar ik geloof dat dit een gros van de pogingen verijdeld.

vind bovendien dat je een vrij flamende houding hebt voor een mod... welke toch het goede voorbeeld zou moeten geven

[ Voor 18% gewijzigd door kalechinees op 07-02-2006 09:59 ]

[kenneth]

curry684 schreef op dinsdag 07 februari 2006 @ 09:32:
SQL injection is een gevaar bij iedere vorm van unprotected string concatenation om een query samen te stellen. Verboden woorden filteren is geen oplossing, de enige manier is correct escapen.

Maar in deze situatie zou je toch eerder kiezen voor een parameterized query?

Het voorkomt btw ook eventuele culture-problemen met floating point (komma of punt?) en datums (slash of dash? m/d of d/m?)

[Janoz]

@kale chinees:

De manier waarop jij sql-injections probeert op te lossen is alsof je een lek in je dak maakt door een paar emmers neer te zetten.

Kijk eens naar de volgende twee queries:
SELECT * FROM USERS WHERE USERNAME='$username' AND PASSWORD='$password'

DELETE FROM ITEMS WHERE ID=$id

Bedenk eens wat er gebeurt als ik bij de eerst als wachtwoord " ' OR 'x'='x" en bij de tweede "1 OR 1=1" invul. Deze zouden keurig door je check heenkomen. Ook dit valt onder de SQL-Injection.

De enige juiste manier om sql-injections te voorkomen is ervoor te zorgen dat de variabelen die je in je query gebruikt alleen maar als data kunnen worden gezien. Wanneer je getallen gebruikt, controleer dan of er daadwerkelijk een integer meegegeven is. Wanneer je strings gebruikt, zorg dan dat ze juist geescaped worden (in php met mysql_real_escape oid). Gebruik geen userinput als kolomnaam of tabel naam. Beste oplossing is nog om gewoon geparameteriseerde queries te gebruiken.asp

[kenneth]

kalechinees schreef op dinsdag 07 februari 2006 @ 09:57:
Als deze gecontroleerd worden op sql statements heb je toch een vrij veilige oplossing...

Nee, het is symptoombestrijding van het ergste soort, zeker omdat de *echte* oplossing (Janoz: ...dat de variabelen die je in je query gebruikt alleen maar als data kunnen worden gezien) eenvoudiger én eleganter is.

[curry684]

kenneth schreef op dinsdag 07 februari 2006 @ 10:00:
[...]

Maar in deze situatie zou je toch eerder kiezen voor een parameterized query?

Nog liever dan protected concatenations idd, maar in het geval van parameterized queries heb je sowieso geen SQL injection risico

kalechinees schreef op dinsdag 07 februari 2006 @ 09:57:
ehm... sql injection -> invoegen van sql statements wanneer deze dynamisch wordt samengesteld.
Ik zie verder geen andere manieren behalve een form, query, session of cookie request om informatie in een webpagina te laden.

Klopt beiden. Je dicht alleen het lek niet op jouw manier.

Als deze gecontroleerd worden op sql statements heb je toch een vrij veilige oplossing...
M'n l33t h4xxor skills zijn dan niet om over naar huis te schrijven maar ik geloof dat dit een gros van de pogingen verijdeld.

"Een gros" is nooit genoeg. Security is mikken op 100% of genoegen nemen met geen security.

Om in PHP een voorbeeld te geven dat jouw aanpak al om zeep helpt.

PHP:

$res = mysql_query("SELECT * FROM User WHERE UserName = '".$_POST["username"]
            ."' AND Password = md5('".$_POST["password"]."')");

En nu voer ik als username in:

code:

Pietje'; INSERT Security VALUES('Curry', 'Administrator'); SELECT '

Gefeliciteerd, ik heb administrator access op jouw systeem. Of wil je het woord 'insert' ook gaan filteren? Doen we het toch gewoon zo:

code:

Pietje'; SELECT 'Curry', 'Administrator' INTO Security; SELECT '

Je wil dus gewoon ieder SQL-keyword filteren? Zou leuk zijn als de forumsoftware hier dat zou doen, zou ik deze post niet hebben kunnen maken.

SQL injection bestrijdt je door correcte escaping of parameterized queries. Iedere andere poging is lek en de moeite niet waard.

vind bovendien dat je een vrij flamende houding hebt voor een mod... welke toch het goede voorbeeld zou moeten geven

Bull, het feit dat ik zei dat je stierenschijt postte is geen flame maar een feit.

[kalechinees]

@curry
okee okee was een beetje op m'n pik getrapt. Excuses. Lijkt erop dat ik ongelijk heb. Daarom ben ik ook geen modje hier. Heb iig weer wat bijgeleerd

heb even gekeken naar de php functie: mysql_real_escape_string()
Wat ik zie zorgt deze functie ervoor dat oa de quotes en slashes extra 'gebackslashed' worden.
Wat gebeurt er dan fysiek met de informatie uit de variabele? Geeft ie dan een error op z'n query?

where username = '$user' and password = '$pass'
Where username = '' and password = '' or 1=1

[ Voor 30% gewijzigd door kalechinees op 07-02-2006 12:51 ]

[DizzyWeb]

kalechinees schreef op dinsdag 07 februari 2006 @ 12:48:
@curry
okee okee was een beetje op m'n pik getrapt. Excuses. Lijkt erop dat ik ongelijk heb. Daarom ben ik ook geen modje hier. Heb iig weer wat bijgeleerd

heb even gekeken naar de php functie: mysql_real_escape_string()
Wat ik zie zorgt deze functie ervoor dat oa de quotes en slashes extra 'gebackslashed' worden.
Wat gebeurt er dan fysiek met de informatie uit de variabele? Geeft ie dan een error op z'n query?

where username = '$user' and password = '$pass'
Where username = '' and password = '' or 1=1

De ingevoerde tekst komt dan letterlijk in de database.

[curry684]

kalechinees schreef op dinsdag 07 februari 2006 @ 12:48:
@curry
okee okee was een beetje op m'n pik getrapt. Excuses. Lijkt erop dat ik ongelijk heb. Daarom ben ik ook geen modje hier. Heb iig weer wat bijgeleerd

No problem Ik ben overigens geen mod van Programming & Webscripting maar van Werk en Inkomen

heb even gekeken naar de php functie: mysql_real_escape_string()
Wat ik zie zorgt deze functie ervoor dat oa de quotes en slashes extra 'gebackslashed' worden.
Wat gebeurt er dan fysiek met de informatie uit de variabele? Geeft ie dan een error op z'n query?

Nee, een error zou in sommige situaties nog fouter zijn dan feitelijk acties op je database uitvoeren, een (publiek zichtbare) error geeft namelijk informatie vrij over de structuur van je code en database, wat extreem ongewenst is. Stel dat ik via injection enkel INSERT User in jouw database weet te frotten. Vantevoren gokte ik dat die tabel er was, maar zodra de DB me terugmeldt dat ik mandatory fields UserName, Password, RegistrationDate en EmailAddress niet heb ingevuld weet ik hoe je halve database eruitziet en kan ik gericht gaan hacken. Sniefijn

mysql_real_escape_string en aanverwanten gebruik je om string values te escapen zodat er niet uit een string te ontsnappen is, in Janoz' eerste voorbeeld. In de tweede met de DELETE statement zit je niet binnen een string dus is deleteUser.php?id=1%20or%201 ook rampzalig al zou je escapen. In die gevallen zal je dus moeten checken of $_GET['id'] wel numeriek is voordat je de query uitvoert.

[kalechinees]

laat maar ik heb hem al
tussen query wordt gewoon als password gezien en geen records vinden...

Begin toch de mogelijkheden van PHP boven ASP/VBscript te zien zal ook maar even kijken naar
geparameteriseerde queries