Security is a very important aspect in the design of Wims. As the system allows remote visitors to execute various programs on the server, care must be taken to avoid the following risks.
Resource exhaustion. A user may ask for a computation (for example factoring a very big integer) which takes hours. Not seeing the result coming, he then clicks on the 'reload' button of the browser for several times, and the server would end up with several copies of the background computing software running endless loops, completely exhausting its CPU resource.
Our solution is to set up a limit to the CPU time allowed to all programs called by Wims. A limit of 20 to 30 seconds, which corresponds roughly to the limit of an ordinary user on the Internet, is sufficient for most computational needs. This limit is configurable at the installation level.
Other resource limits are defined: memory size, file size, etc. But these are less restrictive, as they are not as crucial as CPU time.
It also occurs frequently that an impatient user repeatedly clicks on a link if he doesn't see immediate response. This may overload the server if the link requires a lot of computation on it. For this reason, Wims prohibits further requests by the same user until the processing of the first request finishes.
Finally, a two-level load limit can be defined. Requests to the server are refused when the server load exceeds the limit, with an error message sent to the user, suggesting him to try gain later.
Infiltration risk. Several softwares interfaced by Wims contain commands allowing the user to escape to the operating system. Any possibility for a remote user to gain access to such a command is a security hole. In particular, such a possibility should not be present when the user answers an exercise or requests a computation to tool.
The ultimate solution is to let interfaces to these programs systematically deny access to such commands. For many softwares, it is very hard to achieve an absolute security in this way. So when writing modules, we are taking care not to let raw text supplied by users to be directly fed into background computing programs. Usually user-supplied text appears only as content of a particular function for the background program, and Wims systematically checks all user input for the consistency of parentheses, partly in order to prevent users to escape to the exterior of the function content.
one year, and up to now no successful attempt of security breaking in this respect has been registered.
Bugs or Trojan Horses in user-contributed modules. The system is designed to accept contributed modules. Authors of a contributed module have obviously a much greater freedom to access server resources, than users through the Internet. It seems impossible to eliminate all the possibilities for a contributed module to attack the server. Therefore measures in this direction are principally aimed at limiting eventual damages caused by bugs in modules.
These include:Internet robot accesses. Besides robots used by Internet search engines, many people use robot programs to gather entire contents of a site. The latter raises particular concern, as pages generated by Wims are intended to interactive activities, therefore their addresses contain tags designed to make each of them unique. Thus such a robot program, once launched, is unable to stop by itself. It wastes a lot of the network bandwidth, and the pages gathered in this way are useless.
Our solution to this is to send pages to robots which are different to what is usually generated. Starting pages for each application are presented to robots, because they are necessary for search engine databases. But in these pages, links to answers are suppressed, and if a robot attempts to supply an answer, a special page is sent to indicate an error condition.
For this purpose, the main program wims.cgi includes a small database of known user agents, both ordinary and robot. This solution is only partial, as some particularly ill-behaved robot programs give false agent information to the server.
Depending on the seriousness of the problem, robot control measures may be further strengthened, for example, by allowing only a limited number of robot accesses during a given period, for any given site.
Inter-session infiltration or interference. Nobody should be given access to files of a session not belonging to him. For this reason, temporary files in session directories are not directly accessible by http protocol. This creates a certain inconvenience, as graphics files generated by instex, insplot, insdraw are stored in session directories. These graphics files can therefore be accessed only via wims.cgi, and when the user saves such a file in his local machine, the default filename given by the browser is wims.cgi which does not have a good extension to make it exploitable by other softwares. For the time being, no solution to this problem has been found.
In order to prevent session usurp by a third person, Wims has a mechanism to check IP number of the user, and to compare this IP number with that of the user who created the session. But this mechanism is only partially implemented for registered users, as many connections through Internet providers have dynamic IP numbers which change from request to request.
Mainly due to the above security considerations, Wims is currently only implemented on Linux environment which provides a high level of security protections. There is currently no project of porting it to Windows environment.
Anti-cheating is another aspect of the security consideration. This is important because Wims can be used for on-line examinations.
Globally at the server's level, the prevention of IP number change for registered users mentioned above is one of such measures. Various rules are also implemented in the score registration and accounting mechanism for virtual classes. Besides measures already mentioned in Section 5, we have taken into account the fact that as the exercises are randomly generated, a student may start by repeatedly change the exercise until he finds one which looks easier. When the score is counted, the number of new exercises requested and the number of answers are compared. If the difference exceeds a predetermined tolerance, extra requests for new exercises are counted as failures, which has the effect of lowering the score average. Measures are also taken so that no score is registered when the difficulty level of the exercise is different from that defined by the teacher.
The main anti-cheating measures should be implemented in different exercise modules. Scores should only be given once for each exercise generated, therefore the module must ensure that the user cannot repost an answer to an already scored exercise and get the score again, for example by using the `back' or `reload' buttons of the browser.
Another anti-cheating measure at the modules' level is governed by the principle of the system: efforts are taken to make exercises as random as possible (including random types). In this way, when a student copies from his neighbour, he can only copy the solution to the neighbour's exercise. He must then extract the general method out of the neighbour's solution, and adapt it into his own exercise. The ability to do that is already a good achievement of the teaching goal.