[ic] Tips and Tricks: Locking down your system
Thu, 1 Feb 2001 01:32:45 -0500
Tips and Tricks: Locking down your system
Interchange has lots of built-in protections to make developing your
catalogs pretty care-free. But it will definitely pass you the ammo
to shoot yourself in the foot, as will any templating system that has
power. So you have to be careful, as you do in any scripting environment.
Most of the protections have to do with:
* Tags like [cgi foo], [data ...] and such are not reparsed for tags.
(The only non-container tags that are
* The [value foo] tag never allows a left square bracket to be output.
* Safe is used for Perl, which means that arbitrary perl code
which reads/writes or uses IO is not possible.
* The Interchange files don't need to be readable or writable
by any other user ID, so CGI/PHP programs run by the web server
can't get at them.
* Dangerous operations are allowed only via global UserTag,
and not by catalog UserTag.
But there are ways that user-entered data could end up getting
parsed for tags. The most common breach is to take possibly
tainted user data entered into a form and put it in a database
without filtering it first. There are several ways to do
1. For user-entered form fields like name, address, etc
you should always use the [value ...] tag to display
2. You can filter lists of variables automatically with
Filter name textarea_put
Filter address textarea_put
Filter comments textarea_put
Filter email textarea_put
3. You can prevent problems in some cases by using the data tag
(i.e. [data table=foo col=bar key="[item-param something]"])
which is not reparsed for tags as [item-data ....] is.
This is not foolproof unless you control the key in some fashion --
in most cases, you will use [data session username] or something
4. You should never put user-entered data directly in a Scratch
variable, which can be called with mv_click and mv_check.
5. Process all user-entered data before putting it in a
database that could be displayed in a page later. Or process
it before it is displayed.
6. When putting data inside a container tag, the output of which
is reparsed for more tags by default, consider setting reparse=0.
There are other ways to nail down your system and make it more
difficult to have a security problem.
* Use the WRITE_CONTROL database settings.
Database products WRITE_CONTROL 1
It is the default for MV DBM databases (i.e. you have to have a
[flag type=write table=foo] to write) but not for SQL.
The UI does the proper write flagging, so this should have
no effect on it.
AUTHORS NOTE: I should have made WRITE_CONTROL the default for SQL
in MV4, my bad. As long as MV3 compatibility was as poor as it turned
out to be, I should have gone for it.
* Set "NoAbsolute Yes" in interchange.cfg, it prevents [file /some/dir]
or [include /some/rogue/file] from being used. NOTE: This is the
default starting in IC 4.7.x.
* Split the admin server onto a different IC iteration from your
production catalog, and disable the UI for the production
catalog. That allows you to set the pages/ directory to be read-only
for the production server, and to put WRITE_CONTROL in the production
catalog_after.cfg or etc/<catalog id>.after file.
You could also use a different username to access the SQL data,
and make the production server username have read-only access.
You can use a different UID for the admin server iteration,
and make all directories except products/, upload/, tmp/, session/,
and logs/ read-only for the production server UID.
* Make as much stuff read-only as you can. Develop a script which
sets things read-write while you are admin-ing, and read-only
* Always make ICDIR/*.cfg, ICDIR/bin/*, and ICDIR/lib/* read-only for
the IC user.
* Don't let the interchange daemon user ID have read or write permission
on things it doesn't need.
* Never use AllowGlobal in production if you have user-entered data
going into a database. (AllowGlobal is not the default, so many
people won't know what it is -- see Interchange Configuration.)
Things that are in the works for 4.8 to improve security are:
* Better default security settings in the demo.
* Better permissions settings in the UI.
* Optional filtering for tables, with explicit override to
allow [ in certain situations.
* bin/set_permissions script to audit (and optionally fix)
* New global config paramter:
If the IC daemon has write permission on any file that it reads for
global config, or for any executable module, it refuses to use it.
* New [table-editor] tag which allows you to do secure entry
forms without having to worry about every byte.
All in all, Interchange has been proven to be securable over time.
But we all have to do our part and think about what we are doing
with user-entered data.
Red Hat, Inc., 131 Willow Lane, Floor 2, Oxford, OH 45056
phone +1.513.523.7621 fax 7501 <email@example.com>
Experience is what allows you to recognize a mistake the second
time you make it. -- unknown