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.
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.
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.
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 registere d 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 neighbor, he can only copy the solution to the neighbor's exercise. He must then extract the general method out of the neighbor's solution, and adapt it into his own exercise. The ability to do that is already a good achievement of the teaching goal.