[Alg/SQL] Input in query wordt hacked*

[Verwijderd]

Onlangs kreeg ik van een aardige hacker de volgende info.

Als hij inlogt op een site van mij en voert bij het naam veld het volgende in:

' or ''='' or ''='

Nou kun je dit dmv escape afvangen.

Mijn vraag is alleen waar ik dit het beste kan doen:
- Bij alle where-statements
- Bij alle updates en inserts
- SQL (acces) ASP

Als ik bij de select zeg: where name = ' & esacpe(request.form("Name")) & '
dan werkt het niet.

Wie o wie helpt mij uit de brand.

[whoami]

Wat je het beste kunt doen:

Geen gebruik maken van concatenation om je parameters in je queries te stoppen, maar gebruik maken van parameters of stored procedures.

Door gebruik te maken van parameters en/of stored procedures, worden zo'n dingen afgevangen.
als die 'hacker' dan die string intyped, dan wordt die string door het DBMS ook als string gezien, en wordt die ingegeven string niet aan de query geplakt als SQL statment.

Zie ook:
[rml]whoami in "[ SQL Server] Stored Procedure troubles*"[/rml]

[ Voor 54% gewijzigd door whoami op 29-07-2003 13:59 ]

[Verwijderd]

Maar sp's is momenteel niet te doen en concatenation werkt volgens mij niet bij acces databes. Misschien weet jij daar meer van?

[whoami]

Verwijderd schreef op 29 juli 2003 @ 14:00:
Maar sp's is momenteel niet te doen en concatenation werkt volgens mij niet bij acces databes. Misschien weet jij daar meer van?

Wat bedoel je met 'concatenation werkt niet icm access db's'?
Nu maak je je query op aan de hand van concatenation:

_C#:

code:

string sSQL = "SELECT * FROM tabel WHERE veldid = " + 1.ToString();

bv.

Als je het doet mbhv parameters (Access kan dat wel aan, je zult alleen even moeten opzoeken hoe je het precies doet in de taal die jij gebruikt), dan kan je al heel wat problemen vermijden:

_C#

code:

SqlCommand1.CommandText = "SELECT * FROM tabel WHERE veld = @p_veld";
SqlCommand1.Parameters.Add ("@p_veld", SqlDbType.Integer);
SqlCommand1.Parameters["@p_veld"].Value = 1;

_Delphi

code:

Query1.SQL.Text := 'SELECT * FROM tabel WHERE veld = :p_veld';
Query1.ParamByName ('p_veld').AsInteger := 1;
Query1.Open();

Ik geloof dat het met ASP kan dmv vraagtekens in je query te zetten, zoiets als:

code:

SELECT * FROM tabel WHERE veld = ?

Hoe je die parameter dan opvult in ASP weet ik wel niet zo direct.

[ Voor 10% gewijzigd door whoami op 29-07-2003 14:09 ]

[Verwijderd]

Ik gebruik vbscript in asp formaat zeg maar. En naar mijn weten kun je in acces geen sp's gebruiken. Verder worden er al standaard componenten gebruikt.
Eigenlijk zoek ik naar een oplossing om enkele qoutes die de client invoerd op te kunnen slaan zonder dat ik hier conversies voor hoef uit te voeren.

Ik werk nu als volgt:
strNaam = "cbi's"
Replace(strNaam," ' "," '' ")
dit is dus niet hackproef in de select:
"select * from tabel where naam = ' " & strNaam & " ' "

Het mooiste zou zijn als er iets bestond als
"select * from tabel where naam = '[ " & strNaam & " ]' "

Het is alleen vrij lastig sql documentatie te vinden, welke werkt op een acces database.

[justmental]

In de inhoudelijke P&W FAQ staat ook een mooie uitleg over dit onderwerp:
P&W FAQ - Hoe beveilig ik een website?

[whoami]

Verwijderd schreef op 29 July 2003 @ 14:13:
Ik gebruik vbscript in asp formaat zeg maar. En naar mijn weten kun je in acces geen sp's gebruiken. Verder worden er al standaard componenten gebruikt.
Eigenlijk zoek ik naar een oplossing om enkele qoutes die de client invoerd op te kunnen slaan zonder dat ik hier conversies voor hoef uit te voeren.

Je hoeft ook geen stored procedures te gebruiken. Maak gewoon gebruik van parametrized queries. Dan moet je je helemaal niks aantrekken van zelf quotes rond bepaalde waarden te zetten, en rond andere niet, Access doet het dan allemaal voor jou.

klik eens hier

[ Voor 11% gewijzigd door whoami op 29-07-2003 14:17 ]

[Verwijderd]

Thx,

Hier moet ik verder mee komen.

[ Voor 7% gewijzigd door Verwijderd op 29-07-2003 14:19 ]

[sh4d0wman]

niet zo veel verstand van asp maar toch nog een tip. zoek met google eens op SQL Injection. krijg je veel tips hoe dit is tegen te gaan.

[dream0r]

Ik doe het altijd als volgt: (php)

$qry = "SELECT * FROM tabel WHERE username = '".$_POST["username"]."'";

Dan een while waarin de $_POST["password"] vergeleken wordt met het password wat hij selecteerd in de query bij de bijbehorende user. Als die matched, inloggen.

[whoami]

Je kan veel beter direct de juiste row uitlezen.
Dus, een query doen op zowel username en (encrypted) password.

(+ gebruik maken van parameters ipv string concat)

[dream0r]

(+ gebruik maken van parameters ipv string concat)

Ik heb geen idee hoe je dat zou moeten interperteren met php. Kan iemand me opweg helpen ?

[bigtree]

whoami schreef op 29 July 2003 @ 14:35:
Je kan veel beter direct de juiste row uitlezen.
Dus, een query doen op zowel username en (encrypted) password.

(+ gebruik maken van parameters ipv string concat)

Zo weet je alleen niet of het een foute username of een fout password was. Soms wil je dat weten om een account bij x foute pogingen op een dag tijdelijk dicht wilt zetten.

[whoami]

Skizzik schreef op 29 juli 2003 @ 14:37:
[...]


Ik heb geen idee hoe je dat zou moeten interperteren met php. Kan iemand me opweg helpen ?

Google?

[Verwijderd]

Bedenk bovendien ook dat "geparametriseerde queries" je queries ook makkelijker te lezen maken (omdat je niet al het concatenation textuele overhead hebt). Dus besteed er zeker aandacht aan om eens te kijken hoe je dat kan gebruiken en merk dan op dat je in diverse "omgevingen" dezelfde constructie tegenkomt.

[ Voor 7% gewijzigd door Verwijderd op 29-07-2003 16:21 ]

[_js_]

Verwijderd schreef op 29 July 2003 @ 14:13:
Ik werk nu als volgt:
strNaam = "cbi's"
strNaam = Replace(strNaam," ' "," '' ")

dit is dus niet hackproef in de select:
"select * from tabel where naam = ' " & strNaam & " ' "

Zo is het wel hackproef.

Als je niet zoveel regels wilt moet je replace in de sql string zetten.

[simon]

Skizzik schreef op 29 July 2003 @ 14:32:
Ik doe het altijd als volgt: (php)

$qry = "SELECT * FROM tabel WHERE username = '".$_POST["username"]."'";

Dan een while waarin de $_POST["password"] vergeleken wordt met het password wat hij selecteerd in de query bij de bijbehorende user. Als die matched, inloggen.

ik doe dus meteen

PHP:

$qry = "
   SELECT
      *
   FROM
      table 
   WHERE username = '" . $_POST["username"] . "' 
      AND password = '" . md5($_POST["password"] . "'";

Scheelt weer werk.

Daarnaast kun je niet gewoon escapen ipv vervangen? Dan blijft die naam nog kloppend.. Ikzelf vind het altijd brak als de invoer zoveel anders (sommige gevallen daargelaten) dan de uitvoer

[ Voor 13% gewijzigd door simon op 30-07-2003 09:33 ]

[whoami]

Ik blijf het herhalen:

Gebruik de tools en technieken die er voor handen zijn: de topicstarter maakt gebruik van ASP en Access, en daar is het perfect mogelijk om gebruik te maken van parametrized queries.
Je moet dus helemaal niet zitten prutsen met concatenatie van strings om je query op te bouwen. Door concatenatie wordt je code onduidelijk, en minder performant.

[Janoz]

Simon schreef op 30 July 2003 @ 09:32:
[...]


ik doe dus meteen

PHP:

$qry = "
   SELECT
      *
   FROM
      table 
   WHERE username = '" . $_POST["username"] . "' 
      AND password = '" . md5($_POST["password"] . "'";

Scheelt weer werk.

Daarnaast kun je niet gewoon escapen ipv vervangen? Dan blijft die naam nog kloppend.. Ikzelf vind het altijd brak als de invoer zoveel anders (sommige gevallen daargelaten) dan de uitvoer

Alles leuk en aardig, maar heir heb je exact hetzelfde probleem als de TS. Dat het hier misschien wel veilig gaat komt door de magic quotes settings van php..

[Verwijderd]

Simon schreef op 30 July 2003 @ 09:32:
[...]


ik doe dus meteen

PHP:

$qry = "
   SELECT
      *
   FROM
      table 
   WHERE username = '" . $_POST["username"] . "' 
      AND password = '" . md5($_POST["password"] . "'";

Scheelt weer werk.

Daarnaast kun je niet gewoon escapen ipv vervangen? Dan blijft die naam nog kloppend.. Ikzelf vind het altijd brak als de invoer zoveel anders (sommige gevallen daargelaten) dan de uitvoer

Ik zou het dan zo doen

PHP:

$qry = "
   SELECT
      *
   FROM
      table 
   WHERE username = '" . mysql_escape_string($_POST["username"]) . "' 
      AND password = '" . mysql_escape_string(md5($_POST["password"]) . "'";

Dit is tamelijk eenvoudig, omdat ik een sql_select functie in een mysql class heb .

[Verwijderd]

Nog een leuke, wanneer een ASP-site gebruik maakt van SQL-server en de (numerieke) queries worden niet goed ge-escaped (vergeet ; niet!!!) zou je via de querystring een stukje query kunnen meegeven... Als de dbadmin niet zo strak op authentication let is het eenvoudig om stored-proc's uit de masterdatabase te gebruiken, waaronder xp_cmdshell.
Kortom; volledig systeem open en bloot.
Voorbeeldje:
http://www.url.com/default.asp?id=1;EXEC master.xp_cmdshell "format c:\"

Raar genoeg is dit erg vaak mogelijk op sites, een heleboel webmasters zullen in hun c-root een file vinden "i-was-here.txt". It wasn't me!
Truukje is al wat ouder, ik heb hier 3 jaar geleje al last van gehad (en last mee bezorgd).

[whoami]

Tja, als je gebruik maakt van stored procedures of parametrized queries, dan zou bovenstaande zowiezo al niet mogelijk kunnen zijn.
Bovenstaande is mogelijk doordat de query opgebouwd wordt dmv concatenatie.

Bv:

code:

sSQL = 'SELECT * from tabel WHERE veldid = ' & Request.QueryString(0)

Dan krijg je (bij bovenstaand voorbeeld idd:

code:

SELECT * from tabel WHERE veldid = 1;EXEC master.xp_cmdshell ...

Door gebruik te maken van parametrized queries of SP's, zal die xp_cmdshell SP niet uitgevoerd worden.

(Trouwens, numerieke queries kan je (mag je) zowiezo niet escapen).
Dit bv:

code:

SELECT * FROM tabel WHERE id = 1

is niet hetzelfde als:

code:

SELECT * FROM tabel WHERE id = '1'

[Verwijderd]

true, maar met escapen bedoel ik voornamelijk controle op datatypes, verwijderen van ' (bij strings) en ;
Daar heb je zo een functie voor inelkaar geklopt.. Maar goed, je zal toch sneller stored-proc's willen gebruiken, al is het alleen al om de scalability en performance-winst bij grotere queries.

[Crazy D]

Bij numerieke waardes in een query moet je er sowieso voor zorgen dat ze numeriek zijn. Niet alleen de ; niet vergeten, maar gewoon alles wat niet 0-9 is moet eruit (of afkeuren en dus de query niet uitvoeren)...
En de ' moet je niet verwijderen, maar escapen (van een enkele ' er dus 2 maken...). Dan maakt een ; ook niet meer uit (en tis ook lullig als je net een ; in een wachtwoord hebt staan ), omdat het geheel een string is ("where username = 'blah';exec iets_fouts" wordt dan "where username = 'blah'';exec iets_fouts'" (na blah staan dus 2 ' tekens) en dat kan dan weer geen kwaad.