Är det möjligt att skydda sig mot "SQL injection" mha regex?

Om ja ..förslag?

Det går säkert fixa något bra mönster, men varför inte bara använda dej av parameteriserade frågor?

/Johan

Jag har hittat en sida som påstår att derar regex skall detektera sql injections ...

har testat följande UTAN att det fungerar ...
<code>
/\w*((\%27)|(\'))((\%6F)|o|(\%4F))((\%72)|r|(\%52))/ix
</code>

Sidan hittas på url : http://www.securityfocus.com/infocus/1768

Kommentarer önskas!

Något som du ska tänka på är att du kör replace på alla ' till " i dina textfält. Detta bara för att man inte ska kunna bryta mitt i en SQL:en.

Som Johan nämnde är det lämpligt att använda parametriserade frågor. Men jag rekommenderar att du ändå validerar det som matas in.

Jag är skeptisk till att det går att skriva ett och endast ett reguljärt uttryck som stoppar alla möjliga kombinationer av sql-injektioner. Det är ju i princip alltid bättre att säga exakt vad som är tillåtet än att säga vad som inte är tillåtet.

Om du har möjlighet att köra Enterprise Library så kan jag rekommendera det. Det ger dig riktigt bra möjligheter att bygga in olika kombinationer av validering på ett bra och lättsamt sätt.

http://msdn.microsoft.com/en-us/library/cc511619.aspx

Vad är skillnaden ?

<code>
SQLStmt = "SELECT ID, Name, State FROM Employee WHERE (ID=? AND State=?)"
cmd.CommandText = SQLStmt
lngID = 519
StrState = "CA"
Set rs = cmd.Execute (, array(lngID, strState))
...osv
</code>

<code>
lngID = 519
StrState = "CA"
SQLStmt = "SELECT ID, Name, State FROM Employee WHERE (ID= " & lngID & " AND State='" & StrState & "')"
...osv
</code>

Är det inte lika illa?


PS Vad är det för fel på denna regex? Den triggar på allt....
<code>
/\w*((\%27)|(\'))((\%6F)|o|(\%4F))((\%72)|r|(\%52))/ix
</code>

<b>>Är det inte lika illa?</b>
Ja, i det specifika fallet. Men i det specifika fallet behöver du inte bry dig om sql-injections öht.

sql-injections är ett problem när användaren skickar strängar. I det fallet är ditt först alternativ säkert mot sql-injections, men inte det andra.

Skickar du in strängen
'); DELETE FROM Employee; --

i den andra tömmer du hela tabellen, i den första får du bara ut "0 rader".


Sen finns det andra saker du bör kolla; XSS, om du hämtar ut strängar ur tabeller och använder dem för att bygga frågor dynamiskt, användning av strängar till systemanrop, som namn på filer osv. Vad det handlar om är att du måste hålla reda på vad användaren skickar in för strängar och hur de används, och sen hantera dem på rätt sätt. Parametriserade frågor hjälper mot den vanligaste formen av sql-injections (eller alla sql-injections om du använder det precis överallt).

Antingen kan du ju säga:

"Tillåt bara siffror." eller t.ex "Tillåt bara positiva tal." vilket är ganska trivialt.

Eller motsatsen:

"Tillåt inte bokstäver." och
"Tillåt heller inte ' tecken" och
"Tillåt för all del inte %27" och
"Tillåt för guds skull inte ..... "
etc.

Det är ju ganska enkelt att missa något som inte är tillåtet och det kan bli extremt komplext med många "Tillåt inte...".

Här är några triviala exempel som täcker upp det mesta och det går även att testa dem online:
http://www.regextester.com/regular%20expression%20examples.html

hur skriver man regex för "Tillåt inte DELETE" ...

Men Magnus...
1. Det absolut mest effektiva, enkla och snygga sättet att bli av med SQL injections är att använda parametriserade frågor genomgående där man hämtar strängar. Det finns nog med djupare problem för att stirra sig blind på sql-injections.
2. Vad skulle hända om någon verkligen skulle behöva skriva DELETE?
3. Vad betyder "Tillåt inte"? Vad du gör är att du använder ett regexp för att få ett ja/nej svar, och sen negerar du det. Då är ditt svar

.*DELETE.*

Och sen tillåter du det inte om du får ett ja-svar.

Men vad är det med parametriserade frågor som gör att sql injections plockas bort?

Någon som vet vad som händer inne i de "parametriserade frågorna"?

Kör Sql Profiler och kolla skillnaden på en parameteteriserad fråga och en utan. Med parameters använder ADO paramtetrar hela vägen ner till databasen.

De skickas i de flesta fall direkt till databasen "på sidan om". Databasen vet då att sära på data och kommando, vilket är det absolut säkraste sättet att säkra sig mot SQL-injections.
I de fall som den inte kan skicka data skilt till databasen kontrollerar den datatypen som angivits och om det är en sträng kör den en "escape" (i brist på bättre ord) på strängen för att säkra den.

Så, du ska använda parametrar, då behöver du inte längre tänka på säkerheten gällande SQL-injections.

<b>Så, du ska använda parametrar, då behöver du inte längre tänka på säkerheten gällande SQL-injections.</b>
<b>Om</b> man genomgående använder parametrar, även på ställen där man först hämtar ur databasen.

Alltså (okej, skumt exempel, skit samma):

FindSimilarNames(){
s = sql("SELECT Name FROM Employees WHERE ID = 1");
return sql("SELECT Name FROM SimilarNames WHERE Trait = '" + trait(s) + "'");
}

Är potentiellt farlig, även om man inte tar in strängar från användaren direkt.
Sen finns det som sagt en uppsjö andra attacker man ska kolla på.

En tidigare tråd om samma problem...

http://www.pellesoft.se/communicate/forum/view.aspx?msgid=268014

Ponera att vi vill kontrollera SQL-injektioner med regex ....
(inser att parametrisk frågeställning är bästa lösningen.. inser också regex begränsning.. men ändå)


Ingen fena på regex. men kan detta vara något som greppar klanthackare?
<code>
(?=.*delete.*)|(?=.*insert.*)|((\%27)|(\'))((\%6F)|o|(\%4F))((\%72)|r|(\%52))
</code>

Som du säger Niklas, ALL data måste gå igenom parametrar för att det ska vara säkert.

Gällande SQL-injections, det finns så många sätt man kan göra på. Att skriva till exempel strängen
<code>
'; DROP TABLE tabell;
</code>
i ett textfält som direkt skickas in i SQL frågan fungerar bara, vad jag vet, i MSSQL som kan ta flera frågor på en gång. MySQL kör bara första delen, vet inte hur Access gör.

En annan vanlig sträng man kan använda för att logga in som något konto är
<code>
' OR ''='
</code>

Varför man ens ska försöka hitta dessa försök med Regular Expressions förstår jag inte, finns ingen vits om man absolut inte vill logga dem för att sedan stämma hackaren ;-)

Jag inser fördelen med parametrisk hantering ... men ponera att det är det vi vill att just fånga hacken med regex.

Ni som innehar kunskapen vet Ni om hackaren skjuter in injektionen i hexaform?

<code>
(?=.*drop.*)|(?=.*delete.*)|(?=.*insert.*)|((\%27)|(\'))((\%6F)|o|(\%4F))((\%72)|r|(\%52))
</code>

Magnus, du kan lita på att hackaren kommer att försöka med precis allting.
Du har missat update, exec, xp_cmdshell .... etc etc .. listan kan göras lång om du vill upptäcka alla såna typer av kombinationer. :)

Bara att ösa på Samuel! Låt oss göra en regex så bra vi bara kan.

<code>
(?=.*update.*)|(?=.*exec.*)|(?=.*xp_cmdshell.*)|(?=.*drop.*)|(?=.*delete.*)|(?=.*insert.*)|((\%27)|(\'))((\%6F)|o|(\%4F))((\%72)|r|(\%52))
</code>

Okej. Det systemet som kommer om tre månader som inte är påtänkt än som är case-insensitive och använder kodorden:
ArNe
MAGnuS

Det är lönlöst. Det bästa du kan göra är att inte kolla på enskilda ord, utan att istället se till att inte släppa in strängar som innehåller tecken som avslutar sql-strängar, typ '. Låt säga att jag vill skicka in ordet drop, exec eller delete - ska jag inte få det då?

Problemet är att det inte är så enkelt ändå, du måste ibland tillåta det (Skicka in ordet "don't"), och beroende på lösning är det antingen omöjligt att släppa in det, eller enkelt att komma förbi det om man inte har mer komplicerade skydd. (Låt säga att du ersätter ' med '', då kan jag skriva \', som då ersätts med \'', och då betyder första att vi vill ha en escapad ', och det andra blir riktig, osv., osv.

Då återkommer vi till allra första lösningen, där vi slipper alla de här problemen.

Jag inser det nästa omöjliga i min önskan och strävan.

Men kan man göra mer än det en SQL-db klarar av?

Poera vi inte tillåter "drop", "delete" etc. Blir det lättare?

Föresten ... hur gör man med parametrisk teknik när man kör en insert, update eller delete ?

På samma sätt, överallt där du skulle skrivit ett värde ersätter du det med en parameter. Kolla denna artikeln, tyvärr bara exempel för SELECT, men principen är densamma.

http://www.pellesoft.se/area/articles/article.aspx?artid=815

/Johan

<b>>Jag inser det nästa omöjliga i min önskan och strävan.</b>
Äntligen! ;-)

<b>>Men kan man göra mer än det en SQL-db klarar av? </b>
<b>>Poera vi inte tillåter "drop", "delete" etc. Blir det lättare? </b>

Jag antar att du menar att "vi skulle kunna ta hand om alla nyckelord en databasmotor skulle kunna reagera på". Två problem:
1. Om vi inte ser till att få bort problem med "avslutande av strängar" så får vi fortfarande sjukt fula felmeddelanden under vissa situationer. Och lyckas vi få bort "avslutande av strängar" så behöver vi inte kolla på nyckelorden alls.
2. Vad strängar ska användas till är det bara den som skriver applikationen som vet. Det är därför jag hela tiden säger att sql-injections är första steget. Sen handlar det om att se till att inskickade strängar inte används fel efteråt heller; typexempel är om strängen ska användas i HTML, som filnamn, skickas till operativsystem på någon nivå, eller användas i något annat system som tar emot strängar. I de fallen handlar det återigen om samma sak: använd parametrisering om det finns. Annars är det att försöka escapa och krångla och hålla tummarna...

Exempel:

s = sql("SELECT a FROM tabell");
system("externt_program " + join(s));
externt_system("Find: " + join(s, ' '));
print_html("Messages: " + join(s, '\n'));

Om s innehåller något som ett operativsystem kan tolka och a kommer från användaren så kan första anropet ge användaren tillgång till vad som helst.
Om detta externa system anropas med strängar (säg, xml), så kan det andra anropet leda till problem.
Och om s skulle innehålla javascript, eller annat som en webbläsare kan tolka, så leder tredje anropet till katastrof (a.k.a XSS).

Inser men ger inte upp.

Ta en titt på svaret jag fick på en liknande fråga:
http://www.pellesoft.se/communicate/forum/view.aspx?msgid=269942&forumid=10&sum=0
Det kan verka krångligt men det är inte så svårt som det verkar. Tog mig bara någon timme att implementera i min applikation och har get mig mycket bättre kontroll över databasfrågorna.

Men hallå! Kanske är lite otydlig. Men jag vill verkligen ha hjälp med att utveckla en regex för att detektera så mycket injektioner som möjligt.

"[a-zA-Z1-9]*"
Allt som inte stämmer in med den strängen är en potentiell fara.