Open Sourcing? Stick with Standard Suffixes
When developing web applications for download by the open community, stick with default suffixes for files containing server processed code, and avoid non-standard suffixes not mapped in a default install.
I posted on the LassoTalk mailing list the other day about avoiding non-standard file suffixes when building applications for others to download. I’m going to revisit that topic here, for readers who might not subscribe to LassoTalk. And, because I know I’ll refer back to this topic in future posts.
Lasso is my web development platform of choice. For those unfamiliar with this platform, it’s roughly similar to PHP but with a much more cohesive language and far fewer security problems. With a default install of the Lasso environment, client requests to the webserver with “.lasso” or “.lassoapp” suffixes are handed off to the Lasso engine for processing — exactly like “.php” for a PHP install. Requests with other suffixes are handled differently depending on the suffix mapping for the given webserver, but most webservers serve unknown suffixes as plain text.
It’s become common, recommended by some, for Lasso developers to use a variety of non-standard suffixes. Among the most frequently seen are “.ctag”, “.ctyp”, and “.inc”. Proponents of this practice do this so they can easily tell from a file’s name what purpose a file has. Some proponents also routinely configure their webserver to not serve these files directly in response to a client request, improving security.
Both of these reasons are well and good. Code should be easy to read, and that extends even to the file names. And, securing libraries that are not intended to be called directly helps keep private information; well, private.
However, there are other ways to accomplish the same things. For example, you could use a standard suffix, while turning the string in question into a prefix. So instead of “header.inc”, you’ll end up with “inc_header.lasso”. This actually will have the added benefit of grouping like-files together. But, if you like the order your file names are in now, “header_inc.lasso” will work just as well.
For restricting access to these same files, an “.htaccess” file, or another mod-rewrite rule, can be used to restrict access to those files. For example, the following works with Apache2 and prevents both access to anything with “_inc” in the filename or path, and any hit to Lasso for such requests.
RewriteRule _inc access_denied.lasso [NC,NS,L]
Of course, the reason you should stick with default suffixes for downloadable web applications is security. If you’re responsible, you must code defensively. This means assuming other layers of your security will be compromised. Like, for instance, an inexperienced admin setting up their environment to serve a non-standard suffix, but not execute that same suffix. This is easy to do, and results in a perfectly working web application where key blocks of raw-code can be viewed at known URLs which are not commonly checked.
If you always use the standard suffixes available in a default install, then no amount of URL-hacking will result in raw-code being served. The worst possible result will be for the code of the included file to be processed out of sequence, and you can code defensively for that as well.
I’m not suggesting that you should never use a non-default suffix. I’ve seen a website, for marketing purposes, use their phone number as a suffix — although I would suggest using mod-rewrite to achieve this trick. But use non-default suffixes only within your proprietary code, where you have complete control of the environment, and only yourself to blame for a mixup.
Feel I’m off base with this? Please leave your thoughts in the comments.