This section treats the security of the "Distance Education over Internet- web questionnaires package. The security issues are divided into these three areas:
An important security issue for the server is clearly to avoid unauthorized access to the server file system. Data in the package that should be protected from unauthorized access, are the following:
The worst case would be that some person with the intention to make as much damage as possible to the system entered as the package administrator or the system administrator.
If someone with bad intentions gets over the user name and password for the administrator of the package, he/she could cause grave damage to the package. What he/she would not be able to do is removing the courses and the information residing below the directory Courses/. Those directories are created by the web (on the server ceibo, but it wouldn't be the same on for example elmer) and they can therefore not be removed or changed without accessing them from a browser. What could be damaged (which is very much) is the rest of the data on the server. The scripts, the web directories, the User directory (with teachers access files and passwords) and the JavaScript directory could be deleted/changed.
Because of the problems described above, it is quite good to have a backup for all the files/directories on another server, preferably this server should also be updated once in a while. The QuestionPages can be recovered using the .data files that resides below Courses/theCourse/PageData/. The damage would, if a backup is used not be too grave. As the students answers would stay stored on the server and the QuestionPages can be regenerated (or taken from the backup).
If anyone got system administrator access for the whole server, he/she could remove/change whatever he/she would like to. In that case the backup would be a greater help than in the case when the intruder only have the package administrator's user name and password.
Most hopefully no one will get over the user name and password of the package administrator nor the system administrator. The risk of that is very low.
Access to the server through scripts
All the scripts residing on the server are public and therefore they can also be accessed by anyone who knows where they are and what they are named. To be able to do any damage it is also necessary to know which the in arguments are. This because all scripts are secured, so that there cannot be any harm done on the server if no in arguments are provided with the script calls. The only right set to public for the script files is the right of execution. The right to read and write are exclusive for the system administrator. As the scripts cannot be read (nor the directory where they resides) there should not be anyone knowing about them, except for the distans.perl scripts, that the QuestionPages calls and which can be viewed in the Location field of the browser (when it is accessed).
As a conclusion, anyone wanting to mess with the server and the courses need to know about the name of the script that will be used as well as the coding of the in arguments for the script. Further he must have information about a name of a course and in most cases data about the students. The last point (the students data) applies to the scripts that register/deletes students and the one that save student answers on the server (distans.perl).
The scripts that can be accessed (through a browser) and potentially inflict damage are:
Probably the script that could do most harm of them all. If anyone finds out about the rmCourse script and knows about the arguments needed, then a whole course could be deleted, with all the answers of the students and the QuestionPages created for the course. This could really be a problem. Actually we did not find out about it until recently (as the program is quite new too). This should be one of the very first improvements to be done to the package. It could easily be done with just adding that the user has to give his/her password if a course is to be deleted. This could then be checked by the script before the course deletion.
distans.perl
This is the script that is most probably to be tried to be violated if anyone is going to try to mess up anything at all. The name of the script can be viewed in the Location field of a browser when giving answer to a QuestionPage which saves the answers on the server. What could happen is that someone answers QuestionPages using other peoples identity. What is actually checked in the distans.perl is that the student is registered to the course and that he/she has not answered the QuestionPage before. If anyone with bad intentions then gives answers to students registered for a QuestionPage (which is the only thing that could be done), then the students affected will not be able to answer that QuestionPage. If this would happen it is not very easy to repair, even though it isn't mortal either. To fix it the administrator for the package will have to enter the answer file for the QuestionPage affected and there remove the answers for the students that were given by the "cracker".
removeCourseAccess.perl
It is possible that someone could find out and violate the access files for the teachers. Anyway, if that happened it would not damage too much, as teacher access files can just be modified for users already existing in the system. The worst that could happen in this case, is that a teacher looses all the accesses to her courses, but that can easily be fixed by the administrator for the package. This should therefore not be a big problem, just annoying.
addCourseAccess.perl
As the password file is not accessible for anyone that does not have server access, no one can create new users. Anyone wishing to get access to a course, for example to change the students data must therefore have access to a registered teachers user name and password. Even if an unauthorized person got over such information, the answer data for students cannot be changed. This is due to that the teachers themselves cannot edit the answer data for students. The data that could be changed is the students registration data, such as the names of the students and the cedula numbers.
If course access is added to a teacher registered on the server, it would not cause any great problem as it could easy be solved and as the teacher most probably would not want to mess up anything for anyone else. Though, it could happen that a teacher finds out that he/she has access to a course he/she does not know about, and therefore thinks that it is due to some error in the applet/server and because of that deletes it.
deleteStudents.perl
Anyone knowing about the name of this script, it's in arguments, the name of a course and a student registered to the course, can remove the student from the course. It could easily be repaired by the administrator of the package as the answer data for a student isn't removed from the server even if the student is dismissed from the course.
registerStudents.perl
Anyone knowing about the name of this script, it's in arguments and the name of a course, can register students to that course. This could be fixed up by the teacher in charge of the course by simply removing the "false" students from the course, using the CreateCourseApplet. It can though be quite annoying.
rmPage.perl
Anyone knowing of a subject and a QuestionPage name could delete a
QuestionPage calling the rmPage.perl script.
First of all, it is supposed that the teachers granted a user name and a password for the possibility to administrate distance courses will not try to damage the system. Still, even a corrupt teacher could only damage the system in a limited manner, as she for example could create an extreme amount of courses or delete the courses that she shares with other teachers. Hopefully this will never cause any problems, as this kind of teachers are quite rarely encountered.
To be able to access the applets used in the package (CreateCourseApplet, MakePageApplet and ReadAnswer) a user name and password is needed. Those user names and passwords are only to be granted for teachers that will give courses over the Internet. If a teacher does not remember it's user name and/or password the administrator of the package can be contacted so that he/she can find it out.
What also falls into the teacher security section is how easy unrecoverable errors are made. This is not an issue in MakePage or ReadAnswer. In CreateCourse, courses can be deleted. If a course is deleted it is not possible to recover the specific data for that course (students answers, students registered and QuestionPages created). This have been dealt with by prompting the teacher, using a dialogue window asking the teacher if he/she really wants to delete the course in case the delete button have been clicked.
All other errors that can be made in the applets are recoverable. Still, some actions that a teacher performs uses dialogue window prompting, this because some errors could be a bit annoying even though they are recoverable.
The students will be granted a unique identification numbers or their cedula numbers to identify themselves. The only time when they the identification of a student is needed is when the student saves answers to QuestionPages on the server.
A problem here could be that if someone knows about a students identification
numbers, that person could give answers to QuestionPages for the student.
As a student is only permitted to answer a QuestionPage once, the "real"
student would not be able to answer the QuestionPages if someone already
had done that. Most probably, no one would like to bother the students
that attends the distance courses. But if they do, they must know about
the identification number of the exposed student. If cedula numbers are
used for identification, the "false answering" could be quite easily done,
as cedula numbers are open to public access. Using computer generated large
numbers instead of cedula numbers, could eliminate some of the risks.
.
An improvement of this could be done, letting every student registered
to a course have a user name password. As the system is built up right
now, either the user name or the password would then have to consist only
of numbers. This would not acquire too much work to implement.