Hi All -
Our Dev team is going to start building some upload data transfer
capabilities in some apps
Login, click upload - browse & then upload
So on the server - that means a write access -
what is the safest way to do this ??? keep the upload directory outside
of inetpub & lock down NTFS ??
Or something else ?
On Jun 13, 12:48 pm, ERoss
> Hi All -
>
> Our Dev team is going to start building some upload data transfer
> capabilities in some apps
>
> Login, click upload - browse & then upload
>
> So on the server - that means a write access -
>
> what is the safest way to do this ??? keep the upload directory outside
> of inetpub & lock down NTFS ??
>
> Or something else ?
There is no "safest way". Security is relative to the environment and
functionality that you want to provide.
In general, you are concerned with:
- User Identity that has write access on the server
- Filesystem Location of the uploaded file and NTFS ACL on that
location
- Whether user has read/script/execute access to the uploaded file or
not
User identity depends on whether you are ok with the anonymous user,
specified upload user, or normal authenticated users having write
access to a Filesystem Location
Filesystem location could be under inetpub, could be outside inetpub,
or even on a UNC share - depends on your needs
Based on Website/Vdir configuration, the Filesystem location may/not
be directly accessible via HTTP or support read (i.e. download) or
script/execute (i.e. run on server) access. Depends on if you want
users to have download access or not.
Proper configuration depends on your choice of security needs.
//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//
I would add to David's comments that with upload one
might be open to a denial of service of sorts if uploaders
are malicious and fill the available disk space. This can
be a consideration a) for the upload app design, b) for the
placement of the uploads, i.e. a non-critical partition
If the identities that login are Windows accounts then one
could consider use of filesystem quota on upload area.
"ERoss"
news:MPG.20da13f89e0078389896aa@msnews.microsoft.com...
> Hi All -
>
> Our Dev team is going to start building some upload data transfer
> capabilities in some apps
>
> Login, click upload - browse & then upload
>
> So on the server - that means a write access -
>
> what is the safest way to do this ??? keep the upload directory outside
> of inetpub & lock down NTFS ??
>
> Or something else ?
Thanks both -
More info - there is no anonymous upload - all accounts to access the
app are database driven -
I am hoping (but I am not a developer) that the coders can restrict file
type uploads (ie no EXE files)
There is nothing financial - so I don't need to worry about "bullet
proof" - but I want to make it at least difficult for a script kiddie to
dump a binary into a directory in IIS & call it
So yes, the user Identity on the server is the key one - the basic IUSR
account is running the web site - so I guess granting it write access in
one location would be easiest to maintain -
But again, in general is this safer outside of the inetpub environment ?
In article
says...
> I would add to David's comments that with upload one
> might be open to a denial of service of sorts if uploaders
> are malicious and fill the available disk space. This can
> be a consideration a) for the upload app design, b) for the
> placement of the uploads, i.e. a non-critical partition
> If the identities that login are Windows accounts then one
> could consider use of filesystem quota on upload area.
>
>
> "ERoss"
> news:MPG.20da13f89e0078389896aa@msnews.microsoft.com...
> > Hi All -
> >
> > Our Dev team is going to start building some upload data transfer
> > capabilities in some apps
> >
> > Login, click upload - browse & then upload
> >
> > So on the server - that means a write access -
> >
> > what is the safest way to do this ??? keep the upload directory outside
> > of inetpub & lock down NTFS ??
> >
> > Or something else ?
>
>
>
If you want to make it difficult to dump a binary into IIS and call
it, then you either:
1. Make sure no IIS directory has script/executables permission, so no
way to execute with IIS
2. Move the resource outside of HTTP namespace
However, this assumes that you do not have HTTP-accessible script
which transitively calls resources outside of HTTP namespace. For
example, for the gross sake of outlandishness, if you have /
Management.asp?execute=C:\windows\system32\cmd.exe , it doesn't matter
if you upload the binary outside of HTTP namespace if you have an HTTP-
accessible script which transitively crosses and executes code outside
the HTTP namespace boundary.
In other words, security is really about identifying and establishing
boundaries of trust and then access-controlling entities that cross
the boundary. There is nothing inherently secure/insecure about any
particular environment like inetpub. One can make inetpub secure or
insecure. One can also make non-inetpub secure or insecure.
//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//
On Jun 14, 6:33 am, ERoss
> Thanks both -
>
> More info - there is no anonymous upload - all accounts to access the
> app are database driven -
>
> I am hoping (but I am not a developer) that the coders can restrict file
> type uploads (ie no EXE files)
>
> There is nothing financial - so I don't need to worry about "bullet
> proof" - but I want to make it at least difficult for a script kiddie to
> dump a binary into a directory in IIS & call it
>
> So yes, the user Identity on the server is the key one - the basic IUSR
> account is running the web site - so I guess granting it write access in
> one location would be easiest to maintain -
>
> But again, in general is this safer outside of the inetpub environment ?
>
> In article
> says...
>
>
>
> > I would add to David's comments that with upload one
> > might be open to a denial of service of sorts if uploaders
> > are malicious and fill the available disk space. This can
> > be a consideration a) for the upload app design, b) for the
> > placement of the uploads, i.e. a non-critical partition
> > If the identities that login are Windows accounts then one
> > could consider use of filesystem quota on upload area.
>
> > "ERoss"
> >news:MPG.20da13f89e0078389896aa@msnews.microsoft.com...
> > > Hi All -
>
> > > Our Dev team is going to start building some upload data transfer
> > > capabilities in some apps
>
> > > Login, click upload - browse & then upload
>
> > > So on the server - that means a write access -
>
> > > what is the safest way to do this ??? keep the upload directory outside
> > > of inetpub & lock down NTFS ??
>
> > > Or something else ?- Hide quoted text -
>
> - Show quoted text -
It might be best to have specificed to the coders the reqs to let admins
gate an install's allowance of uploads by type and max size. Admins
should be aware that "executability" depends on more than extension.
For storage just do it where a disk-full only blocks new writes (uploads,
page content mods, etc. i.e. not an app or OS due to lack of space).
I don't comment on privilege issues/concerns as I tend toward app
pool indentites that only traverse permit thread from their root to
a piece of their partition and general user permits in the system.
--
Roger
"ERoss"
news:MPG.20db0d9569ac95b79896ab@msnews.microsoft.com...
> Thanks both -
>
> More info - there is no anonymous upload - all accounts to access the
> app are database driven -
>
> I am hoping (but I am not a developer) that the coders can restrict file
> type uploads (ie no EXE files)
>
> There is nothing financial - so I don't need to worry about "bullet
> proof" - but I want to make it at least difficult for a script kiddie to
> dump a binary into a directory in IIS & call it
>
> So yes, the user Identity on the server is the key one - the basic IUSR
> account is running the web site - so I guess granting it write access in
> one location would be easiest to maintain -
>
> But again, in general is this safer outside of the inetpub environment ?
>
>
> In article
> says...
>> I would add to David's comments that with upload one
>> might be open to a denial of service of sorts if uploaders
>> are malicious and fill the available disk space. This can
>> be a consideration a) for the upload app design, b) for the
>> placement of the uploads, i.e. a non-critical partition
>> If the identities that login are Windows accounts then one
>> could consider use of filesystem quota on upload area.
>>
>>
>> "ERoss"
>> news:MPG.20da13f89e0078389896aa@msnews.microsoft.com...
>> > Hi All -
>> >
>> > Our Dev team is going to start building some upload data transfer
>> > capabilities in some apps
>> >
>> > Login, click upload - browse & then upload
>> >
>> > So on the server - that means a write access -
>> >
>> > what is the safest way to do this ??? keep the upload directory outside
>> > of inetpub & lock down NTFS ??
>> >
>> > Or something else ?
>>
>>
>>