När man använder sig av numreriska värden som kommer från Request.Form eller Request.QueryString så bör man ta för vana att alltid använda CLng. Skulle det då vara ett tecken som inte är en siffra som kommer med så skulle det bli ett ASP-fel.
Om man använder dom här kontrollerna då borde man väl vara säker:
Function secure(txt)
txt = Replace(txt, "'", "''")
secure = txt
End Function
function killChars(strWords)
dim badChars
dim newChars
badChars = array("select", "drop", ";", "--", "insert",
"delete", "xp_")
newChars = strWords
for i = 0 to uBound(badChars)
newChars = replace(newChars, badChars(i), "")
next
killChars = newChars
end function
[B]SQL satsen[/B]
"INSERT INTO note (memb,note) VALUES('"& secure(Session("username")) &"','"& secure(killChars(Request.Form("note"))) &"')")"
Jag skulle personligen använda funktionen IsNumeric för att avgöra om det är ett tal eller inte, om inte så är fallet kan jag meddela klienten (som jag antar har skickat värdet i detta fallet) att han matat in ogiltiga värden. Min filosofi är att aldrig visa system-felmeddelanden för klienten.
Är det siffror kunden matar in själv så bör man göra en kontroll. Däremot så litar jag inte på IsNumeric efter som att det med den kan smyga sig in bokstäver.
Är det däremot id:n som kommer från QueryStringen så känns det löjligt att meddela användaren om att han matat in felaktiga siffror.
Bättre då att fixa en generell felhantering som visar upp ett vänligt felmeddelande till användaren och loggar det riktiga felmeddelandet.
Bosse; ang. strängvärden; eftersom du ersätter apostroferna först, så är du ju redan 'homerun' så att säga, eftersom utan dessa kan du inte 'escape':a ur strängvärdet. Då får de gärna skriva hur mycket DROP, --, DELETE eller pipes de vill, de hjälper ju inte ändå?
Viktigast är som sagt att se till att;
..numeriska värden antingen manglas genom isNumeric() eller typkonverteras med CInt() eller CLng().
..strängvärden kontrolleras och rensas från apostrofer och %.