Re: SQL Injection and DB user permissions

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance


"Nime" <eminakbulut@xxxxxxxxx> wrote in message
news:e7$MMwy$IHA.4816@xxxxxxxxxxxxxxxxxxxxxxx
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


If someone request I supply the code.



"Bob Barrows [MVP]" <reb01501@xxxxxxxxxxxxxxx>, iletisinde þunu yazdý,
news:uyE5fAL%23IHA.6012@xxxxxxxxxxxxxxxxxxxxxxx
Randy wrote:
I have a .asp web application (using MSSLQ SRV).
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?

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.





.

Relevant Pages

  • [Full-disclosure] Raising Robot Criminals
    ... identity theft and robot-driven attack propagation. ... security as well as on Sql Injection, this text is not yet another one. ... security numbers - are opened for remote penetration. ...
    (Full-Disclosure)
  • Writing a phpshell via SQL Injection to a host
    ... I've really been hitting SQL Injection pretty hard lately. ... comfy with SQL Injection on MSSQL server now, ... with with it on MySQL. ... The best reference on this type of attack that I've found so far is: ...
    (Pen-Test)
  • Re: sql injection: url or form based?
    ... URL based and Forms based SQL injection but I'm wondering what are the ... and if the script is expecting something sent as a POST request, ... you'd want a 'form' based attack. ... This is a bit misleading, calling it a form-based attack, as HTML ...
    (Pen-Test)
  • Re: [OT] IIS security
    ... administration page and performed a SQL injection attack, ... >> That's got no effect on IIS security. ... That's like saying that since one car was stolen becase the doors were ...
    (microsoft.public.windows.server.sbs)
  • [Full-disclosure] WebCT 4.x Javascript Session Stealer Exploits
    ... WebCT 4.x Javascript Session Stealer Exploits ... Attack Type: ...
    (Full-Disclosure)