Byta ut farliga tecken

voigtann1 skrev:

@nders kan inte ; göra saker? Har för mig jag läste om att man kunde tex:

SQL = "Select * from data;drop data"

då ta man ju bort "data" lagringen...

Det är riktigt att i vissa dbms kan man utföra mer än SQL-fråga i ett anrop. Men då skulle jag vilja fråga dig; hur får du dit semikolonet (eller radbrytningen, eller vad man använder för att separera sina statements)?

Litet utklipp från informativ webbplats:

8.0 How to avoid SQL Injection?
Filter out character like single quote, double quote, slash, back slash, semi colon, extended character like NULL, carry return, new line, etc, in all strings from:
- Input from users
- Parameters from URL
- Values from cookie

For numeric value, convert it to an integer before parsing it into SQL statement. Or using ISNUMERIC to make sure it is an integer.

Källa

Fina länkar:

SQLSecurity
4GuysFromRolla
Finfin Google-sökning

mvh

Vet inte om det är just ett vedertaget sätt att ändra ' till " men vill man fortfarande ha kvar tecknen som dom ser ut kan du ändra
' till & #39; och
" till & aqout;
(utan mellanrum)
Kan vara att de kanske inte är kompatibelt över alla teckenuppsättningar men då får man ändra efter behov

/Jonas

Vet inte om det är just ett vedertaget sätt att ändra ' till " men vill man fortfarande ha kvar tecknen som dom ser ut

Det är därför man ersätter en apostrof med två, för att lagra korrekt. Du ändrar ju ingenting, utan escapear bara tecknet i SQL-frågan så det lagras riktigt.

@nders: Ska man förenkla det så är det ju i stort sett allting som man hämtar med Request objektet som kan vara farligt. Alltså även t.ex. USER_AGENT och HTTP_REFERER.

När det gäller strängar så är det ju bara som sagt att byta ut ' mot ''. Men när det gäller t.ex. siffror, datum och booleans så kan det vara lite krångligare. Det kan vara bra att ta för vana att alltid göra om inparametrar till rätt dataformat. Alltså CLng för siffror, CDate för datum och CBool för booleans.
Då finns det ingen risk för att det kommer in nån konstig kod som ställer till det.

Erik Juhlin skrev:

@nders: Ska man förenkla det så är det ju i stort sett allting som man hämtar med Request objektet som kan vara farligt. Alltså även t.ex. USER_AGENT och HTTP_REFERER.

Ja, egentligen alla request-samlingar, dvs form, querystring, cookies och servervariables.

Mvh

En fin sak med att använda COM-objekt är att man där enkelt kan sätta datatyp för alla inparametrar. Då får man automatiskt ett skydd mot många slags SQL-injections. Exempel:

Public Function GetProduct(ByVal lProductId As Long) As ADODB.Recordset
	Set GetProduct = ExecuteSQL("SELECT * FROM tblProduct WHERE ProductId = " & lProductId
End Function

Ingen risk att någon skickar in typ "123;DROP TABLE tblProduct". :)

Calevan skrev:

det var det jag hade för mig, att det inte räcker, någon som kan ge oss förslag på åtgärder för att stoppa allt?

Jag skulle väl rösta för renholms förslag, d.v.s. att inte använda vanliga SQL-frågor utan parametriserade frågor, prepared statements. SQL-frågan blir dessutom enklare att läsa, och man kan i viss mån strunta i hur den lokala SQL-dialekten beter sig.

Ett tips på en svensk sida med mycket information om olika säkerhetsämnen är swesecure.com

Där hittar du bla. en artikel om vad SQL-injection är samt en om hur du kan använda parameteriserade frågor

Hur ser SQL-erna ut som körs mot databasen i en sån parametriserad fråga?

Som synes i fredriks länk så lägger man aldrig in värdena i SQL-strängen, de sätts in (på ett eller annat sätt) programmatiskt efteråt. Allt man gör är att byta ut värdet i sin SQL-sträng mot ett frågetecken, och sen säger man i sin kod därefter vad man vill att det EGENTLIGEN ska stå där. Man slipper escape:a strängar eller lista ut hur datumformat ska se ut. Dessutom kan man få en liten prestandavinst, åtminstone ska göra flera anrop till databasen där det bara är värden som byts ut och inte strukturen på själva frågan (t.ex. om man ska göra en bunt inserts i samma tabell, eller nåt).

Okej, den bygger alltså ihop en sån där EXEC pryl... :)