Security
web
Mathematica 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
web
Mathematica 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 web
Mathematica 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 web
Mathematica 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.
web
Mathematica 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 web
Mathematica program and executed. The security process analyzes input from the server and accepts or rejects it based on a set of criteria. The web
Mathematica 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 web
Mathematica. 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.
<msp:evaluate>
MSPBlock[ {$$expr, $$num},
Expand[$$expr^$$num]
]
</msp:evaluate>
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 web
Mathematica. 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.
web
Mathematica 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.
<msp:evaluate>
val = ToExpression[ $$num]
</msp:evaluate>
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.
Now you can test expressions for validity. The first example shows a harmless mathematical expression that is found to be secure.
Out[3]= | |
Here is a less-than-friendly expression, the sort of thing that could be sent as an attack.
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 A
llowedSymbols.
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.
Out[5]= | |
This is the value of
AllowedSymbols.
Out[6]= | |
DisallowedContexts has the value
Null.
DisallowedSymbols has the value
Null.
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 web
Mathematica 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 web
Mathematica is used from the Apache web server.