|
| Best Practices for Impersonation and File Upload? |
|
|
|
|
| Messages |
|
Related Types |
This message was discovered on microsoft.public.dotnet.framework.aspnet.security.
Responses highlighted in red are from those people who are likely to be able to contribute good, authoratitive information to this discussion. They include Microsoft employees, MVP's and others who IMHO contribute well to these kinds of discussions.
| Jed (VIP) |
I can't seem to find a definitive answer on this subject.
I have a web page which provides the file upload control. When it posts to the server I attempt to save the file to the server with uploadedfile.SaveAs(localpath). This of course fails because the ASPNET account does not have access to the localpath.
My solution was implement the code found at:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q306158
I have a special static method which accepts the uploaded file, changes the security context, saves the file and calls the context.undo.
This doesn't work because of the reasons noted. One of the following must be done.
Grant the "Act as part of the operating system" privilege to the ASPNET account (the least privileged account).
NOTE: Although you can use this method to work around the problem, Microsoft does not recommend this method.
Change the account that the Aspnet_wp.exe process runs under to the System account in the <processModel> configuration section of the Machine.config file.
However, both options are apparently a security risk.
I don't get it. Should I give ASPNET change permission to the upload folder? Should I grant "Act as part of the operating system"?
What's worse? What's better?
|
|
|
| |
|
|
| |
| |
| Raterus |
Grant ASPNET permissions to the folder, assuming the folder is on the same server IIS is running. If not, you'll have to go for another option.
Don't ever grant ASPNET "Act as part of the operating system", people who really have no understanding how security works recommend that, and it would fix the problem, but the ASPNET would essentially become like "God" to every file on the webserver, as the account would be given full access to the entire filesystem, voiding any NTFS permissions you may have set.
I'm not quite sure how exactly you wanted to fit impersonation into all of this...
--Michael
"Jed" <Click here to reveal e-mail address> wrote in message news:Click here to reveal e-mail address...
[Original message clipped]
|
|
|
| |
|
| |
| |
| Jed (VIP) |
Thanks, Michael,
Yeah, I have read differing opinions regarding "Act as part of the Operating System"
As one person said, "It can be a security risk, but IMHO only in combination with other high-level privileges as 'Log on Locally' etc. The ASPNET account is pretty much a low-privileged account by default."
Your answer seems more in line with the result I would suspect.
Regarding your question, "I'm not quite sure how exactly you wanted to fit impersonation into all of this..."
I wanted to temporarily take on the identity of a user with more access using the WindowsImpersonationContext in order to write the file to the server and read it later.
My primary concern is exposing the uploaded files in an insecure directory on the server where the ASPNET user has direct access.
It seems that you can't restrict access to the directory or the files using the config file because that only controls access to files which are processed by the aspnet_isapi.dll.
The only recommendation I can find is to append a ".resources" suffix to the end of each file uploaded, which is inconvenient overhead on all file access.
[ref: http://www.wwwcoder.com/main/DesktopDefault.aspx?tabId=68&mid=407&site=1795]
|
|
|
| |
|
|
| |
| |
| Joe Kaplan \(MVP - ADSI\) (VIP) |
The "only combined with other high-level privileges" statement really isn't
true about Act As Part of the OS. The thing about that privilege is that it
lets you bypass OS security in kernel mode, so you can make yourself into
the SYSTEM account if you know what you are doing.
This is something you definitely don't want, even if the likelihood of
someone being able to exploit this is extremely low. There is still an
argument to be made that by default the account is less powerful than
SYSTEM, but be clear about what it is giving you.
Joe K.
"Jed" <Click here to reveal e-mail address> wrote in message
news:Click here to reveal e-mail address...
[Original message clipped]
ASPNET account is pretty much a low-privileged account by default."
[Original message clipped]
server and read it later.
[Original message clipped]
processed by the aspnet_isapi.dll.
[Original message clipped]
access.
> [ref:
http://www.wwwcoder.com/main/DesktopDefault.aspx?tabId=68&mid=407&site=1795]
[Original message clipped]
|
|
|
| |
|
|
| |
| |
| Jed (VIP) |
Thanks, Joe,
Since "Act as part of the OS" is not a good option, what is the recommendation for handling file uploading and more importantly securing the uploaded files directory?
It seems like giving the ASPNET user change access to a directory in the web site poses a security risk.
See my previous posts in this thread for further description.
|
|
|
| |
|
|
| |
| |
| Joe Kaplan \(MVP - ADSI\) (VIP) |
I missed where the thread started. If this is using Windows security in
IIS/ASP.NET and the files are on the local file system, then it should be
easy to just turn on impersonation in web.config. Impersonation can get
ugly if you need to hop to another machine, but that can be fixed by
enabling Kerberos delegation.
Joe K.
"Jed" <Click here to reveal e-mail address> wrote in message
news:Click here to reveal e-mail address...
[Original message clipped]
uploaded files directory?
[Original message clipped]
|
|
|
| |
|
|
| |
|
| |
| Raterus |
How is your current security set up on your application, anonymous access, or some type of windows authentication/basic authentication?
If it is anonymous, you will need to just give permissions to the aspnet user, and hope for the best, but if you really want to secure this application, get the authorized users windows accounts, and either get their credentials from basic/digest/integrated authentication and use the first method in that article, or use forms authentication/authenticate against active directory and use the second method in that article, That way you can set NTFS permissions on the folder with these user accounts, rather than ASPNET.
--Michael
P.S. Joe K is my ADSI Hero :-)
"Jed" <Click here to reveal e-mail address> wrote in message news:Click here to reveal e-mail address...
[Original message clipped]
|
|
|
| |
|
| |
| |
| Jed (VIP) |
The site is configured for anonymous access, because the forms which post files are open to the public who are requesting software demos which requires including sample files.
So I guess the answer is hope for the best, and see if I can get the files out of the browseable web.
Thanks
"Raterus" wrote:
[Original message clipped]
|
|
|
| |
|
|
| |
|
| | |
|
|
| |
| Jed (VIP) |
Thanks, Joe,
So, if "Act as part of the OS" is not a good option then what is the recommended approach for uploading files and protecting them once they are there?
It seems like giving the ASPNET user NTFS change permission on a directory in the web site would open up a security vulnerability?
(See my previous posts for further explanation.)
|
|
|
| |
|
|
| |
| | |
|
|
|
|
|
|
|
|
|
|
|
BootFX
Reliable and powerful .NET application framework. |
|
|
|
|
|
|
