Skydda sina script mot SQL Injections

Byt ut alla ' mot '', gärna med en funktion:

Function SQLSafe(str)
  str = Replace(str, "'", "''")
  SQLSafe = str
End Function

strNamn = SQLSafe(Request.Form("namn"))
'O.s.v...

Tackar, fungerar utmärkt.

Inga andra tecken som är bra att skydda emot för större säkerhet?

Klingstedt skrev:

Tackar, fungerar utmärkt.

Inga andra tecken som är bra att skydda emot för större säkerhet?

Nej, det ska räcka med '.

Nu när tråden finns uppe :P så tänkte jag fråga vad det är som är så farligt om man inte spärrar mot sånt? :o det enda är juhe felmeddelande i form av

Microsoft OLE DB Provider for ODBC Drivers error '80040e14'

[Microsoft][ODBC Microsoft Access Driver] Syntax error (missing operator) in query expression ''talala ' talalaaa, '2004-02-16 14:01', 1038, '194.237.241.xx')'.

/comx/forum/new_post.asp, line 48

Nån vänlig själ som kan förklara närmare med riskerna!

http://www.webforum.nu/showthread.php?s=&forumid=94&threadid=90222

Du kan nog söka lite mer på just 'injections' för att få mer info om detta.

1. Du exponerar eventuellt tabellnamn, kolumnnamn och data som finns i databasen för de som inte skall se den
2. I t.ex. SQLServer kan man använda ' för att göra mer än bara visa felmeddelanden, t.ex. radera tabeller, ändra data, visa data osv, eftersom du kan lägga flera olika typer av statements efter varandra

Om du använder MySQL som DBMS så bör du se till att strängen du ska mata in i databasen inte avslutas med ett \ (backslash). Då returneras ett felmeddelande på sql-frågan.

Vet dock inte hur det är med andra DBMS:er.

När vi är inne på ämnet: Behöver man byta ' mot '' när man lagrar data med t ex RecSet.Add i stället för INSERT? Vid INSERT får man väl fel om man skriver in ', det får man ju inte vid Add. Borde ju även betyda att man inte behöver en replace med Add.

Om det metoden är att föredra är en annan fråga. Med RecSet.Open Connect, SQL, 3,3

Vad har ni för fundelationer i ämnesomsättningen? :)

Vad har ni för fundelationer i ämnesomsättningen?

Ja, det är ju korrekt som du säger. Hela finessen med ADO-funktionerna är att isolera användaren från att behöva veta vilken databas som finns i botten och hantera escapning, typkonvertering och syntaxskillnader automatiskt.

Använder man explicita SQL:er så blir priset att man får göra såna saker själv och får kod som blir mindre flyttbar (vid byte av databas) och (eventuellt) osäkrare.

Riktigt illa blir det om man inte har satt rätt rättigheter på sin databas, då kan man från MS SQL Server med hjälp av Injections, skapa en ny användare och ge den användaren administratör behörigheter.

Efter det så står din SQL Server vidöppen för personen att logga in och göra vad han vill.

- M

http://www.sitepoint.com/article/794 hittade jag på nätet om detta..

Alla som håller på med databaser och webben borde läsa den guiden, om man inte redan läst den eller tillämpat allt som står.

Går även att styra en hel server med hjälp av SQL Injections om man har IIS. Riktigt äckligt!

Klingstedt skrev:

http://www.sitepoint.com/article/794 hittade jag på nätet om detta..

Alla som håller på med databaser och webben borde läsa den guiden, om man inte redan läst den eller tillämpat allt som står.

Går även att styra en hel server med hjälp av SQL Injections om man har IIS. Riktigt äckligt!

Det där var en mycket bra artikel. Och jag håller med dig Klingstedt - kör man webbserver ska man läsa den artikeln. Oavsett hur mycket man tror att man vet.

Kan man redan allting så 'mm'-ar man en hel del.
Kan man inte allt så blir man säkert paranoid och spärrar sönder servern först och öppnar lite försiktigt här och var.