Security
Prev Server Administration Next

Security

Mr. XML Publisher is subject to the same security constraints as all other web applications running on your server. Java web app security is usually handled by the web container, a proxy HTTP server, and specialized modules. In most cases, a web application does not provide its own security; however, Mr. XML Publisher does provide some security features you can use to augment existing security and help provide redundancy.

Your Mr. XML Publisher software license prohibits you from making your Mr. XML Publisher system publicly available over the Internet. Thus, unless you suspect that you have malicious users, your security focus might be on mainly preventing conditions that create accidental security breaches.

Security for your Mr. XML Publisher system can be grouped as follows:

Your Mr. XML Publisher system can be customized to provide more security, or less. If your local users are not malicious, there is probably no need for more security.

Control of Process Ownership

External subprocesses run by Mr. XML Publisher are limited by user permissions in the same way that all processes on your server are limited by user permissions. These external subprocesses inherit their ownership from the web container process; thus, if you allow the web container process to be owned by a privileged user, external subprocesses can be potentially dangerous. Never allow the web container process to be owned by root or a user who is a member of the Administrator group in Windows. If you do, Mr. XML Publisher's external subprocesses will run with excessive privileges. Consult your web container's documentation for instructions on how to control which user owns the web container process.

[Caution]Caution

Never allow the web container process to be owned by root or a user who is a member of the Administrators group in Windows. On both Windows and Linux/Unix, Mr. XML Publisher's ability to read files is constrained only by the filesystem permissions of the owner of the web container process. If the owner of the web container process has sufficient filesystem permissions, Mr. XML Publisher can read any file anywhere on the server. Thus, users' XML can reference and read those files too via external entities.

It is a good idea to run the web container process owned by a a user whose privileges are limited and explicitly assign ownership of all uploaded files to that user. Redundancy is often good when implementing security. Additionally, if you ensure that the owner of the web container process is the owner of all unpacked project files, there will be no file ownership problem when Mr. XML Publisher deletes the temporary working directory after servicing a formatting request.

If you use the appropriate <context-param>s in Mr. XML Publisher's web.xml file, no formatting request is ever serviced without first explicitly assigning ownership and permissions for the project's files. During request servicing, if the ownership and permissions for all unpacked project files cannot be successfully assigned, the request is aborted and an exception is thrown. See UNIX_CHOWN_COMMAND and WINDOWS_CACLS_COMMAND for information on how to assign ownership and permissions to uploaded project files.

Security Features Provided by Mr. XML Publisher

Security features provided by Mr. XML Publisher include:

  • Security-related web.xml <context-param>s

  • Default Prohibitions

Security-related web.xml <context-param>s

Each of the following web.xml <context-param>s helps prevent conditions that contribute to security risks. Consult web.xml <context-param>s for details on each.

Default Prohibitions

Mr. XML Publisher's default prohibitions are described as follows:

  • The "href" attribute values in <xi:xinclude> elements may not use network protocols (http, ftp, etc.). To prohibit the use of network protocols in external entity reference's, pass an appropriate option to the XSLT processor. For example, with xsltproc, the option is --nonet.

  • The "href" attribute value in either <xi:include> or <xsl:import> elements must not attempt to reference a file outside of the project directory. All "href" attribute values must reference only files beneath the project directory. For example: 

    <xi:include href="file.xml">

    or 

    <xsl:import href="subdir/file.xsl">

  • In project XSL, only one <xsl:import> element and only one <xi:include> element is allowed.

    Multiple <include> elements are allowed in a user's project XML, but a project's XSL is allowed only a single <include> element, and cascading <xsl:import> elements are strictly disallowed.[30]

Security Features Provided by Software External to Mr. XML Publisher

The following lists suggested solutions for security-related issues outside Mr. XML Publisher's scope. Other than editing changes in Mr. XML Publisher's web.xml file, implementing any of these suggestions requires no modifications to Mr. XML Publisher. All are transparent to it and work independently. Whether you chose to implement any of these suggestions is completely optional and depends on your local security policies.

  • User authentication and authorization

    Appropriately edit Mr. XML Publisher's web.xml file and use the security facilities in your web container or JEE server to activate user authentication and authorization.

  • SSL

    Use the SSL services provided by your web container, HTTP proxy server, or JEE server. Virtually all web containers, HTTP servers, and JEE servers either provide SSL services themselves or provide documentation on how to get SSL working with OpenSSL (http://www.openssl.org/).

  • Overall web security

    The ModSecurity package (http://www.modsecurity.org/) works well with the Apache HTTP Server (http://httpd.apache.org/). If you are using Tomcat (http://tomcat.apache.org/) as the web container with Apache as a proxy server, ModSecurity is a good choice.

  • Block uploads based on configurable criteria

    Use ModSecurity.

  • Scan uploads for viruses

    Integrate ClamAV (http://www.clamav.net/) with ModSecurity.


[29] When data is pulled from a data source and written to a file in the user's temporary project directory on the server, no mime-type checking is done before writing the file and no change of permissions is attempted for that file. Mime-type checking and changing of the file permissions is done only for those files uploaded from a user's project. Files created from data pulls are written to disk read-only, owned by the user who owns the web container process.

[30] If you wish to change this feature, contact Mr. XML Publisher support.

Prev Up Next
XML from a Data Store Home Logging