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. Todd 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 ;-) ) Chris -- * * Please support the community that supports you. * * http://evolt.org/help_support_evolt/ For unsubscribe and other options, including the Tip Harvester and archives of thelist go to: http://lists.evolt.org Workers of the Web, evolt !