securing connection string (ASP Classic)

Topic

New Reply

We have implemented security standards here that have the side effect of derailing many asp classic web applications, primarily on the issue of non-secure connection strings. These connection strings are implented via include file with the basic asp code required to instantiate a DSN-less connection. all this happens under SSL.

the issue with this method of handling connection strings involves “clear text password”, and, apparently, ASP.NET is the *only* solution to this problem. What this means is, several high-profile and complex web applications have been taken off line and slated for a complete re-write.

I’d like to know if there’s a way to address this issue in ASP Classic so we can continue to use the existing systems. Re-writes are all fine and good but will take several months, and it’d be nice to not have to wait that long. I have advised my people that we should at least wrap all read/write/updates into Stored Procs and use a connection string with limited access to the db but none of my suggestions have deterred the ‘rewrite it all!’ crowd.

any ideas? we can config the SQL Server directly but not the web server. It’s SQL Server 2000 BTW.

Reply | Quote

Replies

The client never sees the password does it? Only the two servers? Assuming that is the case, as long as the NICs on the subnet are not in promiscuous mode (you can create a separate subnet if necessary), there is little chance of interception. Of course, you also could encrypt that connection, between the web server and the database server.

Reply | Quote

i’m not a security maven or a network nabob, so I just *barely* understand you, but yeah the connection string is used by the webserver to open up a connection to sql server “automatically” as needed — no user interaction involved.

the problem really is, since the connection string code is a file on the webserver, it’s *possible* to access the file — altho the webserver doesn’t allow directory snooping from the address line. other options — I’ve been researching a bit — are to put the connect string in Global.asa (yech) or, as you suggest, encrypt it. or store it in the registry, maybe…

The thing I’d like to do — which I asked for in the beginning — was help in wrapping all the SQL Server read/write access into stored procs rather than shooting SQL String out directly from ASP. Strangely enough, the response was more or less ‘no, we’re going to take over your ASP projects and rewrite them in .NET’ – which seems to me a bit beside the point. and, as the apps are complex, this means a LOT of down-time for someone to write, test and implement a .NET solution. I’m not sure why .NET is a must-have for this issue.
I’d still like to re-visit the stored procs solution, which will be a bit of a pain but tons quicker than a complete re-write.

also, I’m not clear on the whole ‘clear text’ objection as the system is operating under SSL. what exactly does that mean and how is .NET an overwhelming advantage?

From what I’ve seen so far, the best option would be to craft a good SQL Server login profile and restrict interaction to stored procs. that way the connect string won’t do more than give someone your SQL Server IP address and db name. If it’s stored in a Global.asa file there’s an additional level of protection under IIS in accessing that file.

Any comments on that?

Reply | Quote

I assumed the connection between the web server and database server was not itself secured with SSL. If it is, there is no clear text issue at all, as you point out.

Regarding any password-related difference between stored procedures and other types of queries, I don’t know what those might be. I use a “read-only” userID/password for my reporting applications (and I cannot add stored queries to the database for fear of voiding support).

Reply | Quote

I always used to store the connection string in a file with an ASP extension – this prevents the web server from echoing the connection string to the end user. Here’s the exact code I used when I wrote my last classic ASP app (over 3 years ago…)

You’ll want to update the connection string with the SQL Server connection string. The file name I used was “dbconn.asp” – which would prevent anyone from reading the file – even if they guessed the exact url of the file. Obviously, I used “cnn” as the connection object.

Hope this helps!

Reply | Quote