You've probably whipped up something like this while developing a new database driven web application. If you're anything like me, you don't want to be bogged down in supporting code and procedures. You want to get connected and begin writing feature code, the stuff that actually does something. "First things first." we tell ourselves; we'll go back and secure the application after we get it working.
If you have a good memory, and if you are not seriously overworked, you might actually come back and do this. When you finally do return to secure your code, there are a couple of things that can typically be done to help secure passwords like this one. First, don't use the sa, or system administrator, account; that much is obvious. Secondly, define database connections and the strings that support them in global.asa or an include file. But is this really enough?
Using an account other than sa is very important. After all, if a hacker were to acquire the connection name and password, you would want to limit the amount of access they would have to other databases that might be supporting other services on your site or even other customers. However, I say that this is insufficient. Your web application is going to want read and write access to the database in order to perform its duties. So, if a hacker has gotten this far, they've already got enough information to sabotage your site, place false orders, or download your entire user list.
Moving your connection strings to global.asa may seem like a good idea at first, but consider the fact that most hackers are very likely to look here first for critical application information. There are known loopholes that allow hackers access to global.asa, just as there are security issues that allow them to view your ASP code. Include files aren't much better, since hackers can usually view these just as any other ASP file on your site.
Don't think you've done enough to prevent this either. I am generally very thorough about security, but I was very alarmed one day when I received an anonymous e-mail from someone handing me a scrap of code from my site that contained the Administrator password for my entire domain! Fortunately for me, it was a password I had long since changed. (One wonders how my code functioned without it, though.) This just illustrates my point; even if you are diligent now, there's no guarantee that your server has always been protected, particularly if you are sharing it with others.
Comments