Security
webMathematica security can be divided into two parts. First, there is security concerned with general web server security. Secondly, there is security concerned with the use of Mathematica language programs inside a web server.
Server Security
webMathematica is based on standard web server technology: Java Servlet and JavaServer Pages (JSPs). Typically, it runs in a server called a servlet container such as Apache Tomcat. This greatly facilities security issues, because these technologies already have many well-documented and well-understood security features.
The Apache Tomcat wiki site, http://wiki.apache.org/tomcat/FAQ/Security, states "There have been no public cases of damage done to a company, organization, or individual due to a Tomcat security issue." Many other servlet containers have similar security records.
To decide how much security to add to your server, start by checking the security policy of your organization. You can then decide whether you want to add features such as restricting server access to users within your organization, locating the server in some special network, setting up authentication, and using HTTPS for communication.
These security features, and many others, are all well supported for many types of servers. Remember that some of these solutions, such as restricting access, might not be available to all webMathematica licenses.
Mathematica Program Security
Mathematica is a general programming language with many features and tools for interacting with the computer on which it runs. For example, it can add, delete, and modify files as well as launch and run programs. Since webMathematica executes Mathematica programs on the server, this means there are security implications. It is necessary to prevent unintended execution of Mathematica code.
The Mathematica programming language is a very dynamic language, and consequently, it is very straightforward for one Mathematica program to construct another. In fact, it is quite easy to pass a textual form of a Mathematica program as a string, turn it into a program, and execute it. This dynamic nature is an important security issue to consider.
webMathematica provides a security process to guard against such problems. The main focus is to prevent input from the external world from being accepted by a webMathematica program and executed. The security process analyzes input from the server and accepts or rejects it based on a set of criteria. The webMathematica developer writing scripts in Mathematica uses functions from the security system, and this ensures the security of the server.
MSPBlock
MSPBlock is one of the key security functions for webMathematica. It is useful for taking input to the server and converting it to be used in a computation. A typical script, taken from the example Expand.jsp, is shown below.
Remember that variables starting with $$, such as $$expr, are input variables. These have been transmitted as part of the web request and are potential sources of attack. In fact, giving them a special naming convention, which draws attention to them, is one security feature. Using MSPBlock avoids security problems because it applies the security test to its variables, in this case $$expr and $$num. If either fails the test, a security exception is thrown and the body is never evaluated; in fact a page error results. (The section on handling errors shows how you can custom the exact behavior of page errors.)
MSPToExpression
MSPToExpression is the other key security function for webMathematica. It is used for taking input to the server and turning it into a Mathematica expression that can be used for computing. A typical script, taken from the example Integrate.jsp, is shown below.
<msp:evaluate>
integrand = Null;
If[ MSPValueQ[ $$expr],
integrand = MSPToExpression[ $$expr]] ;
</msp:evaluate>
If the variable $$expr failed the security test, then MSPToExpression will throw a security exception and the page will be terminated. You can modify the treatment of page errors as discussed in the section on handling errors.
Avoid ToExpression
One of the key functions to avoid is ToExpression, the command that turns a string into a Mathematica program. In fact, well-written Mathematica programs rarely need to actually use this. One case might be when an input has been passed with the web request. But this is exactly what MSPToExpression is for, and ToExpression should not be used.
webMathematica still provides a check to prevent users from calling ToExpression on input to the server. For example, in the following the security test is still applied to the input.
This provides an extra level of security, though it would be better to use MSPToExpression.
You can disable this check. This is described in the section on ToExpression Validation.
Security Validation
This section describes how the security validation process works and how it can be customized.
The Validation Process
The validation process works in a straightforward manner, and you can customize it to give more or less security. You can investigate its operation in the following steps.
First, load the MSP Mathematica application and then lock down the security model, which cannot be modified after SetSecurity is called. When the server initializes Mathematica, it calls SetSecurity.
| In[1]:= |
| In[2]:= |
Now you can test expressions for validity. The first example shows a harmless mathematical expression that is found to be secure.
| In[3]:= |
| Out[3]= |  |
Here is a less-than-friendly expression, the sort of thing that could be sent as an attack.
| In[4]:= |
| Out[4]= |  |
Validation works by collecting all the symbols into a list and steadily reducing the list. If any symbols remain after reduction, the expression is not secure. The reduction process works with lists of symbol and context names that either can be allowed or disallowed according to the following steps.
1. If AllowedContexts is set, remove symbols with these contexts, otherwise remove symbols with contexts not in DisallowedContexts.
2. If DisallowedSymbols is set, remove symbols not in DisallowedSymbols, otherwise remove symbols that are in AllowedSymbols.
3. If no symbols remain, the expression is secure; otherwise it is not secure.
These tests allow you to be restrictive or flexible. If you use the allowed lists, you are restrictive and have more security, whereas if you use the disallowed lists, you are less restrictive and have less security. It is up to each individual site to decide the appropriate balance.
When the server is started, a default security model is installed. This default security model looks like this.
This is the value of AllowedContexts.
| In[5]:= |
| Out[5]= |  |
This is the value of AllowedSymbols.
| In[6]:= |
| Out[6]= |  |
DisallowedContexts has the value Null.
| In[7]:= |
DisallowedSymbols has the value Null.
| In[8]:= |
This model will allow any symbol in Global` context, in addition to a number of other specific symbols. This is a fairly restrictive model that provides a higher level of security.
Configuring a Security Model
To make your own security definitions you should put them into a file in the /WEB-INF directory. The name of the file is set in the MSPConfiguration.xml file with the configuration parameter SecurityConfigurationFile, which refers to the name relative to the base web application. For example, if the configuration information is in a file called ComputeSiteSecurity.m, inside of WEB-INF, the following should be added.
<SecurityConfigurationFile>
/WEB-INF/ComputeSiteSecurity.m
</SecurityConfigurationFile>
A sample security configuration file is shown below. This only allows symbols in the Global` context in addition to Plus, Times, and Power. This is a particularly restrictive security system that might be appropriate in some circumstances.
{
"AllowedContexts" -> {"Global`"}
,
"AllowedSymbols" ->
HoldComplete[ Plus, Times, Power, HoldComplete]
}
As described in the section on Multiple Kernel Pools, it is possible to use different configuration details for different request URLs. Each pool has its own configuration file and its own security system.
When each Mathematica kernel is launched, the security data is sent to the log system at the DEBUG level.
ToExpression Validation
The webMathematica security system adds a security test to ToExpression when it is used on input from the server. This is described in the section on avoiding ToExpression.
You can disable this security test by setting the Mathematica variable MSP`Utility`CheckToExpression to False. In addition, you can disable the test in the MSPConfiguration.xml file with the configuration parameter CheckToExpression.
<CheckToExpression>
false
</CheckToExpression>
It is probably an exceptional site that disables this security feature.
Of course, if the string input to ToExpression comes from an input sent with the request, but is modified in some way, the call to ToExpression will not carry out any validation. Therefore, it is highly recommended that you never use ToExpression, but instead use MSPToExpression.
Security and Kernel Pools
The security system is configured as part of a kernel pool. This means you can have different styles of security configuration for different types of access. More information can be found in the section on kernel pools.
Access Restrictions
You may wish to restrict access to certain parts of your system such as the Kernel Monitor, which is provided for monitoring and debugging your system. In this case, refer to the sections on Logging and the Kernel Monitor. The installation section on Apache and Tomcat describes how this can be done when webMathematica is used from the Apache web server.