Dynamic connection string considerations

  • Thread starter Thread starter Erik Cruz
  • Start date Start date
E

Erik Cruz

Hi.

We are in process to update our first VB6 project to VB.NET. We decided to
use the migration process to optimize certain areas of the application,
including the use of connections. In our VB6 project the connection string
is generated dynamically. Our users type the user id and password on
textboxes, and the application concatenates these values with the other
information of the string. We know that we are loosing pooling capabilities
this way beacuse each user enters different data, but are there any security
issues with this method? Some time ago a consultant told us that creating
the connection string this way would help us to avoid sql injection attacks.

TIA,
Erik Cruz
 
That's a pretty safe way of doing it, since the connection string is not
actually being stored anywhere, but being generated at run time.

I don't really follow how that is related to sql injection attacks. As far
as I understand, that is when a user types in a command like " ' drop table
MyTable", or something like that, which assumes that the programmer is just
concatenating fields on the screen to form the sql statement - and by
closing off the previous string, the hacker is trying to execute malicious
sql statements. But I am not clear on having users enter the
username/password helps avoid this problem.
 
If you use the exact same name and password, you're not losing anything in
the connection pool.

I don't think he was right about Preventing injection attacks. Since they
can't inject anything that you don't let them, and they can't inject
anything until they have a connection which is what's being defined I don't
see the point.

If anything, dynamic sql opens you up to injection attacks, but the way that
you are using it, I don't think it's a problem because they can't inject
unless they have a connection.

HTH,

Bill
 
Since this is a Windows Forms application, the connection pool is created on
a per-application basis and not really a big issue here unless you're
opening more than one connection with different UID/PWD authentication
credentials. SQL injection is also a problem whenever you ask users to enter
data and you concatenate the values into the connection string. Consider
that the values you provide are overridden by values concatenated later in
the same string. Always check for ";" in a Connection string argument and
reject that user. Log the attempt and identify the individual.

hth

--
____________________________________
Bill Vaughn
MVP, hRD
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
 
Connection pooling requires the connection string be
identical each time. If your security is not case
sensitive, you could force the users input to lower/upper
case, preventing them from entering in different cases.

To make better use of pooling, I would suggest have users
impersonate 1 user that is known to the SQL Server. That
way will have identical connection string for all users,
rather than a pool for each user. More secure on the SQL
side as well.

Dan
 
Ah no. Windows forms applications (he said it was VB6) do not share pools
with other processes (applications)--only with itself. Each application gets
its own pool--regardless of whether the connection string is identical or
not.

--
____________________________________
Bill Vaughn
MVP, hRD
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
 
Erik,
I am seeing a lot of conflicting thoughts on this thread, I want to make it
absolutelly clear that allowing customers to type in _anything_ that gets
sent to the server directly is a SERIOUS security threat.

This is especially true for CommandText, but it definitelly applies to the
connection string and there is no way to protect yourself if you are using
v1.0. If you are using v1.1 and are really carefull you can use our new
configuration files to lock down connection string keywords.

The reason this is such a hard area to lock down is that there is a
precedence to connection string keywords. We only pay attention to the last
connection string keyword of any one type in a connection string. If I type
in a connection string like "Data Source=mydb;user
id=sa;password=pass;integrated Security=sspi; Data Source=baddb;" we will
understand it as "integrated Security=sspi; Data Source=baddb" and connect
you to the baddb using integrated security.

There are a large number of security threats associated with allowing user
code in the connection string, integrated security access, denial of service
attacks with Min Pool size, if you are using distributed transactions
letting a customer add Enlist=false or Oledb Services=-4 to the connection
string would allow him to bypass all of your transaction processing, passing
in invalid data to gather extra information from the exception message, etc.

I would highly recomend you reconsider your model for this application.

Hope this helps
 
Hi Angel.

Thanks for information, it was very useful to me! I think I will really need
to reconsider the way our systems work!!

Do you know of any article or other materials that explains with more
details the attacks you mentioned, like denial of service attacks using
minpoolsize?

TIA,
Erik Cruz
 
I know that all of these security issues have been compiled into threat
models and they were going to be published so that all security information
was in one place, I am not sure of what the current status of that work is.
The information I posted can all be found in the current docs.

As far as denial of server, if you are using SqlClient or the Oracle managed
provider setting min pool size to a very large number will flood the server
with connection open requests, if the number is big enough it will also make
it run out of resources.
--
Angel Saenz-Badillos [MS] Managed Providers
This posting is provided "AS IS", with no warranties, and confers no rights.
Please do not send email directly to this alias. This alias is for newsgroup
purposes only.
 
Back
Top