Drag and drop file uploads in IE with .NET

I’ve received a couple of requests lately about how to implement drag-and-drop multiple file uploads in Internet Explorer from within managed code. Fortunately for me, someone else has already taken the liberty of writing an article on the subject at large: Host Secure, Lightweight Client-Side Controls in Microsoft Internet Explorer. Just a couple of tweaks and it’ll be accepting files via drag and drop too.

In MultiUploadCtrl.cs, we need to enable drag and drop processing in the user control. Setting AllowDrop=True handles that in one swoop, now all that’s left is the plumbing to handle the dropped files. For the events, DragEnter and DragDrop, the following should work well:

private void MultiUploadCtrl_DragEnter(object sender, System.Windows.Forms.DragEventArgs e)
if (e.Data.GetDataPresent(“FileDrop”))
e.Effect = DragDropEffects.Copy;
e.Effect = DragDropEffects.None;

private void MultiUploadCtrl_DragDrop(object sender, System.Windows.Forms.DragEventArgs e)
new FileIOPermission(PermissionState.Unrestricted).Assert();
foreach (string fileListItem in (e.Data.GetData(“FileDrop”) as string[]))
if (!fileTable.Contains(fileListItem))

Comments (12)

  1. Anonymous says:

    And as soon as somebody installs this you can use it to lift files from their system without them even knowing (just call AddFile with as many files you need and submit a form, no user interaction required).

    I would expect Microsoft employees to be a little more responsible when posting deliberate security holes on the internet.

  2. Anonymous says:

    A good point that would be true in the ActiveX world without other considerations.

    The column does speak to this problem in the ‘New Security Model’ section. The standard permission set for controls loaded in the Internet zone won’t allow for arbitrary file system access, it has to be explicitly granted through the configuration tool (or a setup package) and even then is subject to the hierarchy of enterprise, machine and user settings.

    Extending this sample, additional steps along the lines of

    a) checking FileUploadURL (‘site-locking’ so uploads can only go to the site the user expects them to)


    b) explicitly prompting the user with the list of files before uploading

    could also be used to good effect.

  3. Anonymous says:

    The problem with security is that users who will have a valid use for this will allow it to run and access the file system without restrictions (being able to specify a restricted access, such as read-only and only within current user’s profile/my documents would help a little too).

    Prompting the user is probably the only way to prevent mis-using this, because when would you check the action url? You can attach an event handler to submit event and change it there, from legit to a rogue one.

    As for calling AddFile – you can hide it, making it inaccessible to a script in a page, but any script will be able to craft an event object and call your event handler, making it just a little more difficult to misuse but not fixing the problem.

    Maybe Secure computing initiative should also apply to examples posted on MSDN 🙂

  4. Anonymous says:

    Dude, calm down. If you don’t like it, don’t deploy it. I think this sort of control is intended for use in an Intranet environment. The question was HOW to do this, not WHAT are the reasons not to.


  5. Anonymous says:

    The eternal conflict between features and security: how to do more things vs. how to prevent them.

    This code example is interesting, because it does use the .NET security model (requesting a permission then using it then reverting it). But it seems the granularity is still causing problems: you can’t give access to one file without giving access to all files…

    The only solution I have ever seen to this problem is the E language and other capability-based security systems (like EROS). Check out http://erights.org and the Skynet Virus talk.

  6. Anonymous says:

    Hmmm. I can’t seem to get the code from the article working. At one point, the article mentions an error I SHOULD be getting, but I’m not. In fact I’m not getting a whole lot of anything. Just what looks like a blank, scrollable frame where the control ought to be.

    Also, I don’t remember having to set any code access permissions when setting up the Workspaces source control Winform components, although I did have plenty of OTHER problems at the time. Any chance you could shed some light on how this was done?

  7. Anonymous says:

    I don’t remember if the article explicitly mentions this, but have you copied the generated assembly (bindebugupload.dll) into the ServerFileUpload folder in your wwwroot? A blank frame suggests the browser is unable to retrive the assembly from the server. This post http://blogs.msdn.com/aoakley/archive/2003/06/20/49627.aspx has some pointers for further debugging.

    Regarding Workspaces, the permissions are granted as part of the installation package along with a few other checks. The installation package has a custom install action (extending System.Configuration.Install.Installer) that creates the code groups and permissions sets (see System.Security.Policy and System.Security.Permissions) before using System.Security.SecurityManager to save the modified policy.

  8. Anonymous says:

    Counts: .NET:9; Admin:2; Blogging:2; Dev:0xF; Funny:1; Security:1; SQL:3; Tools:2; WILY:6; XML:4. Line of the day:

  9. Anonymous says:

    I got a problem when set control’s allowdrop = true. If I did that, the control itself can not been shown in Internet Explorer properly, which looks like un-open image, any helps?

    Many thanks