Connecting from ASP to SQL
-
If have a ASP that connects to my SQL database. What is at risk. If the ASP passes the SQL account and password is it encrypted or does it send it clear text. Is it sufficient to lock down the ASP page so no one can view the SQL account & password. Looking for any words of wisdom on this subject or point me to some reading I can do on this. Thanks
-
I believe the connection information is sent in clear text unless you're using an HTTPS connection.
We code the connection string and "conn.open" statement in an including file (i.e. connection.inc), use an include statement:
<!--- #include file="/includes/connection.inc" --->
in the ASP pages that require a connection. The "includes" subdirectory is set up with NTFS permissions that only allow the IIS userids and the DBA's access to the directory.
If there's a better way to do it I'd love to know.
-
Setting the conn string and/or connection object (if you're using one) in an INCLUDE file is definitely a good way to go. However, using a .INC extension is a bad idea. If someone discovered the name and location of that file, they could browse to it and actually see the content of the file. Name the INCLUDE files .ASP files and that prevents the problem because browsing to an ASP file causes it to be processed, not displayed.
-
"The way to go" is to not connect to SQL Server from ASP code. Put all data handling (SQL queries) and "business logic" in ActiveX DLL(s). Pass disconnected recordsets back and forth to ASP code.
This puts majority of your executing code in compiled DLLs (which, if also installed under MTS/COM+ will have shared object pooling), will run faster, have shared connection pooling to database, and will not have your logon info in plain text anywhere. Use ASP code only for building html pages, and handling response inputs.
Mark -
Unfortunately the keepers of the web world at our company do not allow application-specific DLL's.
-
ASP is server side does not get sent anywhere. Clear or other wise.
Dave
Trainmark.com IT Training B2B Marketplace
(Jobs for IT Instructors) -
This forumware keeps only giving me one line for msg...whats up with that?
Dave
Trainmark.com IT Training B2B Marketplace
(Jobs for IT Instructors) -
You know, he's right. The ASP is all server-side. If the concern is that the SQL connection userid and password is being sent over the Internet (or even Intranet), it's not. It only gets sent between the IIS server and database server. Assuming a reasonable effort to keep server traffic within it's own context (i.e. all on one switch or switch complex) then the conversation between the two servers is pretty much untouchable. -
That is true, but the connection info is still being stored in plain text files (.asp file). There have been IIS security holes that allowed retrieving the file as text (the : Data problem). Also, if there was a problem with ASP processor program (it is just a program) the ASP file could be returned as plain text to your web user.
It just makes sense to not store SQL connection info in plain text on ASP pages. Since DLLs are not an option, consider storing the connection string in a registry entry. Or store it encrypted and have the decryption routine and/or key in another file.
Mark -
I would suppose that if your IIS server is not secure then any strategy for protecting your SQL server will be compromised in one way or anthoer.
I read an article about storing the connection string in the registry but one would imagine that if someone got ahold of your ASP pages they would also get a hold of the code for retrieving the connection string and therefor defeating the purpose. No?
Even if ALL of your db access code was encapsulated in a DLL, if someone had access to your asp pages they could perhaps use your DLL in malicious ways. Calling otherwise benign methods in a way that potentially corrupts your data. For example a simply method for updating a record could probably be called passing in XXXXXXX for name fields etc. So using your own DLL and whatever SQL account it uses, I'd imagine that a hacker could still mess up your data if IIS is not secure.
I suppose the lesson is to spend at least as much time securing your IIS server as you do securing your database.
I have a few questions concerning best practices in this area but I'll post them later after dropping kids off at school
Dave
Dave
Trainmark.com IT Training B2B Marketplace
(Jobs for IT Instructors) -
Sorry about the single line, forum flips out randomly.
I tend to store in a .asp include file, depending on what the data is. In a financial company, we did use a DLL that read from registry on a different machine (not the web server), but that's complex and overkill for many situations. In many situations we use an anon IIS account that has limited rights to the db and NT auth.
The ASP bugs that allowed to code to come through were fixed, but that's not to say there will not be other ones down the road. However, this may or may not be much different than storing in a file. Chances are you want to keep that info in a var somewhere rather than having every page read the registry and if you go down that road, then you are potentially allowing some other injection code from hitting you as well.
Assess the risks and then choose the simplest method that works for you. Above all, limit the rights for all accounts to what they need, especially from the db. Don't automatically give all rights to all tables (ie datareader/data writer). Explicitly allow things.
-
single line appears to only happen when following link from notification email
Dave
Trainmark.com IT Training B2B Marketplace
(Jobs for IT Instructors)
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply