This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1BE56.9508A080
Content-Type: text/plain;
	charset="iso-8859-1"

Sorry to come to this late. I have been off work ill for the last few days.

This might be of interest:
http://online.securityfocus.com/cgi-bin/archive.pl?id=88&threads=0&start=200
2-01-05&end=2002-01-11

The link if to some of a discussion on the most secure place to put your
connection string. Read the links that have the title "SQL Connection string
Security" and "SQL connection string security (Summary, I think)". These
people really know their stuff.

regards
David Cameron
nOw.b2b
dcameron@i...

-----Original Message-----
From: Joe Hughes [mailto:JoeHughes@M...]
Sent: Friday, 22 February 2002 4:42 AM
To: Pro ASP HowTo
Subject: [proasp_howto] RE: Connection strings


Very true.

Theres always the blank sa password, as well as various problems with plain
text passwords in DTS packages. It comes back to the point of appropriate
access rights, and up to date patches.

Like most M$ products there are always exploits.

There have been in the past plenty off unchecked buffers in SQL7, one
particular issue was where there were a few stored procedures that caused a
buffer overrun when ran with the correct parameters;

raiserror() function (accessible to all users)
formatmessage() built in function (accessible to all users)
xp_sprintf extended stored procedure (accessible to the 'public' role by
default

It will allow you to execute code in the security context of the service
(SQL typically runs with Administrator privelages)
This can also lead to SQL Command injection.


----- Original Message -----
From: "Jerry Diegel" <diegelj@g...>
To: "Pro ASP HowTo" <proasp_howto@p...>
Sent: Thursday, February 21, 2002 5:07 PM
Subject: [proasp_howto] RE: Connection strings


Pedantic Point:

The login in your connection string should only have the permissions that
are absolutely necessary for the application using it.  For example, why
would the user in your connection string need permission to create stored
procedures or have access to extended stored procedures?

Jerry

-----Original Message-----
From: Joe Hughes [mailto:JoeHughes@M...]
Sent: Thursday, February 21, 2002 11:19 AM
To: Pro ASP HowTo
Subject: [proasp_howto] RE: Connection strings


I must admit for basic asp websites, I'd store the connection strings in an
include file, or a session variable.

I've developed a few ASP sites and simply stored the connection string in a
file. Recently I developed a site where the people wanted it super-secure.
In order to do this I hardcoded the various connection strings in a DLL, and
all functions that accessed the datasource (supplied by connection string)
were also contained in a DLL. All the ASP got to see was a 2D Array returned

from the various functions.

It was impossible for someone using simple ASP to access the connection
string. The methods of obtaining connection strings are completely
transparent to any potential "hacker" (apart from reverse engineering). On
top of this, any sensitive data in the database was encrypted using keys &
salts.

Using COM+/MTS you can enforce access checks and roles, as well as using
private objects etc The site was developed on the basis, that if someone
managed to take the webserver - they wouldnt be able to access any sensitive
data. .

On the otherhand if you simply have a component function that returns the
connection string, then that is just the same as storing it in plain ASP.
Someone could simply do;

'=====
StrConn = TestComponent.GetConnectionString()

Response.write(strConn)
'=====

If someone manages to "take control" of the webserver - which sadly has been
very easy in the past with the various exploits on IIS4/5. Then it is quite
easy for them to manipulate ASP. If they know the connection string, they
can manipulate the database.

There's certain instances which can be worse. A potential hacker can run
riot on your system if they know the connection string, can manipulate ASP
and using SQL server.  Besides from the fact they can create their own
stored procedures and views there is a lesser know extended stored procedure
called "xp_cmdshell " which allows users to execute shell commands on the
SQL server. If the SQL service is running under local_system account then
they have full access to the server.

I think to summarise, if your webserver is patched up with the latest
security patches and you have taken necessary steps to lock down the server,
then connection strings in ASP are fine. If you have a decent firewall with
unecessary ports blocked then that helps. Make sure all the services have
the appropriate access rights. Then there are other things you can implement
like DMZs and IDS systems.

Thats my dollars worth :)

Joe



$subst('Email.Unsub').

$subst('Email.Unsub').




$subst('Email.Unsub').