Forum Moderators: open
[edited by: jatar_k at 4:44 pm (utc) on May 5, 2008]
[edit reason] no specifics thnks [/edit]
What you need to be fixing is the "forms handler" script/program to which the form data is sent. That is what is allowing the malicious SQL commands to slip through.
All other ASP scripts should be checked, too.
At every location where input is received from a user, that input has to be "sanitized" before it is used for any purpose.
If you are using Asp.Net the following link may be of use to you.
How To: Protect From SQL Injection in ASP.NET [msdn.microsoft.com]
If someone can get code injected into your site that gives them the needed permissions for "write access" (i.e. modify, add, or delete files), they basically can do anything to the site they want.
Any form could potentially allow malicious code to be injected, but remember it's not the form. It's whatever program the data is sent to when the user clicks the Submit button.
Pages that don't contain forms can be vulnerable, too. I expect that ASP must have the same potential for "Remote File Inclusion" vulnerabilities that PHP has.
The basic rule is: ALL data provided by the user (including the HTTP request itself, such as in a query string) is potentially malicious, and your application must never use that untrusted data without first sanitizing/cleaning/scrubbing it (all of those being terms used for the process).
So, for example, your search function could indeed be vulnerable (assuming it's not a standard Google/Yahoo-provided Search This Site box). The user enters a search string. Depending on how your search script handles the string and performs the search, they could theoretically enter a search string that tricks the program into giving them access to your site.
You or your programmer should read carefully the article Ocean10000 linked to. If you don't understand it or the techniques it describes, the safest course would be to remove the forms from your pages, delete or rename the forms handler scripts that you're using, and read about SQL injection. Don't allow any user input until you fully understand the hazards and how to protect the site.
[edited by: SteveWh at 4:10 am (utc) on May 7, 2008]
if you have been sql injected, then it only affects the database table fields that have been written to/overwritten, updated etc.
however of course if you are writing your pages dynamically with data drawn from the database of course your pages could easily be affected (this is the point for most hackers as well as trying to steal sensitive information)
Our hosting company configured such an account and it couldn't select tables (or so the error said) and after a day of checking things they said we needed to change our SELECT statements to specify the database and owner account directly in order to access this.
Example:
Old query string:
oRs.Source = "SELECT DISTINCT [slu].[state], [slu].[stateLong] FROM [tblStateLookup] [slu]...
New query string:
oRs.Source = "SELECT DISTINCT [slu].[state], [slu].[stateLong] FROM [dbdeckard].[acct567x].[tblStateLookup] [slu], ...
Question - is this really the easiest way to do this? We have HUNDREDS of lines of code that would have to be updated.
Any better ideas?
Have you checked to see if the connection string specifies the new user name and database name correctly ?
Then, the next step would be to get a developer who doesn't leave the site vulnerable to SQL injection.
Finally, why wouldn't you use stored procedures in ms sql? It will make your code far more maintainable and likely reduce a lot of redundant code.
As far as blaming the host for not keeping up on patches, no patch is going to stop the SQL injection. This was a result of the poorly written ASP code by your developer.
That gives a "breathing space" in which the stored procedures can be written , and , I suggest, called usng parameters not variables.
Note that the SQL injections I have seen are actually in binary...
