Re: File Upload - Security Issues
From: Azz (Azz_at_azz.com)
Date: 10/19/04
- Next message: McKirahan: "Re: Decode base64 string"
- Previous message: Xander: "Re: Need script to delete a registry key"
- In reply to: Roland Hall: "Re: File Upload - Security Issues"
- Next in thread: Roland Hall: "Re: File Upload - Security Issues"
- Reply: Roland Hall: "Re: File Upload - Security Issues"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 19 Oct 2004 10:27:42 +0100
"Roland Hall" <nobody@nowhere> wrote in message
news:<OWX0JEYtEHA.3572@tk2msftngp13.phx.gbl>...
> "Azz" wrote in message news:%23OLf10StEHA.2244@TK2MSFTNGP10.phx.gbl...
> : I've been faced with a bit of a pickle and was wondering if anyone here
> : would be able to help me out clear up a few points. I am wanting to
upload
> a
> : file (unspecified type as of this moment, but could be MS Word, Access,
> : Excel etc).
>
> You're kidding, right? You want to upload a file for what reason and you
do
> not know what type? One would think your goal would be defined first and
> then you would try to determine what the best solution would be. I'm sure
> your agument may be that but the difference in non-executable file types
> doesn't factor in.
How can this be possible? I have a list of files that potentially be
uploaded and the user could upload any or all of these in theory. Maybe you
misunderstood, or maybe I mis-explained. "unspecified" was intended to mean
that I don't say what files people must upload. I simply limit their choice.
I can't believe a big list of the applications will be required for this
point.
My goal is very well defined, but I tried to keep my problem explanation
brief so the fact people wouldn't have to read 4 pages of crap before they
arrived at my question.
> : We've spoken to a number of people including our tech team who
> : are concerned about uploading these files to our Windows 2000 (or NT)
box
> : running IIS using ASP.
>
> And those are?
To be honest, I'm not too sure. I ask the question to our technical support
team and they gave me the answer that from past experience, this was not the
way to go. Microsoft Word/etc documents can contain Macro's which can, from
my memory contain viruses. I am told therefore, if placed on a Unix box,
these viruses have less chance of being able to execute (even if succeeded
to attempt to do it) than if on a Windows box.
> : So we've had to come up with an alternative solution
> : and we have a few ideas on ways around it.
>
> Perhaps the purpose of locating the file on the web server and which type
of
> file and what pitfalls you see re: security might be helpful on this end?!
The process is:
* Mr Joe public wants to tell us some information, and possibly attach a
document which details more information, a presentation, results of some
kind, blah blah blah! It's worth noting that Mr Joe Public is exactly that:
any member of the general public.
* He then fills in our form and uploads his files.
* These files are then saved to the file system, virus scanned, and then
accessed by someone inside my organisation.
> : Firstly I guess I should ask; Should I be worried about uploading MS
> Office
> : files to an IIS server that doesn't have MS Office actually installed?
>
> What are you worried about? How does your data file present a problem to
> security?
Macro's can contain malicious code. MS Office documents can contain macros
and viruses.
>
> : I am
> : told, and therefore expect that this is not a good security situation...
> so
> : I look at other ways around.
>
> And, I repeat, that is?
Because it's feared that these files could be opened, causing some malicious
code to execute.
> : This leaves me with the option of palming the file off to PHP/Unix box &
> : scripting where it will be quite a bit safer.
>
> How is it safer?
MS Office isn't native to Unix boxes, neither does the filesystem work the
same.
> : One way that appears to be a
> : possible solution is to do it as follows:
> :
> : 1* HTML displayed with a form (multipart/form-data enctype) and a file
> input
> : box.
> :
> : 2* Upon submit this is submitted to an ASP page that then (using the XML
> : object in ASP) effictively "posts" the information directly to the PHP
> page.
> :
> : 3* This PHP page then takes the file and saves it to the Unix
filesystem,
> : and then, completes it's processing and sends XML information of the
file
> : back to the ASP page.
> :
> : 4* The ASP finishes parsing and displays the next bit of HTML displaying
> : whatever.
> :
> : We have successfully set up a XML submit to the PHP that retains all the
> : Request.Form post information as well as the multipart binary file.
> :
> : The problem I foresee (and basically my main question):
> :
> : * The IIS, when sending the multipart information, I presume it must be
> : storing the file in a binary temporary file somewhere? If so, is this
> : something that could be run?
>
> Run? It's a data file. How can it be run if you are referring to being
> executed? Surely you do not think a temp data file is executable?!
Ok, open. And once open the Macro's/Virus runs it's evil code.
> : Therefore kinda making this process pointless.
>
> Still looking for the point.
Yeah, it appears to have been lost. I want to know if I should be worrying
about having Microsoft Office files on the Windows server and whether they
could indeed be run by a clever attacker. And also, if doing it the way I
proposed in anyway reduces this risk. Note that if question one returns an
answer similar to "there is no risk", then question two would'nt really be
an issue obviously.
> : We are trying to avoid using PHP in great chunks as there is only myself
> and
> : one other in our office that have had any hefty experience of it, and
> : therefore, it would make it largely unmaintainable!
>
> A file upload process requires a lot of maintenance? No matter what you
> choose, if that becomes part of your infrastructure, people will have to
> brought up to speed or replaced with those that have or are willing to
learn
> the knowledge required to maintain it.
>
> : I hope this makes sense,
>
> Not really. So far, all I've seen is unsubstantiated claims that one web
> server/technology is greater than another. You're referring to security
yet
> you have to shown any reference to SSL, certificates, VPN, etc. We also
do
> not know your network design so we do not know where the [target] server
> resides or any information regarding your security model. If your server
is
> outside your control [hosted] then it's important to know that and if it's
> not, why not just make a network connection on the LAN?
My "claim" is that one web server is built upon the same technology and
backbone as some of the files I potentially upload. Therefore I ask, "is
this safe"?
SSL? How would that help this situation? That would stop third parties
taking part in transactions.
Certificates? For everyone in the world?
VPN? That allows me to "dial-in" to the network. I don't think giving
general public this would be something we'd consider doing in a great rush.
> : Any pointers on the above? Or as importantly, any pointers on things we
> have
> : missed from our logic?
>
> No pointers to offer yet. Still need a lot more information. It appears
> you're looking for a vote, one way or another, regarding IIS/ASP vs
*nix/PHP
> and that is too limited to answer since neither, in itself, has anything
to
> do with security. And, no matter how one differs from the other, your
> developer(s) can also render either/both of them completely insecure.
Yes, it's possible the developers could do. But we're not up to that stage
yet, we are still trying to work out how it works, and if what we are doing
is in the correct direction.
Thanks for your time,
Azz P
- Next message: McKirahan: "Re: Decode base64 string"
- Previous message: Xander: "Re: Need script to delete a registry key"
- In reply to: Roland Hall: "Re: File Upload - Security Issues"
- Next in thread: Roland Hall: "Re: File Upload - Security Issues"
- Reply: Roland Hall: "Re: File Upload - Security Issues"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
