David Day

According to http://msdn.microsoft.com/library/default.asp url=/workshop/author/dhtml/reference/objects/input_file.asp

¡°Internet Explorer 7 or later. To improve security and prevent disclosure of system configuration details, file names no longer include folder (directory) details when submitted to the server process.¡±

I have tested several IE7 systems both XPSP2 and Vista and both still provide the full path to the file in the form data. Is the documentation wrong Or was this changed at the last minute before the release of IE7. There was a post in the blogs where people were seeing this and the response is that it was as designed not to show the path but it currently appears to be different.



Re: Internet Explorer Web Development Will the real file input post behaviour please stand up

BeauLA

I haven't tested this behavior, but I bet Microsoft backed off on implementing this change when they realized how much unexpected breakage it would cause.

If you assume a "typical" web model, then the server has no need of the full path to the file... that's a client file path that means nothing to the server.

Unfortunately, this "typical" model does not encompass many legitimate, important ways in which people use IIS. I have worked on projects where IIS had to serve pages to an instance of IE on the same machine. This architecture was largely dictated by the fact that the developers wanted to use ASP.NET (as opposed to WinForms). (I know, I know... I should feel guilty for ever doing this. I am dirty... who could ever love me But WinForms is kind of lame, especially if you're used to ASP.NET, and we were going to use network calls, generic handlers, etc. any way, so using IIS / ASP seemed like a good idea at the time...)

Another problem we had with this atypical architecture was the server-side prohibition against doing anything with a GUI. That is, an ASP.NET code-behind cannot (under XP SP2+) display a message or dialog box, or even spawn an app with a GUI. Again, under the typical web model, maybe this makes some sense. A real web server does not need to display forms on its own monitor as a result of page requests. But in our case (where IIS and IE run on the same machine), sometimes it did make sense for IIS to open the GUI app or form as opposed to IE. I never found an easy way around this, and what we ended up implementing was a do-it-all client-side ActiveX object that runs the GUI app. (Nice job patching that security hole, guys... using ActiveX is much, much safer, right )

Returning to your issue, I fail to see the big problem with forwarding the entire path to the server, even in a typical web app. So what if the web server knows that I keep my images in "c:\images," for instance Is that like knowing the prefix code in Star Trek II Can they bring my whole PC down by knowing where I keep my files Please... I realize the underlying security theory is to share as little information as possible, but the risk/reward ratio in this case still favors sending the full path (as Microsoft has apparently realized).

I think there is a philosophical dispute in play here also. I get the sense that many network / security / infrastructure professionals operate under the mistaken assumption that a secure, reliable network is an end in itself. It's not. I can achieve complete IT security at any location simply by removing all the computers / networking hardware. That's an extreme example of a very real (and very mistaken) philosophy that some IT professionals have.

A more realistic example of this mistaken philosophy was the file extension blocking for attachments that was originally part of Office XP. It achieved near total immunity from trojan horse attacks by essentially removing the ability to receive mail attachments. Microsoft must have backed off (I still get my attachments), but my experience as an "early adopter" of XP really soured me on Microsoft and their clumsy attempts to implement security.

Another general statement I will make is that Microsoft makes some very good software but is often clueless about how it is (or should be) used. I like VS.NET, IIS, etc. but I often find their associated code samples and guidelines to be worthless. I have a book titled "Practical Guidelines and Best Practices for VB and C# Developers" which, though full of useful material, is riddled with overly general blanket statements, nice-sounding but impractical rules, and some flat-out bad advice. For example:

"Place all of your user-interface strings in a resource file rather than burning them in code." (p.36)

"Methods should have a single exit point" (p. 148)

"Use three spaces for each indenting level" (p.14)

"Use tabs instead of spaces to indent code" (p.13)

Briefly, I would assert that the first guideline assumes too much about my architecture; that the second guideline can legitimately be violated in cases where an error has occured and I want to make darn sure I exit the method; that the third guideline is just petty; and that the fourth guideling is dead wrong.

In summary, I would say that Microsoft is much better at implementation than they are at grasping the big picture. If you tell them to prevent buffer overrun attacks in the CWiffleSnaffleEx class, they can probably do that. But they may break some useful, legitimate code in the process, and they are likely ignorant of the overall place CWiffleSnaffleEx has in computer science as a whole.






Re: Internet Explorer Web Development Will the real file input post behaviour please stand up

David Day

I also believe they backed out the change. I am looking for an Official word from Microsoft and to update their documentation. It seems silly to not put the full file path in the multipart data automatically but still allow local access Jscript. A malicious coder could still get the file path.