

Make sure if there aren't secure libraries to upload files already available.Īntivirus aren't worth it.


It is worth also setting X-Content-Options: nosniff, which can also protect against this. The scenario here is one newsletter editor compromising the session of another newsletter editor. This guards against XSS being achieved by upload of HTML containing script tags, or other Same Origin Policy bypasses using Flash or PDF files. It would also be worth virus scanning each file, just in case the newsletter author uploads (either maliciously or accidentally) a file that would attack subscribers' computers rather than the server.Īlso ensure that the Content-Disposition is set to attachment: Content-Disposition: attachment filename="filename.html" You can also use the handler to check that the current user has the correct permissions to load the file. This way you do not need to worry if in future you wish to serve additional file extensions as executable file types, as any file is served directly from a byte stream from the file system and is never passed through the web server handlers. Either way, I would sanitise the parameter to guard against directory traversal attacks.Į.g. The file could be requested either by original file name, a system generated file name or by an ID. I would then create a HTTP handler that would be linked to from the email, which would stream the requested file. I would allow any file extension to be uploaded, but I would store the files in a folder that is not directly served by the web server.
