The person(s) behind this appears to realise that he/she/they need to adapt as measures are taken to prevent these attacks. I wouldn't rely on any one single method to stop this and I wouldn't be surprised if it's back again soon in a different guise.
Check all input from your websites (URL parameters, Form data, cookie data etc)
Close up the holes in the code that allows this through. (Use parameter objects)
Revoke all unnecessary permissions (sys.Tables, syscolums, syscomments, INFORMATION_SCHEMA views etc)
Do not allow your website user accounts to make schema changes.
Do not allow your websites access to your databases with sysadmin or DBO rights.
There are probably more things that I've missed but this is a good start and I've rarely seen a site that has done all this.
Hi, A Sys Admin account in MS SQL give you access to all databases and gives you all privileges. So basically you don't need any other rights. I'm not sure if a Windows Admin account has admin right in MS SQL. I believe you need to add the Windows Account to
MS SQL and grant that account proper permissions. If you were able to create a new sql login with SysAdmin privileges, then you probably had SysAdmin. Each database has a "permission admin" role which allow a sql user to grant permission. Remember, a sql login
grant access at the database level (except for server roles like sysAdmin). You need to grant that sql login access to each database you want that sql login to access to. If you grant DBO rigth to a sql login to a database, that sql login becomes a user in
the database. DBO rights is the highest level in a database (not database server). So you'll get creater, alter, grant, select etc... for all DB objects (view, stored proc, etc...). Security in MS SQL can get complicated. That's why it's important to involve
a DBA when you're not sure. People tend to grant DBO rights because it's the easiest way. You then pay the price later. Luckily the script did not try to create tables, stored proc... Dont hesitate if you have questions
Flackie
Ok I think i got it working (for one site anyway, others should be simple now). I ended up creating a new admin login for myself and then using that to go into the SQL management so i knew i had full admin rights. I made sure I gave myself permissions for
all the sites I need to change and then ran the code and it worked without error.
I then made sure it worked and does deny access by running this using the web back end of the site (which uses the ASP user account for this site):
SELECT * from sysobjects
Previously this returned full results, now it returns nothing - so that seems to be job done as far as this part goes.
Thanks eftennis and davidreabow for your comments, these helped me greatly.
Everyone should use parameter objects whether you use stored procedures or not. It is probably one of the most important things to do when protecting yourself from SQL Injection.
But then I started getting too many false alarms due to google's search.
I is doing many sorts of phrases that include many of the words that are notallowed.
So I made a change to the verify function
function verify(s)
'convert the querystring to lowercase
s = lcase(s)
risk_level_counter = 0
' badwords - a list of disallowed keywords in the url
badwords= "select 1=1 insert update delete drop -- table alter cast declare convert exec chr( union"
' create an array list of each back word
r = split(badwords, " ")
' loop through the bad words and return false if it is present.
for i =0 to ubound(r)
if instr(s, r(i)) > 0 then
risk_level_counter = risk_level_counter + 1
end if
next
if risk_level_counter >= 2 then
verify = false
else
verify=true
end if
end function
I think that I am going to give a uniqe level of risk to each word, for instance giving 3 for DECLARE, UPDATE , DROP and a level of 1 to select.
I would also combine the checks with the length of the string not allowing more than 150 characters for a known need.
I'm going to suggest an alternative to the "find bad words and redirect" solution. This may not work for everyone but will hopefully break any attempts to inject SQL.
You should still search for the "bad" words but when you find them, instead of redirecting to another page, you should replace them with the same word and a character.
So if you find the words "Select" or "Declare", simply replace them with "Select," or "Declare,". By inserting a "," it should be sufficient to break the sql statement and not allow it to run.
This should also help where sites do pass valid text data that may contain these words.
Replace "--" with "-,-". This will break the comment.
Also if valid data is identified as a false positive, rather than redirecting your user it just looks like a "typo" error if the data is stored and displayed.
This will also be friendly towards things like fulltext searches.
SELECT
ON [INFORMATION_SCHEMA].[TABLES]
TO [Public]
DENY
SELECT
ON [INFORMATION_SCHEMA].[COLUMNS]
TO [Public]
DENY
SELECT
ON [INFORMATION_SCHEMA].[VIEW_COLUMN_USAGE]
TO [Public]
DENY
SELECT
ON [INFORMATION_SCHEMA].[CONSTRAINT_COLUMN_USAGE]
TO [Public]
DENY SELECT
ON [INFORMATION_SCHEMA].[COLUMN_PRIVILEGES]
TO [Public]
GO
-------------------------------------------------------------------------------------- Your Database --------------------------------------------------------------------------------
use [Your_Database_name]
GO
DENY
SELECT
ON [sys].[columns]
TO [Your_User]
DENY
SELECT
ON [sys].[tables]
TO [Your_User]
DENY
SELECT
ON [sys].[syscolumns]
TO [Your_User]
DENY
SELECT
ON [sys].[sysobjects]
TO [Your_User]
DENY
SELECT
ON [sys].[objects]
TO [Your_User]
DENY SELECT
ON [sys].[syscomments]
TO [Your_User]
GO
I have also revoked all insert/update/delete permission from tables where the account does not need them.
You may also want to deny permission on CREATE statements.
Would it work to use the CInt function to test the ID that's passed to confirm that it is an integer between -32767 and 32767? It seems like that would force an error given the length and alpha characters that are in the script.
I would still suggest using parameter objects. There are two main reasons for this;
1. You can set the data type of the parameter object and achieve the same "error checking" as you would with CInt.
2. SQL Server treats parameters slightly different to executing a single "string" statement. When a string is executed it is first interpreted or it has to be "prepared" by SQL server for execution and any mal formed character strings that can be interpreted
as executable will be executed. When parameter are passed into a statement they are treated a parameters and mal formed data is not executed.
This takes care of the interface between your development language and SQL Server. I have seen Stored Procedures that take character strings and within the stored procedure build Dynamic SQL statments. If anyone is doing this you are in danger of being attacked
the same way within your SP. This is particularly true where the SP accepts large character strings. To fix this you can also use parameters within TSQL (also known as prepared statements).
I know it isn't always possible as some applications will have to accept long strings but where possible you should also limit the length of your character data.
A combination of many of the previously mentioned solutions would be best. All you really need to achieve is to "break" the execution of the malicious code. Some people have mentioned detecting specific strings from this attack and acting on that. The problem
with this approach is that the attacker could easily change something, All he/she/they need to do is add an extra %20 and your detection will fail.
I still believe that one of the most important things is to use parameter objects at your code level and paremeters (prepared statements) within your SP's.
In my situation, most of the input should not have a ' or a ; in it at all, so I just filter that out completely when those characters are not expected. I place an include with the following code at the top of almost every page.
<%
str = request.servervariables("QUERY_STRING")
if instr(str, ";") then response.redirect("/404msg.asp")
str = Request.Form
if instr(str, ";") then response.redirect("/404msg.asp")
str = request.servervariables("QUERY_STRING")
if instr(str, "--") then response.redirect("/404msg.asp")
str = Request.Form
if instr(str, "--") then response.redirect("/404msg.asp")
str = request.servervariables("QUERY_STRING")
if instr(str, "'") then response.redirect("/404msg.asp")
str = Request.Form
if instr(str, "'") then response.redirect("/404msg.asp")
%>
This won't work for everyone, but if you know for sure that a ' or ; or a -- should not be in the input, just kill it before it goes anywhere.
This code checks both GET and POST (i.e. parameters in the URL or submitted from a form) and can be used as a preemptive filter before it even gets to the rest of the code.
Obviously this is not the only thing you should do, but it may be a quick way to kill certain attacks. Combine this with proper sanitizing of variables, and it makes your site more difficult to attack.
lillyg
Would it work to use the CInt function to test the ID that's passed to confirm that it is an integer between -32767 and 32767? It seems like that would force an error given the length and alpha characters that are in the script.
That should definitely be used for checking integers. But depending on the application, not all parameters may be integers.
sql injection injection filter code asp cint integers
DavidReabow
10 Posts
Re: Anyone know about www.nihaorr1.com/1.js?
May 13, 2008 01:53 PM|LINK
The person(s) behind this appears to realise that he/she/they need to adapt as measures are taken to prevent these attacks. I wouldn't rely on any one single method to stop this and I wouldn't be surprised if it's back again soon in a different guise.
Check all input from your websites (URL parameters, Form data, cookie data etc)
Close up the holes in the code that allows this through. (Use parameter objects)
Revoke all unnecessary permissions (sys.Tables, syscolums, syscomments, INFORMATION_SCHEMA views etc)
Do not allow your website user accounts to make schema changes.
Do not allow your websites access to your databases with sysadmin or DBO rights.
There are probably more things that I've missed but this is a good start and I've rarely seen a site that has done all this.
Hope this helps.
David
greenlit_des...
3 Posts
Re: Anyone know about www.nihaorr1.com/1.js?
May 13, 2008 03:09 PM|LINK
Sql injection filter MS SQL security sql login
DavidReabow
10 Posts
Re: Anyone know about www.nihaorr1.com/1.js?
May 13, 2008 03:50 PM|LINK
I've been looking for a good tutorial on using parameters to pass on to some developers and found this:
http://weblogs.sqlteam.com/jeffs/archive/2006/07/21/10728.aspx
Everyone should use parameter objects whether you use stored procedures or not. It is probably one of the most important things to do when protecting yourself from SQL Injection.
csraodel
1 Post
Re: Anyone know about www.nihaorr1.com/1.js?
May 14, 2008 07:13 AM|LINK
Do a complete server side data validation on your forms.validation
drors01
1 Post
Re: Anyone know about www.nihaorr1.com/1.js?
May 15, 2008 10:12 AM|LINK
Hi,
I added the url filter to my site just in case...
But then I started getting too many false alarms due to google's search.
I is doing many sorts of phrases that include many of the words that are notallowed.
So I made a change to the verify function
function verify(s)
'convert the querystring to lowercase
s = lcase(s)
risk_level_counter = 0
' badwords - a list of disallowed keywords in the url
badwords= "select 1=1 insert update delete drop -- table alter cast declare convert exec chr( union"
' create an array list of each back word
r = split(badwords, " ")
' loop through the bad words and return false if it is present.
for i =0 to ubound(r)
if instr(s, r(i)) > 0 then
risk_level_counter = risk_level_counter + 1
end if
next
if risk_level_counter >= 2 then
verify = false
else
verify=true
end if
end function
I think that I am going to give a uniqe level of risk to each word, for instance giving 3 for DECLARE, UPDATE , DROP and a level of 1 to select.
I would also combine the checks with the length of the string not allowing more than 150 characters for a known need.
Thanks
DavidReabow
10 Posts
Re: Anyone know about www.nihaorr1.com/1.js?
May 15, 2008 11:28 AM|LINK
Hi everyone,
I'm going to suggest an alternative to the "find bad words and redirect" solution. This may not work for everyone but will hopefully break any attempts to inject SQL.
You should still search for the "bad" words but when you find them, instead of redirecting to another page, you should replace them with the same word and a character.
So if you find the words "Select" or "Declare", simply replace them with "Select," or "Declare,". By inserting a "," it should be sufficient to break the sql statement and not allow it to run.
This should also help where sites do pass valid text data that may contain these words.
Replace "--" with "-,-". This will break the comment.
Also if valid data is identified as a false positive, rather than redirecting your user it just looks like a "typo" error if the data is stored and displayed.
This will also be friendly towards things like fulltext searches.
DavidReabow
10 Posts
Re: Anyone know about www.nihaorr1.com/1.js?
May 16, 2008 05:08 PM|LINK
Hi all,
Here are some "DENY" permission scripts I have used. I'd advice you to check that they don't break your applications/websites before using them.
-------------------------------------------------------------------------------------- Master -------------------------------------------------------------------------------------------
use [Master]GO
DENY
SELECT ON [INFORMATION_SCHEMA].[TABLES] TO [Public]DENY
SELECT ON [INFORMATION_SCHEMA].[COLUMNS] TO [Public]DENY
SELECT ON [INFORMATION_SCHEMA].[VIEW_COLUMN_USAGE] TO [Public]DENY
SELECT ON [INFORMATION_SCHEMA].[CONSTRAINT_COLUMN_USAGE] TO [Public] DENY SELECT ON [INFORMATION_SCHEMA].[COLUMN_PRIVILEGES] TO [Public]GO
-------------------------------------------------------------------------------------- Your Database --------------------------------------------------------------------------------
use [Your_Database_name]GO
DENY
SELECT ON [sys].[columns] TO [Your_User]DENY
SELECT ON [sys].[tables] TO [Your_User]DENY
SELECT ON [sys].[syscolumns] TO [Your_User]DENY
SELECT ON [sys].[sysobjects] TO [Your_User]DENY
SELECT ON [sys].[objects] TO [Your_User] DENY SELECT ON [sys].[syscomments] TO [Your_User]GO
I have also revoked all insert/update/delete permission from tables where the account does not need them.
You may also want to deny permission on CREATE statements.
lillyg
1 Post
Re: Anyone know about www.nihaorr1.com/1.js?
May 18, 2008 10:08 PM|LINK
Would it work to use the CInt function to test the ID that's passed to confirm that it is an integer between -32767 and 32767? It seems like that would force an error given the length and alpha characters that are in the script.
DavidReabow
10 Posts
Re: Anyone know about www.nihaorr1.com/1.js?
May 18, 2008 10:38 PM|LINK
Hi Lilly,
I would still suggest using parameter objects. There are two main reasons for this;
1. You can set the data type of the parameter object and achieve the same "error checking" as you would with CInt.
2. SQL Server treats parameters slightly different to executing a single "string" statement. When a string is executed it is first interpreted or it has to be "prepared" by SQL server for execution and any mal formed character strings that can be interpreted as executable will be executed. When parameter are passed into a statement they are treated a parameters and mal formed data is not executed.
This takes care of the interface between your development language and SQL Server. I have seen Stored Procedures that take character strings and within the stored procedure build Dynamic SQL statments. If anyone is doing this you are in danger of being attacked the same way within your SP. This is particularly true where the SP accepts large character strings. To fix this you can also use parameters within TSQL (also known as prepared statements).
I know it isn't always possible as some applications will have to accept long strings but where possible you should also limit the length of your character data.
A combination of many of the previously mentioned solutions would be best. All you really need to achieve is to "break" the execution of the malicious code. Some people have mentioned detecting specific strings from this attack and acting on that. The problem with this approach is that the attacker could easily change something, All he/she/they need to do is add an extra %20 and your detection will fail.
I still believe that one of the most important things is to use parameter objects at your code level and paremeters (prepared statements) within your SP's.
Regards
David
wistex42
1 Post
Re: Anyone know about www.nihaorr1.com/1.js?
May 20, 2008 05:03 AM|LINK
In my situation, most of the input should not have a ' or a ; in it at all, so I just filter that out completely when those characters are not expected. I place an include with the following code at the top of almost every page.
<%
str = request.servervariables("QUERY_STRING")
if instr(str, ";") then response.redirect("/404msg.asp")
str = Request.Form
if instr(str, ";") then response.redirect("/404msg.asp")
str = request.servervariables("QUERY_STRING")
if instr(str, "--") then response.redirect("/404msg.asp")
str = Request.Form
if instr(str, "--") then response.redirect("/404msg.asp")
str = request.servervariables("QUERY_STRING")
if instr(str, "'") then response.redirect("/404msg.asp")
str = Request.Form
if instr(str, "'") then response.redirect("/404msg.asp")
%>
This won't work for everyone, but if you know for sure that a ' or ; or a -- should not be in the input, just kill it before it goes anywhere.
This code checks both GET and POST (i.e. parameters in the URL or submitted from a form) and can be used as a preemptive filter before it even gets to the rest of the code.
Obviously this is not the only thing you should do, but it may be a quick way to kill certain attacks. Combine this with proper sanitizing of variables, and it makes your site more difficult to attack.
That should definitely be used for checking integers. But depending on the application, not all parameters may be integers.
sql injection injection filter code asp cint integers