SQL Injection and DB user permissions
Randy
I have actually taken it down after reading articles posted here and
elsewhere, since it contains quite a bit of 'dynamic sql' and I KNOW that
it' FULL of vulnerabilities to SQL Injection attach. I decided not to wait
around for this to happen and I'm working to 'harden' it.
So this is probably a stupid question and, no doubt, there is a concept that
I am not grasping.
But, since my site is purely informational, and, (by intention at least)
only allows the user to search and display the data, I would THINK, that
employing a database user in the connection string with read-only
permissions, would at least make it LESS susceptible to this kind of
attach.
Am I missing something here?
Bob Barrows [MVP]
Nope. That is certainly a valid approach. The only potential problem
that would remain is if there is something to read in the database that
you don't want people to be able to read.
If users are not allowed to modify data, that certainly reduces your
potential for damage, and would definitely prevent the recent worm
attack from affecting your system.
Just be sure to explicitly grant SELECT permissions to only the database
object you want to have visible to users. Don't just put the user
account in db_datareader and think you're safe.
--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.
Nime
-inserts javascript code-
Our site has tons of vulnerable spots, I think. I and a friend of mine
couldn't
patch the ASP codes, completely...
After an attack, site slows down -at the client site, of course- due to load
the
remote javascript file. People don't know what problem is and say "your site
is too slow"
or "there is a virus" like things.
Then I've decided to clear the tables automatically and I did it. I monitor
a field in a table
-say honeypot- if there will be a change I'll remove the changed
string -usually a javascript code-
At the moment, I'm using that code. It can be used as standalone script when
you notice an attack
or you may include as a part of any script -i.e. default.asp, with 10 minute
intervals- It has silence mode
ability so there is no problem to include it anywhere...
If someone request I supply the code.
"Bob Barrows [MVP]" <reb0...@NOyahoo.SPAMcom>, iletisinde şunu yazdı,
news:uyE5fAL%23IHA...@TK2MSFTNGP04.phx.gbl...
Mark McGinty
"Nime" <emina...@gmail.com> wrote in message
news:e7$MMwy$IHA....@TK2MSFTNGP06.phx.gbl...
> We are being attacked these days, and someone/bot modifies the fields
> -inserts javascript code-
>
> Our site has tons of vulnerable spots, I think. I and a friend of mine
> couldn't
> patch the ASP codes, completely...
>
> After an attack, site slows down -at the client site, of course- due to
> load the
> remote javascript file. People don't know what problem is and say "your
> site is too slow"
> or "there is a virus" like things.
>
> Then I've decided to clear the tables automatically and I did it. I
> monitor a field in a table
> -say honeypot- if there will be a change I'll remove the changed
> string -usually a javascript code-
>
> At the moment, I'm using that code. It can be used as standalone script
> when you notice an attack
> or you may include as a part of any script -i.e. default.asp, with 10
> minute intervals- It has silence mode
> ability so there is no problem to include it anywhere...
That is a poorly considered approach, for at least the following reasons
(likely many more):
1. In between each successful SQL injection attack, and the next automated
cleanup, your site's visitors are subjected to client-side attacks when the
malware javascript that was injected into your data runs in their browsers.
That is irresponsible, and will surely cost you users as time goes on. (For
me personally, the first time I noticed it would be the last time I browsed
your site.)
2. The overhead incurred by both the SQL injections and the clean-ups could
be substantial, and is definitely 100% wasted compute and resources.
3. Those SQL injections can be quite sophisticated, making complete clean-up
difficult, if not impossible to program.
4. The SQL injection attacks I've seen truncate data when max field length
is not sufficient to permit storing both the data and the injected crap,
which means loss of data without restoring a backup.
By accepting that the attackers will be able to write to your SQL Server
data, and accepting the [mistaken] premise that there's nothing you can do
about it, you practically join their ranks. By relinquishing your right to
your own data integrity, your right to be free from their corruption, you
also relinquish your user's rights to be safe from attack by vandals and
theives while browsing your site.
What you describe is no solution, it is a surrender, to those that lack even
a shred of decency, or any respect for the property of others. And for
merely the false sense of contentment you get out of calling this a
solution -- and not one tiny single thing more -- you've sold-out your user
base, to the jackals that are going to harvest every fiber of their
collective being, just to make a dishonest buck.
As god would be my witness [if only there was one] you have folded, man, you
lose.
-Mark