[WeaZear]

När jag använder replace koder i ASP för att sortera bort känsliga tecken för att skydda mina inputs mot SQL Injections har jag märkt att replace koderna är Case Sens... Jag kom på ett sätt att få bort det, genom att göra om texten som skall rensas till Lower Case, dock ser det stört ut på profilerna etc, när man itne kan skriva med versaler.

Någon som vet något bra sätt att göra replace inte case sens?

[jonny]

Vad är det du letar efter då? Borde det inte vara tillräckligt safe att bara leta efter specialtecken?

[WeaZear]

Jo de klart, men tänkte på typ DROP, TRUNCATE och sådana.

[Clarence]

"update profiler set text='TRUNCATE users' where id=5" gör inget annat än uppdaterar profiltexten till "TRUNCATE users". Så länge du rensar de relevanta specialtecknena så är du säker från injicerad SQL.

[Jonas]

Du bör nog hellre skydda dig emot detta på Serversidan istället. Alltså i MySQL, har du tillgång till MySQL användar hanterare så gör enbart så att ditt konto du skall använda live enbart kan göra det du behöver: SELECT, UPDATE, INSERT & kanske DELETE.

[scrdj]

Det är väl bra enkelfnuttar och backslash du behöver skydda dig emot?
Gör en replace där dessa blir samma tecken x 2 bara.

[Vimp]

Det där är ett helt värdelöst skydd. Det enda sättet att skydda sig på är genom att köra med ADODB.Command och parametrar.

Kika här:
http://www.aspsidan.se/default.asp?p...d=5&pId=562673

Du bör även använda stored procedures och inte bara vanliga sql-injections på sidan. Då kan du genom dem ange direkt vilken kod som ska köras och samtidigt få all sql-kod på samma plats, vilket underlättar om du hittar något fel.

[WeaZear]

Originally posted by Vimp@Jun 21 2008, 23:46
Det där är ett helt värdelöst skydd. Det enda sättet att skydda sig på är genom att köra med ADODB.Command och parametrar.

Kika här:
http://www.aspsidan.se/default.asp?p...d=5&pId=562673

Du bör även använda stored procedures och inte bara vanliga sql-injections på sidan. Då kan du genom dem ange direkt vilken kod som ska köras och samtidigt få all sql-kod på samma plats, vilket underlättar om du hittar något fel.

Men om jag replacar ; mot typ / och () mot /, borde man inte vara skyddad mot den typen av SQL Injections?

Dock såg detta ut att kunna lösa problemet:

Const adVarChar = 200
Const adParamInput = 1

cmd = Server.CreateObject("ADODB.Command")
Set cmd.ActiveConnection = conn
cmd.CommandText = "SELECT * FROM Users WHERE Username = ?"
cmd.Parameters.Append cmd.CreateParameter("Username", adVarChar, adParamInput)

cmd.Parameters("Username") = "Tant102"

[Vimp]

Originally posted by WeaZear@Jun 22 2008, 09:41

Const adVarChar = 200
Const adParamInput = 1

cmd = Server.CreateObject("ADODB.Command")
Set cmd.ActiveConnection = conn
cmd.CommandText = "SELECT * FROM Users WHERE Username = ?"
cmd.Parameters.Append cmd.CreateParameter("Username", adVarChar, adParamInput)

cmd.Parameters("Username") = "Tant102"

Där används ADODB.Command, vilket är rätt sätt att lösa det på. Genom att använda parametrar (helst i samband med stored procedures) så är man automatiskt helt skyddad mot SQL Injections.