One of the most important tasks for a Challenger administrator is to maintain security. A web server is reachable by any user on the internet, some which might harbor ill intent. The whole server, including all user or third-party scripts, must be made secure. It is necessary to have an understanding of the issues involved.

One fundamental task is to decide who to trust, and to what extent. Do you trust that the programmer of a third-party script has taken security considerations into account when making the script? Do you trust your users not to abuse the <pike> tag?

It is also important to watch your log files. Problems, such as attempted break-ins, will often show up in the log files. You should watch the access logs as well as the debug or event log.

An important task is to educate your users and programmers about security. You are the one who has a vested interest in security, users and programmers will often see it as a nuisance, unless they are taught about its importance.

Trusting code
The easy sharing of code via the web is both a blessing and a curse. It makes it simple to get the functions you want. On the other hand, it makes it easy to compromise your security. You leave the security of your server in the hands of the programmer who has made scripts you install, so you better make sure that it is a programmer who takes the security issues seriously.

You should always check who has written a script and who maintains it. You should make sure that the programmer and maintainer describes the security issues in a serious way in the documentation of the script.

User input
The main problem when programming on the Web is handling user input. Unlike a normal application, a web application cannot limit what may be sent as user input. It must be able to handle anything, be it megabytes of machine code in a field meant for a single word.

There are two problems associated with user input, buffer overruns and special characters. Buffer overruns in a problem that can occur when writing scripts in compiled languages like C or C++. In such languages, it is tempting to make fix-length buffers. The problem is that an attacker can execute machine code by sending more input than the length of the buffers.

Special characters are a problem for any script that in itself runs external programs or connects to databases. Some characters have special meaning for the command interpreter or the SQL interpreter. The programmer must therefore make sure to quote any occurrence of such characters.

When using RXML together with dangerous tags, like the <pike> tag, it is very important to quote <, > and &. If any output tags are used, like <formoutput> or <sqloutput> it becomes necessary to quote : as well.

Pike scripts or modules
Challenger's built-in scripting capabilities use Pike, which makes it impossible to create buffer overrun bugs. There is simply no way to execute machine code from Pike. Pike also contains safe methods for starting external programs, as well as methods for quoting dangerous characters when connecting to databases.

When using RXML to connect to databases, dangerous characters must also be quoted. This is done by default. For more information about RXML quoting see the formoutput page in the Web site Creator manual.

Trusting users
We can distinguish between three different categories of users. How much you trust a user will depend on which category she belongs to.

External users

People looking at your web site.

Internal users

People that can create and maintain web pages.

Administrators

People who have access to Challenger's configuration interface.

External users are usually not trusted at all. Most of your work is to ensure that external users cannot break the security of the web server. There are several different access control schemes available that can be used to limit access to certain pages for certain networks or users.

Internal users are trusted to a degree. How much depends on your organization. For example, if you are administrator for a school or ISP, you will probably not trust internal users very much. If, on the other hand, the internal users are colleagues you meet daily, you will probably trust them to a higher degree. It is possible to use trust levels to give different internal users access to different modules.

Administrators have access to the whole web server. The question is whether they also have access to the machine the web server runs on. This determines which user to run the server as.

Trustlevels
Trustlevels is a builtin permission system that can be used to give access to different modules for different internal users. That way, you can limit access to potentially dangerous modules to trusted users.