.Net Connection String Security

[Frinavale]

I currently have a .NET application that has an object which passes a string (a connection string) as a parameter to another object that does database manipulation.

This string isn't stored anywhere else and is only used by this behind-the-scenes object to provide the database manipulation object with a connection string.

Does my connection string pose a security problem when it is inside the code like this?

Or are connection strings only at risk when they are listed in an web.config file?

Why would you want to put your connection string in a web.config file as apposed to putting it directly into code as I have done?

Are hackers able to get into a compiled project and extract the value of a string inside an object used with that project? How???

I'm kind of confused and would love some clarification.

Thanks

-Frinny

[chazcross]

The web.config file is the best place for it. Not only having a single known place where you can update it, you can also easily encrypt it.

The VS designers places database credintials in the web.config file itself.

[Frinavale]

The web.config file is the best place for it. Not only having a single known place where you can update it, you can also easily encrypt it.

The VS designers places database credintials in the web.config file itself.

Why is the web.config the best place to put my connection string?

I only use it in that one class...which just passes it as a parameter to another object that is included as a resource in my project.

Can people see this string somehow inside my code?

My code isn't even on the server...its only on my development server.

I still don't understand.

-Frinny

[bobneedshelp]

Why is the web.config the best place to put my connection string?

I only use it in that one class...which just passes it as a parameter to another object that is included as a resource in my project.

Can people see this string somehow inside my code?

My code isn't even on the server...its only on my development server.

I still don't understand.

-Frinny

I'll assume your app is exposed to the web and not sure exactly what you're worried about or trying to protect against. Security from hacking comes in layers and just isn't about where the sql statement is.

[Motoma]

Why is the web.config the best place to put my connection string?

I only use it in that one class...which just passes it as a parameter to another object that is included as a resource in my project.

Can people see this string somehow inside my code?

My code isn't even on the server...its only on my development server.

I still don't understand.

-Frinny

Security issues can come in if you have debugging on, or if your app is set to display error messages. Often with ASP, you can configure your server to display lines of actual code for debugging purposes.

If someone were to actually get your application, they could run it through a .NET Decompiler such as Dis#. But then, if that happened, you have worse things to worry about than your connection string, mainly the giant gaping security hole.

[Frinavale]

I'll assume your app is exposed to the web and not sure exactly what you're worried about or trying to protect against. Security from hacking comes in layers and just isn't about where the sql statement is.

Well, basically I've never thought about web-application security before because I've never had sensitive data that people would be able to access if my web-sites were hacked.

I was (and still am) looking up what types of hacking are out there and how to prevent them.

So far I'm pretty happy with what security I have naturally put into place without knowing about web-application security. It just seems natural to not let anyone see any errors...even if it is an IIS error...I don't even want them to know what type of server I'm running....it also seems natural to make sure that the user input is clean of unwanted data....and that it is valid data. It seems pretty stupid to store personal information in sessions or cookies so I don't (I probably will in the future...but I'll have to learn how to properly encrypt such data)

Anyways, while I was doing research I starting to get into the database insertion attacks and part of the recommendations to prevent this is to encrypt your database connection string in the web.config file.

I remember learning that it was almost a standard to put the connection string in the web.config but I never could figure out why? I understood that by putting it there it could be accessed from anywhere in the application but I always group my database manipulation stuff together and have one class handle it. In the case of the application I'm trying to secure, its a set of classes and its code isn't even in the project...I have developed an outside DLL to do this for me and its placed within a system folder under one more layer of security.

I'm probably going to remain kind of fuzzy on why the connection string should be put in the web.config file...but that's okay for now. I'm pretty sure it is safe within my application.... .for the most part

Thanks for all your help.

-Frinny

[Frinavale]

I'm moving the database manipulation out of the system folder....it seems to be one more place that a hacker might be able to gain access in. Even if I set the folder permissions...I don't want to compromise the server.
This security risk I didn't consider.

[ggibson1]

You can either use .Net 2.0 built in web.config encryption or you can use a tool like Assembly Lockbox ( http://alb.gibwo.com ) to encrypt the entire dll that your code is in... that will protect the connection string and all the other code as well.