Is 'cast' dangerous in user-submitted content in classic ASP?

The legacy web app I have inherited, which was custom-written for Oxfam New Zealand in classic ASP, runs a string replace on user-submitted inputs removing the string 'cast' presumably because of the cast function.

However this means that none of our participants can have a name or email address that contains that string. This is causing problems for someone with the surname Hardcastle.

This seems completely over the top security-wise - or at least there must be a way to ensure the user inputs are safe without changing the inputs of people with 'cast' in their name or email address.

The actual replace is done with:

strString = (Replace(strString, "cast", "", 1, -1, vbTextCompare))

I'm considering just commenting that line out, would that b开发者_如何转开发e safe to do?

The legacy app is doing it wrong.

Rather than filtering the content at the source, the content should be property encoded wherever it is used. In other words, if it's being used in a query, the value would be encoded prior to adding it to the SQL statement or better yet placed unmolested into a stored procedure parameter.

So yes, you can remove that code, but make sure strString is being used safely elsewhere.

I could change it to

strString = (Replace(strString, "cast(", "", 1, -1, vbTextCompare))

that way, you still get the "safety" of escaping the SQL, but won't aggravate users with cast in their names

This is actually an extremely ineffective way to prevent SQL injection attacks. There are 100 other words you would need to replace. The accepted answer is incorrect in that this does not retain the safety of this code, because there is no safety to begin with. The line with the "(" character would never execute if the hacker just added a space between CAST and (.

See this question on parameterized queries in classic asp. You never want to concatenate user supplied data to make a sql string. There are ways to do this without concatenation that are correct, but the code you currently have is useless. You might as well just remove that line.