I face a situation where my web service needs to access partion D in server hard disk and can send, receive files to/from client.
Is it true that a web service can do that even when there's no permission on the folder?
I know that I can add to the folder of asp.net path using mappath function...
Can any one illustrate to me how this would be done and how can the web service access the server local disk?
In order for the web service to be able to either read or write files to a folder on your server it must have permission to do so.
The first question you need to determine is what user is the web service executing under? Once you know that then you can set the appropriate rights to the folder in question.
"Is it true that a web service can do that even when there's no permission on the folder?"
NO
Related
We have 2 servers in DMZ. First one is application server, let's call it APP machine. The other is a file server, let's call it FILE. Web site running on APP machine under IIS is trying to create a file in a shared directory located at FILE server.
When application pool is running with some user in IUSR_IUSRS or NETWORK SERVICE writing to remote location fails. I cant authorize this user in shared folder, because that FILE machine can only see local users.
I created a user X on APP machine (APP/X) and another one with the same username on FILE (FILE/X). Then I added FILE/X user to credential manager on APP machine. When APP/X and FILE/X users have different passwords writing fails again. But when passwords are the same then writing just works.
I cant understand why passwords matter. At the end of the day they are two different users APP/X and FILE/X. Could someone clarify this phenomenon?
When the local user account on APP attempts to connect to the FILE server it passes it's credentials (username and password). If that combination isn't an exact match against a user on the FILE machine then it will fail.
There are multiple ways to do this "correctly". The most common would be to have a domain setup in which the site on the APP server runs under. That way you could just authorize the user to have rights on the FILE server.
If you can't have a domain controller, then the username and passwords must be kept in sync on the two machines.
My team have been asked to 'enhance' a web app to permit the following. Is this considered a security risk in a web app? I'm not sure about this.
"Be able to access directories, for exporting and importing [data into the database] , outside of the virtual directory"
In other words the requester wishes to be able to navigate to a data file anywhere outside the application's IIS virtual directory, presumably when importing (or exporting) data.
I think this means on the web server, but it may mean local files on the client machine (to be clarified). But either way the question stands.
If you are talking about going outside the boundaries of the web application, that means a risk. Once you allow a particular user to go beyond your web application, then there is no more control in what that user could do with the webserver.
Have a look at path traversal attacks:
https://www.owasp.org/index.php/Path_Traversal
Also, here is a list of things to consider in order to avoid this:
https://www.owasp.org/index.php/File_System#Path_traversal
Any questions, just let me know.
Regards,
Fabio
#fcerullo
The question does not stand 'either way'. They are different questions. If it is about being able to select a file from the local computer to send to the remote server then that is pretty routine. e.g. one does it all the time while attaching a file to an email. The user is the one who initiates the file choice AND it is their file to send to the web app. No security hole here.
IF you have a need to allow clients to be able to browse the server computer for all sorts of files, then that itself is NOT a security hole. That is what you wanted, you got it. It is a security hole ONLY when you did not mean that the client should be able to grab hold of files off any whichever directory on the server. This whole scenario is classified as security issue because more often than not you do NOT want clients to have access to all inclusive files on the server. Typically the client needs to be able to access only certain files. Restricting you to virtual directory is one way of doing it. e.g. would you want your clients to be able to grab hold of the actual DB files with records of all users of your web site and then load that DB file in their own DB?
If you need to go beyond that, you need to implement mechanisms in place that allow access to only certain files. Remember your web server is running in the context of some user on the server OS. When the client request comes to the server, it that that web server user under which the command executes. So you cannot achieve security by simply putting in permissions for that web server user.
I have this load balanced asp.net application which needs to upload files to a shared location. The web app is not impersonated, which means it will cross the machine boundry using network service credentials. Now my question is, to which account do I need to assign permissions on the folder where the files are being uploaded? How can I say the network service of these web servers need write permissions?
If your server is part of AD domain, then you can add the Server itself from the security permission dialog to have read/write permission (in fileshare server). Remember to select "Computers" when searching Active Directory. Depending on your setup, might have to search from the root of your Active Directory or select "Entire Directory". You will have to add all of your servers that are part of load-balanced ring to have permission in fileshare server's directory.
If your server is not within an AD domain, then your local server's network service will not have any security context to write on another server; which means only generic permission will work (e.g. giving write permission to "Everyone").
Otherwise you will have to use UNC authentication. An example is posted here.
I have a web application that runs on SERVER_A. The web application calls a web service which runs on SERVER_B. The web service returns a set of folder names on the file system from SERVER_B. However the web service fails to return any content when I run my application from SERVER_A, but it works OK when I access the web service directly via a browser or my localhost i.e. via Visual Studio. I can get it to work for SERVER_A if I grant the machine name (SERVER_A) access to the file system via Properties > Security. But I don't think this is very secure..?
Ideally I need to grant a service account the correct permissions, but how do I do this? Do I need to run my application on SERVER_A as this service account in order for it pass the identity when it connects to my web service? If so how do I do this?
You can specify the credientials you are using with the webservice. Once you create your service account (if you haven't already) you can specify the credentials when trying to consume the webservice...here is a MS kb article (take a look at the "Second Method").
http://support.microsoft.com/kb/811318
When I access file whith UNC file path from asp.net, I found the following problem. Logon failure: unknown user name or bad password. Pls help me.
The problem may not be with the UNC nature of the path you're trying to access, but with the security credentials. If, for example, you are running your asp.net application under the System account, then you won't be able to access network shares because System is a local account (not a domain account).
I suggest you check in inetmgr under which user your application pool is running (under the Identity tab). Try using a domain account that can access that share.
The solution is held under the impersonation and delegation functionality of asp.net. There are certain constructs which provide a token based security scheme to call a file.copy operation for example with the target being a UNC location. You can check it here.
The account "in charge" when the file access request is issued simply must be lacking credentials to access the share / resource found at the UNC location.
You first need to determine which account is effectively used, as this may vary, and provide the relevant privileges. By default most programs, including .NET programs (to a lesser extent) will run in the security context of the account which launched the program, however this doesn't hold, in many situations, for example if the program is a service of sorts, or if it uses some DCOM objects, or if it impersonate some other accounts etc... Also .NET has a relatively sophisticated system of delegation/impersonation.
One way to diagnose this issue is to add auditing at the level of the UNC file/directory. Upon failure this will leave a event which should show the login name of the account which tried to access the share.