In 2011 I wrote a tool allowing web administrators to edit EPiServer’s language XML files through admin mode. As the code was constructed it assumed that the environment was properly set up (i.e. securing the plugins preventing unauthorized access), thus trusting the user. Anyhow, failing to do so opened up for unauthorized users to read/modify/delete certain files on the server/shares. Here is a summary of the changes in security made to the plugin. New version available on GitHub.
If access to the directory where you put the plugin (~/Plugins/ in this example) is not restricted it is possible for anyone to access it if they are aware of the proper URL to do so. In other words, a website visitor could potentially surf right into your http://yoursite.com/Plugins/LanguageFileEditor/LanguageFileEditor.aspx and start editing your language files. This is not a problem with how the Language File Editor is constructed but rather with the current setup of the environment. You should always make sure to prevent unauthorized access to sensitive directories. A quick way to do this for the Plugins directory is to add a location section in the web.config file.
If a user gets so far as to have access to the previous version of the tool, it is possible for them to read, modify or delete files on your machine and/or network shares. It is not very likely that an intruder would know exactly what URLs to use, how you set up the tool or that you even use it, but better safe than sorry.
For instance, accessing /Plugins/LanguageFileEditor/UpdateLanguageFile.aspx, setting the ContentType to application/json and injecting bad paths like ../../web.config or the like into targetFilename and patternFilename could have serious consequenses.
There are now two new classes added to the plugin code; one for ensuring that the user is valid should you have forgot to secure your Plugins directory, and one for ensuring that you stay inside the proper language file directory.
// You could let the exceptions thrown in this class be unhandled, and have ELMAH give you usernames, IP-addresses, and so forth.
Running EnsureValidRoles when entering either of the two plugin access points will make sure that only authenticated users with the roles WebAdmins or Administrators will be able to use the Language tool. If a visitor now tries to surf to the proper URL they will get an exception; or more likely a friendly error page.
In a similar manner there is a method for ensuring that the accessed path is inside the intended language directory.
The code is pretty straight forward; the accessed path is normalized before compared against a valid directory path. This ensures that the user is not trying to escape into other directories by using for instance ..\ or \\servername\. File extensions are also validated as all language files are XML files.
If I wrote this tool today I would probably never expose paths or filenames as input data, but rather assign each file a random id (likely a guid or something hard to guess) to pass back and forth.