p2p.wrox.com Forums

p2p.wrox.com Forums (http://p2p.wrox.com/index.php)
-   BOOK: ASP.NET Website Programming Problem-Design-Solution (http://p2p.wrox.com/forumdisplay.php?f=23)
-   -   security - xml connection string (http://p2p.wrox.com/showthread.php?t=10598)

fzilz March 16th, 2004 12:20 PM

security - xml connection string
I have a question about using this website as a model for a public website. I am concerned about having my database connection string in an xml file. Should I be concerned, is this more or less safe than having the connection string in my web.config file.

Imar March 16th, 2004 12:25 PM

Web.config files are protected by the setup of the Framework by default.
This means that whenever someone requests a Web.config file, IIS will hand the request over to the forbidden content type handler (something like this, can't recall the exact name) which prevents the file from being downloaded.

XML files are usually seen as content files and can be downloaded if you know their name and location. So, yeah, storing them in an XML file with the Web scope (anywhere below the Web root folder) poses a security risk.

However, you can configure IIS or the disk (NTFS) to block access to the file for unauthenticated users.



Imar Spaanjaars
Everyone is unique, except for me.

fzilz March 16th, 2004 01:11 PM

The project I am working on will be a public website where individuals must register to use the site and view the content of the site. I have normally worked with either annonymous access public sites or Protected Windows integrated security intranet sites. This is new for me.

I would like your opinion, would you use ntfs to protect the folder and use the xml configuration files as presented in "ASP.Net Programming" or would you place the database access connection string in the web.config or is there a better, more robust / secure solution that you would recomment. Thanks again for your response.

Imar March 16th, 2004 01:24 PM

Are you still using Anonymous access for the Web site?

If that's case, change the Security for your folder that holds the connection strings. Set it to Integrated Security only (that is remove anonymous and basic). On NTFS, remove all permissions except for read permission by the anonymous IUSR account (and maybe yourself or an Administrator account).

This way, IIS will be able to read the contents of the folder. If an anonymous user tries to request a file, Integrated Security won't work and they won't get access to the config files.

Alternatively, place the config files outside Web scope; e.g. in a folder called C:\Config. IIS can still read the files, but users won't be able to request them. I haven't read the book, so I don't know if this is applicable in your scenario.

Finally, you could move the connection strings to a Web.Config file. IMO, that makes sense. The inventors of ASP.NET probably thought about this for a while so I am sure there is a good theory behind its design. It also gives you easy access to its contents.

I think all three scenario's are safe: you can protect your connection strings from prying eyes on the Internet. What you choose is up to you: whatever is easiest to implement, or seems most logical to you.



Imar Spaanjaars
Everyone is unique, except for me.

fzilz March 16th, 2004 01:35 PM

Thanks again.

organicglenn March 24th, 2004 11:57 PM

A relatively easy solution to this issue is to encrypt the string that's stored in web.config.

bschaldon March 30th, 2004 04:55 AM

But the module config files have a .config extension - it is the file extension that is screened by IIS. So they are no less safe than web.config.


Imar March 30th, 2004 05:37 AM

Right, I didn't know that (I don't have that book).
The OP said: "xml configuration files" so I assumed files with an .xml extension.

If they end with .config, they are indeed as safe as any other .config file.



Imar Spaanjaars
Everyone is unique, except for me.

All times are GMT -4. The time now is 05:37 AM.

Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
© 2013 John Wiley & Sons, Inc.