[thelist] Website Hacked?

Todd Richards todd at promisingsites.com
Wed May 28 19:01:42 CDT 2008

Hi Chris -

Thanks for the information.  I actually had an article talking about SQL
injections and it mentions using parameterized queries. I wasn't aware of
that, so I will do some more research on how to rewrite my applications to
do so (along with some better data cleansing).  I understand the use of a
parameter, but not quite sure how to implement it.  But I have some books
and the Internet to figure that out.  My queries were being built as 

	Query = "select this from that where id = " & id

I was checking to see that it was being passed an integer, but obviously
that wasn't enough.  Someone else offered a start to how to clean the data
first, so I will look at that as well.  

The whitepaper that I was reading also mention that one of the ways an
attacker figures out stuff is because bad attempts to hack may reveal
database error messages from the server.  What is a common way to avoid
that?  I tried a few hacks that it mentions and I don't get anything
"valuable".  So I don't know whether my site is or isn't vulnerable to that.


PS - Great cartoon - hits home too!!!

-----Original Message-----
From: thelist-bounces at lists.evolt.org
[mailto:thelist-bounces at lists.evolt.org] On Behalf Of Chris Anderson
Sent: Wednesday, May 28, 2008 5:58 PM
To: thelist at lists.evolt.org
Subject: Re: [thelist] Website Hacked?

> problem.  I'm seeing several places where they hit my search.asp file
> with a
> query of "letter=n" (normal query) followed by
> ";DECLARE%20 at S%20NVARCHAR(4000);SET%20S=CAST(0X..."
> So it looks as though I need to go through and see where the ball was
> dropped.

The main thing to look for there is if the query string is being used to
build a string and then executed or if it's used in a parameterised
query. The latter (as said before) is safer.
Note however that even if the string is passed to a Stored Procedure
using a parameter you are still not necessarily safe (because the proc
could be creating a VARCHAR string from the passed query and EXEC'ing
it!) You would have to check the proc to see how the string is used.
If it's used in a query directly it's okay, but if as mentioned earlier)
it's used to create a string which is then executed - you're in trouble.

Basically - Your code should be able to handle this scenario :
http://xkcd.com/327/  :-)

> I
> see that the SA user has access to a lot of stuff.  I know that I
> changed
> the password for it, but couldn't I just disable it?

In SQL Server 2000, you could only disable the sa account by not using
SQL Authentication (i.e Windows authentication only)
Personally if I have to use SQL authentication, I set the sa password to
a *very* long password (300+ characters) and then never use it.
Admin can be done locally (and therefore via Windows auth) and the only
non-Windows (ie. SQL) users are locked down application users.

In SQL Server 2005, sa can be disabled (and is by default)

In either case, you wouldn't ever use it in an application (unless it
was an admin one of course ;-) )


* * Please support the community that supports you.  * *

For unsubscribe and other options, including the Tip Harvester 
and archives of thelist go to: http://lists.evolt.org 
Workers of the Web, evolt ! 

More information about the thelist mailing list