Transfer Files Over the Internet (Continued)

The WebClient class also includes an UploadData method to upload raw data to a remote Web server using HTTP POST. The drawback to this method is that you must provide both ends of the client.

The second way to transfer files over the Internet is to use FTP. The beauty of using FTP is that the acceptor is ready already and it's platform-agnostic. All you have to do is create some requestor code to communicate using FTP.

You can use one of two approaches to communicate using FTP. The easiest way is to use the unmanaged code within WININET.dll (a core Windows system DLL), which does the bulk of the work for you. For example, assume you want to import references to specific functions that you want to use within the WININET.dll (see Listing 2). After you build the FTP class, it's a simple matter to consume the methods in WININET.dll to send a file to a remote FTP server (see Listing 3).

A second approach to implementing FTP is to roll your own FTP class by overriding the WebRequest and WebResponse classes of the System.Net namespace. You can then include the functionality of the specific FTP commands yourself (see Additional Resources).

Q:
How can I secure my application's database connection string and prevent others from getting unauthorized access to my database?

A:
You have a handful of options if you want to secure your database connection string from prying eyes, but most boil down to one of two choices: obfuscation (hiding) or encryption. Encryption can affect your application's performance negatively, so you need to decide who you're securing your connection string from and why before you choose that option.

For example, assume you're a small shop with a single developer who manages the servers and databases. In this case, a single level of obfuscation will probably suit your needs best. If you're deploying a Windows client desktop application, you might want to consider storing the connection string (encrypted or not) in a centralized location, accessible only to the application. If you're implementing your application on a server farm residing at an application service provider's server farm, you might want to implement encryption to prevent unauthorized access to your database.

Hiding the connection string means storing it in a location separate from where you use it in the code. However, be aware that anyone can use ILDASM on your ASP.NET or Windows client application. This means they can debug your application and try to get the database connection string by looking for constants in the code that fit the connection string format.

Popular places to hide a database connection string include the Web.Config file, the Registry, a database, or a remote location accessible only through a Web service or remoting call. You can use the System.Security.Cryptography namespace to add encryption to any of the strategies just mentioned to yield another level of security to your connection string.

However, the safest way to secure your database connection string is to never expose it to the application in the first place. You can do this by developing an assembly that contains a class whose sole responsibility is to return a database connection (and not the connection string) to the caller. The assembly can live in the Global Assembly Cache (GAC) and can use the instantiator's assembly ID as a key to make sure it's on the list of approved assemblies that can have a database connection. You can use this approach to ensure you never send any database credentials back and forth to be intercepted and decrypted. Someone using ILDASM on your application will see only the database connection object, not the credentials used to create that connection.

Creating a database connection class is simple (see Listing 4). After creating the class, deploy it to the GAC, add a reference in your application, and use the class exactly as you would use the SqlConnection class. Deploying an assembly to the GAC for a Windows-based client is simple because you can make it part of the app's installation and you can auto-update new versions. This code consumes the Get method from your DBConnection class in the example:

myDBConnection SqlConnection = 
   new MyConnectionString.DBConnection();

You could pass parameters to the Get method easily if you want to have some other criteria for validating access to the method. The important thing to remember is that using this method doesn't expose your database connection string (or your connection credentials) across the wire.

About the Author
Doug Thews is the director of software development for D&D Consulting Services in Dallas. Doug has more than 18 years of software-development experience in C/C++, VB/ASP, and VB.NET/C#. Reach him at .