P
Phil C.
Can someone explain in plainer english or expound the missing steps/code
especially regarding what and where and how to use the GAC, plus how to
implement and use "the instantiator's assembly ID" in the below discussion
exerpted from Visual Studio Magazine by Doug Thews
Posted February 6, 2004:
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.
/*******************************************************************/
LISTING 4:
C# . Secure Your Database Connection String
Listing 4. The key requirement for securing your database connection string
is to avoid exposing your database connection string (or your connection
credentials). Once you create the class, deploy it to the GAC and add a
reference to it in your application.
using System.Data.SqlClient;
using System.Security.Principal;
namespace MyConnectionString
{
public class DBConnection
{
public SqlConnection Get()
{
// Check here to see if this is a valid request
// Use your own business logic
if (false)
{
return null;
}
// Or use the Windows identify to see if the
// caller matches the list of user ids that CAN
// access this class. Make sure the caller was
// authenticated
WindowsIdentity CallersIdentity =
WindowsIdentity.GetCurrent();
if (CallersIdentity.IsAuthenticated ==
false)
{
return null;
}
// Code to get the connection string from a config
// file or a separate database. This is merely a
// sample to make the code work -replace this with
// your business logic
string myConnectionString =
"Initial Catalog=Northwind;Data
Source=localhost;Integrated
Security=SSPI;";
// Now go get a database connection and return it
SqlConnection myConnection = new
SqlConnection(
myConnectionString);
return myConnection;
}
}
}
especially regarding what and where and how to use the GAC, plus how to
implement and use "the instantiator's assembly ID" in the below discussion
exerpted from Visual Studio Magazine by Doug Thews
Posted February 6, 2004:
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.
/*******************************************************************/
LISTING 4:
C# . Secure Your Database Connection String
Listing 4. The key requirement for securing your database connection string
is to avoid exposing your database connection string (or your connection
credentials). Once you create the class, deploy it to the GAC and add a
reference to it in your application.
using System.Data.SqlClient;
using System.Security.Principal;
namespace MyConnectionString
{
public class DBConnection
{
public SqlConnection Get()
{
// Check here to see if this is a valid request
// Use your own business logic
if (false)
{
return null;
}
// Or use the Windows identify to see if the
// caller matches the list of user ids that CAN
// access this class. Make sure the caller was
// authenticated
WindowsIdentity CallersIdentity =
WindowsIdentity.GetCurrent();
if (CallersIdentity.IsAuthenticated ==
false)
{
return null;
}
// Code to get the connection string from a config
// file or a separate database. This is merely a
// sample to make the code work -replace this with
// your business logic
string myConnectionString =
"Initial Catalog=Northwind;Data
Source=localhost;Integrated
Security=SSPI;";
// Now go get a database connection and return it
SqlConnection myConnection = new
SqlConnection(
myConnectionString);
return myConnection;
}
}
}