Description

If I click on an attachment with Internet Explorer and select "open," the application fails to find the file.

Steps to reproduce

1. Attach a file.
2. Click on the link using Internet Explorer. Select "Open" instead of "Save"
3. Observe "This file could not be found" error message in application (e.g. Word or Powerpoint).

Example

This page.

Testing_an_IE_bug.doc

Details

This wiki.

Workaround

• Use another browser
• Try it 2 times, on the second time it seems to work (while having the target program opened).
• Save the file and then open it

Discussion

Why is this a moin bug?

• Regardless of where blame is assigned (moin or IE), to IE users the wiki is broken because they can't "directly" open attachments of any kind (it's not just .doc) even though they can from any other web site they visit. Even if the problem lies with IE, there are other MoinMoinBugs that fit in that category, so I put it here. In any case, it's either a moin bug or a feature request because 1) I can't get my company to change the browser it uses; 2) I'm not going to get microsoft to fix IE (if it is the problem); and 3) I don't want to field any more calls saying the wiki is broken.

  • Well, I guess some IE user has to find out and make some concrete suggestions at least. E.g. showing what goes wrong and how it can be made working correctly. Some more details would also help (in case not every IE version has that bug). As IE doesn't work on my development machines, I personally can't help much. -- ThomasWaldmann 2006-06-15 13:34:03

  Some more information. I'm currently running 1.5.3. I just tried installing the "AttachFile.py" from 1.5.2 in my data/plugin/action directory and now opening attachments from IE6 works. I'll try to narrow down the difference between 1.5.2 and 1.5.3 that triggers this problem. Hopefully, I'm not asking for trouble using 1.5.2's AttachFile with 1.5.3 in the mean time. -- GregWhittier 2006-06-15 15:17:00

  • The change from revision 520 of AttachFile.py is where this problem starts. The changelog says "Fixed XSS issue which could lead to cookie theft etc." -- GregWhittier 2006-06-15 15:45:36

--- a/MoinMoin/action/AttachFile.py     Fri Mar 31 19:56:30 2006 +0000
+++ b/MoinMoin/action/AttachFile.py     Wed Apr 05 08:32:20 2006 +0000
@@ -644,7 +644,7 @@ def get_file(pagename, request):
-        "Content-Disposition: inline; filename=\"%s\"" % filename.encode(config.charset),
+        "Content-Disposition: attachment; filename=\"%s\"" % filename.encode(config.charset),

Thanks for tracking this down. Note that the above header line is completly valid HTTP.

Please try to check the options that are related to the .doc file entry in the CLASSES_ROOT registry branch. Check the DDE command line and downgrade to non-DDE to test this.

• I'm not a real windows guru, so I'm not sure quite what you're talking about, but I used regedit and looking in HKEY_CLASSES_ROOT\.doc found these keys/vals there:

• I don't see anything that looks related to DDE.

You can use the folder properties window to do it or check the "Word.Document.8" branch of the registry.

• OK, I used Control Panel->Folder Options and de-selected DDE from .doc. Now I get a similar but different error.

I should say that it isn't just word. I've tried a number of things: .ppt, .doc, .pdf, and .igx (Corel iGrafx) and all give some kind of error that says they can't find the file. I've looked in the temp directory and it's not there.

OK. I can reproduce the bug here. But I don't know a solution besides the abovementioned workaround. I strongly suggest not to reverse apply the above patch because it allows for simple XSS attacks that can lead to impersonation of other users.

I've found the bug in our intranet wikis, too (after upgrading from 1.3.4 to 1.5.4 code base). None of the IE users was able to open attachments correctly. By applying the patch above (replacing "attachment" with "inline") I was able to get back the "normal" behaviour. I suggest to re-think this trade-off between making XSS-attacks more difficult and excluding all IE users. What about making the way the attachments are served configurable (if it cannot be reverted to old behaviour)? -- DavidLinke 2006-08-21 15:59:15

Is this known http://joseph.randomnetworks.com/archives/2004/10/01/making-ie-accept-file-downloads ? example code

if(strpos($_SERVER['HTTP_USER_AGENT'], 'MSIE')) {
    session_cache_limiter("public");
}
session_start();
header('Content-type: application/octet-stream');
header('Content-Disposition: attachment; filename="report.csv"');
print($csv);

Simply changing attachments to inline wasn't enough. The following is why it doesn't work in IE. http://support.microsoft.com/default.aspx?scid=kb;en-us;243717&Product=ie The solution I found was to replace 'attachment' with 'inline' and also commenting out all the 'self.setHttpHeader' in the 'disableHttpCaching' method in request.py. For me that was lines 246,247,248,252,256

There's probably a better way to fix this but this was the simple fix I found that worked for me.

I doubt that simply removing the cache disabling code will make you happy. Your IE will maybe show you stale data now and then.

IE bug that seems to cause this: http://support.microsoft.com/kb/323308/EN-US/ - Microsoft also provides registry changes to fix the problem.

Our Apache setup on test.wikiwikiweb.de also seems to influence IE behaviour. Sometimes you get 2 or 3 different behaviours by just "trying again". It behaves different with standalone server (which even worked with SSL using tlslite library).

How to exploit systems that send attachments as "inline"

1. Create a short HTML file that transmits the current cookie via a simple XmlHttpRequest etc. to another (evil) site, or just display an alert window. In the end, it could redirect to another wiki page.

2. Attach this file to a wiki page.

3. Link to the attachment like e.g. this: [attachment:myfile.html Further explanations]

4. Login and click the link.

This is a typical XSS attack and can be used easily to steal the login data.

Plan

• Priority:
• Assigned to:
• Status:
  • this is no moin bug, but browser problems (esp. IE).
  • moin 1.5.5a and 1.6 have a workaround using a blacklist, but it doesn't fix all IE trouble. E.g. if you download a PDF file with IE, it sometimes does not work. Looking at the articles linked above, this is related to some IE bug - it downloads the attachment, but deletes it before the handling application can open it, because the internal caching component in IE saw some "no-cache" http header.
  • I did another change (for 1.5.6 and 1.6) to avoid nocache headers - please test it on this wiki with IE6 and .pdf, .txt and .html attachments.

    • For PDFs try WikiSandBox/test.pdf. Other test-attachments are also in WikiSandBox.

    • Works for me on IE6SP2 for jpg, txt and pdf. html-files are not opened but a download dialogue is shown.-- DavidLinke 2006-10-08 21:31:55

      • Download dialogue for everything potentially dangerous (html, swf, xml) is intended to protect user from unwanted code execution.

CategoryMoinMoinBugFixed