Security considerations
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.
|