The basic idea is we have a test enviroment which mimics Production so customErrors="RemoteOnly". We just built a test harness that runs against the Test enviroment and detects breaks. We would like it to be able to pull back the detailed error. But we don't want to turn customErrors="On" because then it doesn't mimic Production.
I've looked around and thought a lot, and everything I've come up with isn't possible. Am I wrong about any of these points?
We can't turn customErrors on at runtime because when you call configuration.Save() - it writes the web.config to disk and now it's Off for every request.
We can't symlink the files into a new top level directory with it's own web.config because we're on windows and subversion on windows doesn't do symlinks.
We can't use URL-Mapping to make an empty folder dir2 with its own web.config and make the files in dir1 appear to be in dir2 - the web.config doesn't apply
We can't copy all the aspx files into dir2 with it's own web.config because none of the links would be consistent and it's a horrible hacky solution.
We can't change customErrors in web.config based on hostname (e.g. add another dns entry to the test server) because it's not possible/supported
We can't do any virtual directory shenanigans to make it work.
If I'm not, is there a way to accomplish what I'm trying to do? Turn on customErrors site-wide under certain circumstances (dns name or even a querystring value)?
If you have customErrors="On" or "remoteOnly" the error detail doesnt go away right? I mean you can still access it and log it to another source using your custom error page.
Why dont you just have your custom error page in production log the information somewhere your harness can access it, like a message queue or App event log? When the harness comes across a break it just has to be smart enough to do a lookup in the right place for the full error info.
Another thing to consider anyway.
Related
I've had a very frustrating experience on putting an MVC 5 app on Azure. I have been reading the following page: http://www.asp.net/identity/overview/features-api/best-practices-for-deploying-passwords-and-other-sensitive-data-to-aspnet-and-azure
But what I haven't managed to put in my head is the following:
Security Warning: Do not add your secrets .config file to your project or check it into source control. By default, Visual Studio sets the Build Action to Content, which means the file is deployed. For more information see Why don't all of the files in my project folder get deployed? Although you can use any extension for the secrets .config file, it's best to keep it .config, as config files are not served by IIS. Notice also that the AppSettingsSecrets.config file is two directory levels up from the web.config file, so it's completely out of the solution directory. By moving the file out of the solution directory, "git add *" won't add it to your repository.
And:
Security Warning: Unlike the AppSettingsSecrets.config file, the external connection strings file must be in the same directory as the root web.config file, so you'll have to take precautions to ensure you don't check it into your source repository.
The problem is the following: When I upload the Web.config file with the external files without being included I get hit by "The System cannot find the file specified", so for it to go away I must include the .config files defeating the purpose of Microsoft's post.
I really really really do not understand. I have added the connectionStrings and appSetting's keys in Azure's portal. What is the correct and secured way of putting my passwords and secrets online? What am I missing? Is it because I'm running in Debug mode?
According to this:
How can I secure passwords stored inside web.config?
There is nothing to worry about accessing the Web.config file...
But that just defies Microsoft's post.
Thanks.
I find the following technique to be the easiest way to do this.
Instead of putting the deployment values of these settings into the web.config, I keep the test values in there instead. I then put the deployment values into the Application Settings section of the Azure Website via the Azure Portal:
When the website runs, these settings will take precedence over what is in the web.config. This helps me avoid externalized files, allows me to keep sane development configuration that the team can share, and makes deployment very easy.
The best way is to set your secrets in the Connection Strings section of the portal. Any values set there will override values you specify in your web.config file.
This way they are only exposed to people who have admin access over the site itself. Having full access to the source won't even be enough to get the secret values.
More details here
According to this article (method 2, item 6) I'm supposed to add computername\IIS_IUSRS as the role allowed to read my web.config file.
I'm not sure if it's true, though, because:
I've seen other web sites on the current server that don't have that set in security tab but still are accessible
more importantly, I still get the error 500.19 related config data invalid with extension config file insufficient permissions (0x80070005).
(At this point I'm only trying to serve a static HTML page, before I'll go on and also deliver web services.)
What am I missing?
Check every part of the directory tree in your setup. Make sure that every directory, subdirectory and file that you're trying to access, in fact, has the group IIS_IUSRS defined on your local machine (or the server, in fact). I'm betting my left ear that you'll find a part that hasn't.
The error you mentioned - 0x80070005 - means precisely that.
In case you still can't find the source of the issue, remove the whole directory tree and redo the whole setup process. Maybe there's some access right that's catched, then.
I just tested it on my system and I could cause the error you're describing by removing permissions of IIS_IUSRS from a subdirectory.
I've had this question for many years, and did research every time that this issue arose, but could never find a definite answer. Somehow the mighty Internet, MSDN, community forums, are either silent or vague on this. Out of thousands of development-related uncertainties, this is the only one that remained elusive.
To the point: in order to enable users to upload and manage images (and other files) used in their blog posts, in a shared hosting environment, I can either consider SQL Server binary data types (performance implications), or the file system. To use the latter, the necessary permissions need to be set for the IIS_IUSRS role on the storage directory : create/write, read and delete. My question - if I do this, what are the security implications? Could someone somehow take advantage of this, bypass the ASP.NET request pipeline and manipulate the files inside the folder without making a request to the corresponding ASP.NET handler (which checks rights, validates uploads, etc.)?
I've developed several systems that allowed file uploads and this has always bothered me. Now, hopefully, someone will be able to put my mind at ease and, ideally, explain the mechanics behind the process.
UPDATE
After viewing the latest answers (many thanks), another formulation of the question:
Is it in any way possible for a client to somehow bypass the request pipeline and create/delete files inside a directory that allows it (assuming the person knows the directory structure)? Or only the code that handles the request can do it? Any potential exploits?
The main problem is to been able to upload a script, an aspx page, in this directory with the photo files, and runs it.
Here is one case: I've been hacked. Evil aspx file uploaded called AspxSpy. They're still trying. Help me trap them‼
The solution to that is to add this extra web.config file on the directories that allow to upload files and not permit to run any aspx page. Also double check to allow only extensions that you permit and not allow to change that on the file name, if they have the opportunity to make rename.
<configuration>
<system.web>
<authorization>
<deny users="*" />
</authorization>
</system.web>
</configuration>
Also on the directories that you allow to upload files, do not permit to run any other script like simple asp, or php or exe, or anything.
general speaking
All your pages have permissions to run and manipulate many things on the server. What you give now is the ability of write on some directories, also by using some aspx page. The asp.net now have one more extra permission to write files there, on the photo folder. Also note here, that you asp.net page have this control, not the user. What you do there with your code can write on this directories, so must be carefuller there to double check where you write and not allow any other directories, not allow the user to manipulate the directory that can be written to.
So this is the weak link. To been able to upload more script that can take control of the server, at least the part that can be access by the asp.net user of this pool.
Having done this before, I'd make two recommendations:
First, do not store the uploaded files in the same directory structure as your application code (if possible). Make it a well-defined external location, and locked down explicitly to only the user the application is running as. This makes it harder for a malicious upload to be injected into your application as nothing in the web server, or ASP.NET itself, knows how to access the file (only your application).
If that is absolutely not possible to do so, be sure to make sure no external user can access the storage folder using standard ASP.NET authorization and only allow writes by your application user to this folder, nothing else.
Second, do not store the uploaded files with their original names and file extensions; Keep that meta-data separate. Just consider the file a raw binary blob of data. This is good for a couple reasons. First, it prevents inadvertent execution of the file on the server, be it by someone accessing the file system directly, the web server, or ASP.NET. Second, it makes it much more difficult for an attacker to exploit a malicious upload as they should never be able to guess the name, or path, of the file on the server.
I've developed an ASP.NET v4 web app which I am trying to get to write to a folder in the webroot.
For the life of me I cannot get Windows 7 to allow it to write a file, I get Access is Denied error each time.
What I have tried on the folder is
attrib -r /foldernameandpath
attrib -r -s /foldernameandpath
Removing Check from ReadOnly attribute in folder properties
Changed owner to folder to current user whom is also the admin
Changed owner to Everyone
Adding Everyone user to folder with all permissions
Changing the folder to the Public Document directory
Changing to the root of the C drive (Out of desperation)
Nothing seems to work and all I want to do is test that the write works.
Now I know the system works and writes fine cause I had this same web app on a second machine writing the PDFs to the C drive without issue. This second machine I just cannot get it to allow the write.
Oh please for the love of all things holy, put the keyboard and mouse down and stop what you are doing. Some of the actions in your list seriously frightens me.
All the things you list as your actions are most likely useless or desperately random at best.
As a web developer, you shouldn't have to start messing around changing ownership of folders, especially not the web root folder normally used by the web server. When you do, you'll end up in a dark, cold and lonely place. Lord only knows what other desperate measures you have taken. For your own sake, I'll recommend you to do a system restore or even system reinstall to make sure you are in a healthy state.
Let's go back one step and try to sort out what you are doing.
First: what is the path you are trying to write to?
Second: are you running this application directly from within Visual Studio or in IIs?
If you are doing the first option then your current user account is the account who tries to write to the path in question. Do you have write permissions there?
One thing you can try is to start Visual Studio with elevated permissions and see if that works.
If you are running in IIs, it the associated pool account that needs write permissions.
Are you doing impersonation by any chance? If so, make sure the impersonated account have proper permissions.
You should only write to a predefined folder within your app path, like ..\App_Data for example.
The easiest way to find out which account you are running with and determine what path you are trying to write to, is to fire up SysIntenals process monitor and find the entry with the access denied result. Select properties for that entry and find out which account tried to do the write action. When you have determined that, right click on the folder in question and give the proper account write permissions.
I have a ASP.NET application that we've written our own logging module for.
My question is, where is the standard place to write a log file to? I.e. the website will be running as the anonymous user identity (e.g. IUSR on IIS7) and I need a place where I know it'll have permission to write to.
Cheers,
App_Data folder on the root of the project. It isn't served to web requests; so other people can't snoop for it.
I would suggest putting the log file onto a seperate disk, though should give you a little performance gain so that your not trying to both read and write to the same disk as the website. If you cannot put the log file on a seperate disk, then I would simply choose a folder of your choice.
In any case, you will have to give the "Network Service" account "Modify" permissions to the desired folder.
If on the other hand, you have access to a databse, then log the information there. It will be much quicker than accessing the hard drive and won't be publically available. You'll also be able to report from the data quite easily.
I'm not in a position to modify the permissions on folders (especially outside of the virtual directory home folder), and don't already have an App_Data folder, so am a bit hesitant to go with that.
So for the moment I'm going with the CommonApplicationData Folder.
On Vista/Server 2008 this is C:\ProgramData\
On XP/Server 2003 this is C:\Documents and Settings\All Users\Application Data\
I'm not in a position to modify the permissions on folders (especially outside of the virtual directory home folder), and don't already have an App_Data folder, so am a bit hesitant to go with that.
If you have a website, you clearly have a folder somewhere. Can you not add a (non-web-facing) subfolder? It seems like that would be a more appropriate place to put your logs than dumping them into a global, shared folder.
You could also log to the Windows Event log or to a table in a database. How often are people looking at the event log? If it's being examined on a regualr basis, writing to a table amkes the reporting back much easier as it's trivial to reverse the order and only show the last X events for the current time period. The Windows Event log you can also query the Windows Event Log through PowerShell or with LogParser.
Push the app_data is the best idea, just bear in mind, when the publishing the projects, if the option "Delete all existing files before publishing" is ticked, then the current data in the folder will be gone. The workaround is to skip the deletion of app_data folder.
Another option to do logging is to use some existing framework such as Log4net.