http://mivo.truxoft.com
MIVO!
miva beyond limits

MIVA^®  SECURITY:  Improving Miva Security

by Ivo Truxa, 09/11/2000 (rewritten 04/17/2001)

1. Miva Scripts and Security
2. Main Security Risks
3. Server Configuration Issues
• directory structure
• file and directory permissions
• Miva binary
• Miva configuration file
• Sitevars file
• Miva Data
• Miva Scripts
• web server configuration


4. Miva Configuration Issues
5. Miva Programming
6. Things To Avoid
7. Resumé - Checklist
8. Links
9. User Comments

Miva is designed to be a secure and simple replacement of other CGI scripting languages like Perl and the target users are web designers with few or no programming experience. While the simplicity of Miva played an important role in the success of Miva and Miva Merchant, there were various security flaws in previous versions of Miva engines and there are still (as for Miva 3.78) certain security risks when installing and using Miva. We can hope that future versions of Miva will set much stricter criteria on the security. As for now, the administrator and the programmer has to make little bit more effort to avoid possible intrusions.

Beyond the correct server configuration, flawless Miva installation and careful programming, the most important task to do is keeping your Miva Engine up-to-date. In the time of writing this article, the current version is 3.78. All previous versions contain serious security flaws. The older version you use, the more and the worse security holes there are. If you are unable to update the engine yourself, ask your ISP to do it for you and explain them that security issues in older Miva engine can allow a hacker to break in not only into your own virtual server but could possibly lead to an intrusion on a server-wide or even network-wide level. If they are not willing to update, change your provider!

top

Security flaws in Miva setup or scripts may be used in various ways. An intruder may be able:

• to access restricted and password protected areas in your web space
• to view program sources, configuration files and documents that are normally not available through a web browser
• to download any files from your Miva data and script directories (including, for example, also databases containing credit card numbers of your customers)
• to edit/modify your data, scripts or other documents
• to redirect your webpages or order forms to another server and collecting your orders
• to create and run new MIVA, Perl, shell and other scripts
• to upload and run binary programs (e.g. Trojans) or any other files to your server
• to setup cronjobs running tasks in background
• to change the Miva configuration (e.g. for accessing other then desired directories)
• to use your server as a gateway for attacks to more important targets
• to use your server as a store for compromising material (porn, warez, pirated MP3, illegal documents) and distributing it from here anonymously
• to use your mail server to send spam or to send e-mail in your name
• to download detailed information about your server, its configuration and filesystem
• to download any world readable file from your server
• with help of other configuration flaws on your server, he may be able to gain root access or even access to other machines on the LAN.
• etc.

Once an experienced intruder finds a hole in your script, he would be able to achieve many of the above-mentioned actions within few seconds, not letting you any chance to block him.

Beyond an oudated Miva engine and an incorrect configuration, macros are the main security risk in Miva scripts. Each unprotected macro represents a potential entrance for an intruder. Using the DEFAULTMACROENCODING directive, introduced in Miva 3.71 is extremely important for your security. It should appear at the top of every your script:

Since a longer time I am trying to bring the Miva Co. to set this behavior as default at least at newly installed Miva engines and offer a new configuration directive for setting the macro encoding server-wide. However, you should be aware that encoding macros is not a universal cure at recent Miva versions - as you can see below, you still have to program quite carefully and you have to add more code for protecting your scripts from possible attacks.

top

In addition of keeping your Miva configuration and applications secure, you should keep your entire server in a healthy and secure shape. If you are running Linux, check the Linux Administrator's Security Guide for tips or search the web for similar sites. Most of the advices are valid for other Unix clones too. Remember that even relatively unimportant security glitch may be critical in combination with a hole in your Miva script or in your configuration.

Replace Telnet by SSH and FTP by sFTP, SCP or other secure equivalents. Secure your mail server.

Basically and officially there are two different ways of installing Miva: standard and secure installation. See the details in the Empresa Installation Manual. Simply told, the standard installation requires a Miva engine in each user's private cgi-bin directory and the secure installation uses a common Miva binary, a common configuration and an authorization file. Additionally there is a third way, undocumented, but very frequent, that is a mixing of both methods. In fact it must be used any time there is a CGI wrapper on the server (like for example suexec) to restrict user's cgi programs. The majority of Internet Host Providers who offer private CGI directories, uses CGI wrappers and therefore you can find this setup quite often: there is a miva binary in each user's cgi-bin directory, but the configuration is kept in the root (/etc/miva.conf). It can be easily turned into the standard installation, with just slight differences to the setup described in the Empresa documentation.

I advice to create several accounts with different owners and not sharing any space or data among them. Split your applications into several parts/groups. Keep any e-commerce applications like Miva Merchant in a seaparate space. Run other non-critical but secure scripts on another virtual server under another user name and put testing and development scripts into a totally isolated space, again under another owner name.

Check regurarly your log files and look for suspicious activities. Write or buy applications that will monitor the log files and alert you or shut down the server when necessary.

As for your server configuration there are several very important aspects:

• Directory structure
• File and directory permissions
• Web server configuration

top

Miva data and script directories must be separated in parallel spaces in no way overlapping each other. While the script directory must be public, the data directory should never be available through the web. Some providers let it in the web space, restricting the access to it in the web server configuration - much better is keeping it totally out of the web space. Ideally, also the private cgi-bin directory should be out of both structures and the execution of cgi programs out of the cgi-bin should be explicitely forbidden in the web server configuration. Ideally, the file structure should look like this:

UserRoot 
  |---mivadata          
  |---public
  |---cgi-bin
  |---config

The user root contains usual account configuration files, and other private documents and folders. The use of 'mivadata' is evident. It should contain subfolders for data of different Miva applications. The 'public' directory contains all publicly available HTML and Miva documents. The 'cgi-bin' directory contains executable CGI scripts (eventually also the Miva engine) and should be out of the public space. The config directory is made for example for the Miva 'sitevars' file, Miva access log files and eventually other documents. These files should be kept out of both, data and script/public directories and it is better to keep the out of the user root as well.

top

In contrary to the Miva Empresa Unix Installation Guide I strongly suggest setting the permissions on the Miva binary, configuration files, data and script directories and files much stricter. Miva Co. recommends setting the miva binary permissions to '4755' in both standard and secure installations. Much securer is setting it to '4100' respectively to '0100' (on wrapped-CGI systems). It should be installed either somewhere in the root, out of user space (secure installation) or in a private cgi-bin directory out of both Miva data and Miva script directories (wrapped systems).

top

Should be placed out of Miva directories - either in the /etc or in the same directory as the miva binary. Set its permissions to '0400' (Read-Only by owner). Do not even allow writing permission to the owner.

top

Should be also out of Miva directories, in a separate parallel directory not accessible by Miva. Set the permissions of the sitevars file to '0400' and the directory to '0500'. You can place the Miva access log files here too. Use the following directives in the miva.conf to set the proper locations:

top

Set permissions of the Miva Data directory and any eventual subdirectories to '0700' and keep permissions of all files at '0600' (Read/Write by owner) or even at '0400' (Read-Only by owner) if you do not need to update them from within a Miva script.

top

Set permissions of all Miva scripts to '0100' (Execute-Only by the owner). It not only reduces the possibilities of hacking them, but it also avoids accidental exposure of your source code (e.g. at corrupted .htaccess or web configuration). Scripts called by MvDO commands have to be set to '0400' on most systems. You only need to set permissions to '0404' if the documents are not to be parsed by Miva (eg. plain HTML or text documents). The Miva script directory and any subdirectories should be set to '0701' (full access for the owner, executable for 'others'). '0101' would be safer, but it would make the maintenance rather unconfortable.

On some systems you may need to use other setting. Experimenting may be necessary to find out the right combination of permissions, but please set always as few permissions as possible.

top

• Set the private cgi-bin directory out of the public directory tree
• Make sure to restrict execution of cgi programs out of the cgi-bin directory
• Disable overriding the cgi execution option in a local configuration file (.htaccess at Apache).
• Disable viewing of confidential and configuration files (e.g. .htaccess, .htgroup, etc)
• Disable displaying directory indexes

In the case of Apache, you would do it in httpd.conf in the following way:

# restricting access to any file beginning with .ht (server-wide)
# you may add other patterns here too
<Files ~ "^\.ht">
 Order allow,deny
 Deny from all
</Files>

# -ExecCGI = no execution of CGI programs out of ScriptAlias dirs
# -Indexes = do not display directory indexes
Options -ExecCGI -Indexes
# do not allow overriding of settings in .htaccess
AllowOverride none

<virtualhost www.example.com>
...
DocumentRoot /home/example/public
ScriptAlias /cgi-bin/ /home/example/cgi-bin/
</virtualhost>

The above example with AllowOverride none restricts the use of .htaccess control files. You may allow overriding of some options, but keep the restriction on Options - consult the Apache documentation for details.

If you plan to use password protected areas that do not require Miva script, I recommend to put them in a separate directory not within the Miva script nor data dir tree. Use the Apache's Alias directive to achieve it.

Check the documentation of your web server and available resources on Internet to straighten its security. Some security tips for Apache are available for example at http://httpd.apache.org/docs/misc/security_tips.html.

top

In addition to the directory and file structure and the permissions as mentioned above, there are some Miva configuration parameters very important for the security of your server. You should never run Miva in mode allowing cgi-bin formed URLs (http://example.com/cgi-bin/miva?script.mv)! You can disable it with the following directive in the Miva configuration file:
redirectonly=yes

The next very important option is defining explicitly document extensions allowed to be parsed by Miva:
validextensions=.mv,.hts

Not respecting these advises my lead to a compromising of your server, revealing of sensitive data or even deeper intrusion into your system. As I already mentioned, keeping your Miva engine up-to-date is also very important.

You should never keep unnecessary Miva scripts on your server. Especially Miva templates that were part of the installation package at earlier versions of Miva contain serious security holes. Also older versions of Merchant contain some vulnerable code. Using scripts of third-party programmers without verifying them for possible security flaws may be very dangerous. Miva scripts are especially dangerous then, when their source is publicly available - when a malicious hacker finds a security hole in such script, he can easily scan domains for presence of that script and break in. If you keep such scripts, do not intall them in default locations and change file names, at least. For the same reasons, try to limit publishing your code or posting it to discussion forums. If you have to do it, change at least variable names and other details.

top

This part, will be covered in another article. Work in progress.

The most usual security flaw in scripts I can see all around is improper use of macros. Not only that people often use macros without any necessity but they even do not bother to protect them from a possible and very easy abuse. Using DEFAULTMACROENCODING and :entities or :attribute options is a very important means (though not universal one) to improve the security of your scripts. Replacing macros with MvEVAL or with expressions anytime it is possible, is a very good idea.
For example:
<MvSMTP FROM="{g.email}"... instead of
<MvSMTP FROM="&[email]"...

DEAULTMACROENCODING="entities" has the same effect as encodeentities() or &[macro:entities];. Executing Miva code from macros is necessary relatively rarely and in such case you can do it even with an active DEAULTMACROENCODING="entities" in the following way:
&[macro:none];

All this is not to protect you from mistakes in your own code, but from injecting and executing Miva code into your application by a hacker. An intruder could easily achieve most of that what I mention at the top of this article through a macro with an unitialized or an unchecked variable. If the script is not perfectly secured, the code may be injected through forms, URL, HTTP variables, some system variables, etc. There are many tricks how to get the code executed. Some of them are quite sophisticated, but not too difficult to perform once you know them.

This issue is very lightly and not quite correctly covered in the section Security issues with macros of the Miva Script Reference Manual. I'll bring more information later.

top

A list of the most dangerous but in the same time the most common programming faults:

• mivadata accessible from the web
• unitialized variables
• unprotected macros
• executing a macro
• variables without a scope prefix
• storing confidential data unencrypted
• sending confidential data by e-mail (MvSMTP)
• non-secure forms for confidential data (plain HTTP instead of SSL)

top

NOTE: This list is far to be complete. I'll be adding other items continuously.

• Secure the OS and check overall server setup
• Use SSH/sFTP instead of Telnet/FTP. Secure the POP3 login.
• Remove unused daemons (in /etc/inetd.conf on Linux) - nntp, uucp, pop2, imap, telnet, ftp, finger, netstat,...
• Use a secure directory structure
• Set the strictest possible file and directory permissions
• Secure the web server configuration
• Disable CGI outside of cgi-bin folders and disable overriding the option
• Split your applications into several separate accounts
• Analyze log files
• Install intrusion detection software
• Check regularly content of your folders. Remove unknown or unused files and correct all permissions.

• Keep the Miva engine up-to-date
• redirectonly=yes (no cgi-bin-url Miva calls!)
• validextensions=.mv
• Use a secure directory structure, file locations and permissions
• Allow symbolic links only if necessary (securityoption=0)
• Remove all unused Miva scripts (Perl, PHP and other cgi applications as well)
• Rename third-party script file names and move them to non-default directories. Check them for security flaws, fix them and report to the author. Consider global renaming of variables and function names.

• Put <MIVA DEFAULTMACROENCODING="entities"> at the top of each Miva file
• Use <MvEVAL EXPR="{g.variable}"> or <MvSOMETAG ATTRIB="{g.variable}"... instead of macros (&[variable]; or ...ATTRIB="&[variable];"...)
• Use :entities and :attribute macro options
• Be aware of JavaScript tricks. Javascript may be injected into your pages even if you do not use any macros.
• Verify any possible user input (forms, URL, http variables)
• Initialize all variables
• Use allways variable scope prefixes
• Use preferably local variables than global ones
• Encrypt confidential or sensitive data
• Do not use plain MvSMTP for sending sensitive data. Use MvPGP instead.
• Do not keep confidential data (e.g. POP3 passwords for MvPOP) directly in the Miva script directory nor in the data dir. Either ask the user to submit them through a secure form (SSL), store them encrypted, or store them at least in the sitevars file (out of Miva data/script dirs)
• Use SSL forms for submitting sensitive user data
• Do not publish your real source code

top

top

Miva and some other terms used on this page are registerd trademarks of the Miva Corporation
copyright  truXoft  © 1997-2012