This warning technically doesn’t affect or hurt anything but of course after paying for the SSL cert and going through the trouble of installing it, we all want our users to see the green lock icon and not a yellow warning icon!  If you’re running Apache2 the reason for this is that Chrome prefers to use TLS encryption but had to fall back to SSL encryption.  Apache2 supports TLS out of the box but may not be enabled by default.

To enable TLS, open your apache configuration file and add the two lines below:  (The config file is where you previously configured SSLCertificateFile and SSLCertificateKeyFile.  It’s possibly located in /etc/apache2/sites-enabled)

SSLProtocol -all +TLSv1 +SSLv3
SSLCipherSuite HIGH:MEDIUM:!aNULL:+SHA1:+MD5:+HIGH:+MEDIUM

What these lines do is specify that both TLS version 1 and SSL version 3 are supported.  Once you’ve added these lines you need to restart Apache (/etc/init.d/apache2 restart).

If you refresh your browser at this point it’s likely that the warning icon is still there.   Shutting down and re-starting your browser should resolve it.  I suspect that the browser negotiates an SSL connection once and continues to use it until the session expires or the browser is restarted.

First you need to have a server that is running VNC, but most likely only has it’s SSH port exposed. I’ll assume that SSH is on port 22 and VNC is on port 5900 (these are the default ports for these services). I’ll also assume that you have the ssh command and a VNC client installed on your client machine.

1. On your client machine, open a command line window and enter the following to create the SSH tunnel:

ssh -N -p 22 USERNAME@YOURSERVER -L 5901/localhost/5900

Replace USERNAME with your server username, and replace YOURSERVER with your server address (ie verysimple.com or 192.168.1.99)

2. Once you enter this command you’ll be prompted for the server password. Enter the password. You will see no feedback in the terminal window, but the SSH tunnel is now active.

3. Open your VNC client and connect to the address “localhost:5901″ If you have a password set for VNC access then you will need to enter that now. If all goes well, you should see your server VNC desktop!

It might seem weird that you are connecting to localhost in your VNC client. But the the SSH tunnel you created is actually routing port 5901 on your localhost to port 5900 on your server.

Solution 1: Create a symbolic link

Open terminal and do the following:

sudo su
mkdir /var/mysql
ln -s /tmp/mysql.sock /var/mysql/mysql.sock

You just created a symbolic link in the place where PHP expects the socket file to be located so it should be happy.

Solution 2: Edit php.ini

If you don’t like the idea of creating a symbolic link, you can also simply alter your php.ini file to point PHP to the real location of mysql.sock.

Locate /etc/php.ini. (If php.ini doesn’t exist on your system, copy /etc/php.ini.default to /etc/php.ini).  You will likely have to do this from the terminal unless you have Finder configured to show hidden files.  Open the file and update the setting mysql.default_socket so it looks like this:

mysql.default_socket = /tmp/mysql.sock

To commit the change you need to restart Apache.  You can do that in System Settings -> Sharing, then  uncheck, then recheck Web Sharing.

The TextInput can be bound as well so that when the dataSource changes, the value of the TextInput will automatically update. However, unlike the DataGrid, changing the text of the TextInput will not automatically update the dataSource. Take the following code for example (assuming “source” is a String variable):

<mx:TextInput id="text1" text="{source}" change="{source= text1.text}" />

When the TextInput is changed, the value of source remains the same. It’s only bound one-way. If you want the value of source to be updated when TextInput changes, it’s actually easy, but there are at least five (5) different ways to do it of which I know. For the most straight-forward two-way binding, you could update the TextInput code like so:

Technically source is not bound to the TextInput, but it does produce the desired result. source is updated manually whenever the valueCommit event fires. The valueCommit event fires when the TextInput text has been changed onBlur (ie when when TextInput loses focus). If you prefer source to be updated on every key stroke, you can change valueCommit to change instead and the update will occur on every keyUp. If I’m updating a database or making a service call, I prefer valueCommit so the back-end code only fires once after the user is finished updating the field. If the TextInput is an ajax-style auto complete or lookup, the change event might be more desirable so the application can react after each key stroke.

As I mentioned there are five methods to do this. You can bind controls using Flex’s binding features in either MX code or ActionScript. Depending on your application one may be better than the rest as far as keeping your code clean and consistent. For the most part they all achieve the same result. Below is source code that demonstrates all five techniques:

<?xml version="1.0" encoding="utf-8"?>
<mx:WindowedApplication xmlns:mx="http://www.adobe.com/2006/mxml" layout="vertical" creationComplete="{init()}">
	<mx:Script>
		<![CDATA[
			import mx.binding.utils.BindingUtils;
			import mx.binding.utils.ChangeWatcher;
 
			/**
			 * Called at creation complete and initializes all of the examples
			 */
			private function init():void
			{
				this.initExample2();
				this.initExample3();
				this.initExample4();
				this.initExample5();
			}
 
			/**
			 * Example 1: simple inline binding (see the MXML)
			 * -----------------------------------------------------------------------
			 */
 
			[Bindable]
			private var value1:String = "example 1";
 
			/**
			 * Example 2: use ChangeWatcher to assign a change watcher to text2.text
			 * -----------------------------------------------------------------------
			 */
 
			[Bindable]
			public var value2:String = "example 2";
 
			private var watcher2:ChangeWatcher;
 
			public function initExample2():void
			{
				watcher2 = ChangeWatcher.watch(text2,"text",text2changed);
			}
 
			/**
			 * notice that the argument is an event
			 */
			public function text2changed(event:Event):void
			{
				this.value2 = (event.currentTarget as TextInput).text;
			}
 
			/**
			 * Example 3: use BindingUtils to bind a change watcher to the text3.text setter
			 * -----------------------------------------------------------------------
			 */
 
			[Bindable]
			private var value3:String = "example 3";
 
			private var watcher3:ChangeWatcher;
 
			public function initExample3():void
			{
				watcher3 = BindingUtils.bindSetter(text3changed,text3,"text");
			}
 
			/**
			 * notice that the function argument is a string (the value of text3.text)
			 */
			public function text3changed(val:String):void
			{
				this.value3 = val;
			}
 
			/**
			 * Example 4: Use BindingUtils to bind text4.text to this.value4 (notice value4 has to be public)
			 * -----------------------------------------------------------------------
			 */
 
			[Bindable]
			public var value4:String = "example 4";
 
			private var watcher4:ChangeWatcher;
 
			public function initExample4():void
			{
				watcher4 = BindingUtils.bindProperty(this, "value4", text4, "text");
			}
 
			/**
			 * Example 5: using MX:Binding in the MXML (see below)
			 * -----------------------------------------------------------------------
			 */
 
			[Bindable]
			private var value5:String = "example 5";
 
			public function initExample5():void
			{
				text5.text = this.value5;
			}
 
		]]>
	</mx:Script>
 
	<mx:HBox>
		<mx:TextInput id="text1" text="{this.value1}" change="{this.value1 = text1.text}" />
		<mx:Label id="label1" text="{this.value1}" />
	</mx:HBox>
 
	<mx:HBox>
		<mx:TextInput id="text2" text="{this.value2}" />
		<mx:Label id="label2" text="{this.value2}" />
	</mx:HBox>
 
	<mx:HBox>
		<mx:TextInput id="text3" text="{this.value3}" />
		<mx:Label id="label3" text="{this.value3}" />
	</mx:HBox>
 
	<mx:HBox>
		<mx:TextInput id="text4" text="{this.value4}" />
		<mx:Label id="label4" text="{this.value4}" />
	</mx:HBox>
 
	<mx:HBox>
		<mx:TextInput id="text5" />
		<mx:Label id="label5" text="{this.value5}" />
	</mx:HBox>
 
	<!-- Configure the binding here in MXML -->
	<mx:Binding source="text5.text" destination="this.value5" />
 
</mx:WindowedApplication>

If you know of any other ways to bind data to UI Controls, please post a comment.

One simple way to achieve this is to write your automation functions as a regular web-based page within the app and then use wget to post a web request to that URL. You can use cron to schedule the frequency.

wget is fairly simple to use, however one thing that is difficult to find in the documentation is how to get the contents of the document and append them to a file. The normal behavior is to just download the file and save it with it’s original name. You can remedy this by specifying a dash “-” as the output filename, which tells wget to output the document to the console. the –quiet parameter tells wget not to output a bunch of connection info. Finally, we redirect the console output to append to a file using >> at the end. The resulting statement looks something like this:

wget --quiet --output-document=- http://localhost/auto.php?arg=123 >> /path/to/file.log

Depending on your server configuration you may need to put quotes around your URL as well, like so:

wget --quiet --output-document=- "http://localhost/auto.php?arg=123" >> /path/to/file.log

If you are attempting to connect to a secure URL (beginning with “https”), you may also need to add the “–no-check-certificate” option to the command in which case your command would like like so:

wget --quiet --no-check-certificate --output-document=- "https://localhost/auto.php?arg=123" >> /path/to/file.log

If you have your automation script output debug information, then your log file will contain useful information. As an example, I like to output the date and time that the script runs and then any info about failures that may have occurred.

One note about security – if you don’t want people poking around and firing off your automation and/or viewing your debug information, you should implement some type of security, such as a simple username/password arguments or something more robust if required.

Note, when I specify something in brackets like so: [filename] that is to indicate that you type in a filename or whatever. Do not include the brackets in your command.

Navigating UNIX:

• / (refers to the root directory on the server)
• ./ (the current directory that you are in)
• ../ (parent directory of your current directory)
• pwd (shows what you current directory is – giving the full path)
• ls (lists all the files in your current directory)
• ls -al (lists filenames + information)
• ls -alR (lists filenames + information in all subdirectories)
• ls -alR | more (lists filenames + information in all subdirectories,
• pausing when the screen become full)
• ls -alR > result.txt (lists filenames + information in all subdirectories,
• and ouputs the results to a file instead of the screen)
• ls *.html (lists all files ending with .html)
• ls -al /home/usr/bob/ (lists files + info for /home/usr/bob)
• cd (changes you to a new directory)
• cd images
• cd / (changes you to the root directory)
• cd /home/usr/images
• cd .. (this goes back one directory)

Moving, Copying and Deleting Files:

• mv [old name] [new name] (move/rename a file)
• cp [filename] [new filename] (copy a file)
• rm [filename] (delete a file)
• rm * (delete all files in your current directory)
• rm *.html (delete all files ending in .html in your current directory)

Creating, Moving, Copying and Deleting Directories:

• mkdir [directoryname] (creates a new directory)
• ls -d */ (lists all directories within current directory)
• cp -r [directoryname] [new directoryname] (copy a directory and all
• files/directories in it)
• rmdir [directoryname] (remove a directory if it is empty)
• rm -r [directoryname] (remove a directory and all files in it)

Searching Files and Directories

• find / -name [filename] -print (search the whole server for a file)
• find . -name [filename] -print (search for a file starting with the current directory)
• find / -name [directoryname] – type d -print (search the whole server for a direcory)
• grep [text] [filename] (search for text within a file)
• sed s/[oldtext]/[newtext]/g [filename] (searches file and replaces all occurances of [oldtext] with [newtext]

Viewing and Editing Files:

• tail [filename] – view the tail end of a file, useful for checking the error log when debugging a script
• vi [filename] – opens a file using the vi text editor. you are a true geek if you use vi, however it’s fairly easy to use. (refer to the vi primer in this support forum)

Installing Software & Scripts

For downloaded ‘tar’ scripts, to un-tar and un-gz

• tar -xvf [archive.tar] – extracts files from the tar archive ‘archive.tar’
• tar -zxvf [archive.tar.gz] extracts files from the tar archive ‘archive.tar.gz’

Getting Server Information

• which (displays path to an executable, ex which perl, which php)
• whoami – displays your current username
• uptime – displays how long the server has been up and some performance statistics

Viewing disk space

• du (to view disk usage on server)
• quota (to view your disk usage on server)

Viewing and Stopping Processes

• ps – displays running processes
• top – (may be only available to admins) similar to windows task manager
• kill -9 [process Id] – terminiates a running process (out of control CGI, etc). The process Id can be obtained using “ps”

File and Directory Permissions

There are three levels of file permission: read, write and execute. In addition, there are three groups to which you can assign permission, The file owner, the user group, and everyone. The command chmod followed by three numbers is used to change permissons. The first number is the permission for the owner, the second for the group and the third for everyone. Here are how the levels of permission translate:

• 0 = — (no permission)
• 1 = –x (execute only)
• 2 = -w- (write only)
• 3 = -wx (write and execute)
• 4 = r– (read only)
• 5 = r-x (read and execute)
• 6 = rw- (read and write)
• 7 = rwx (read, write and execute)

I prefer that the group always have permission of 0. This prevents other users on the server from browsing files via Telnet and FTP. Here are the most common file permissions used:

• chmod 604 [filename] (minimum permission for www HTML file)
• chmod 705 [directoryname] (minimum permission for www directories)
• chmod 705 [filename] (minimum permission for www scripts & programs)
• chmod 606 [filename] (permission for datafiles used by www scripts)
• chmod 703 [directoryname] (write-only permission for public FTP uploading)

Note that some systems use AFS filesystem and chmod does not behave as expected.You can sometimes identify AFS if the path that you are using begins like so /afs/path/to/files/ If your system uses AFS, then the following commands are used instead of chmod.

• fs setacl [directory] [group] [access] (set file permissions)
• fs listacl [directory] (list file permissions)

example:

fs setacl . httpd rliw (set read, lookup, insert, write to http for current dir)

Scheduling Tasks

You can schedule tasks to run automatically by using the UNIX cron command. To use this, you create a text file with cron instructions, then process this file. cron instructions are basically UNIX commands with extra info about the time that they will run.

One important thing to note is that it is best to use full paths when creating your cron file. As an example, create a file called mycronfile and in it place one line:

0 1 * * * cp /usr/www/file.txt /usr/www/backup.txt

now at the command line, type the following:

crontab mycronfile

You have just scheduled an automated task! This task will run at the time specified until you decide you want to cancel it.
There are six fields in this file. The first five represent the time that the job will run. The sixth field is a UNIX command that will run at the specified time. The above example will run every night at 1AM, at which time it will copy a file.

Here is how the fields break down:

Field 1 | Field 2 | Field 3 | Field 4 | Field 5
Minutes | Hours | Day of Month | Month | Day of Week
(0-59) | (0-23) | (1-31) | (1-12) | (0-6)

You can enter a number in the field, a range of numbers, or an * to indicate all. Here are a few more examples. These examples use the ls command, which would be pretty useless. Note the time that it runs, though.

• 0 1 * * 1-5 ls (this would run every Monday-Friday at 1am)
• 0 1 * * 1,3,5 ls (this would run every Monday, Wednesday and Friday at 1am)
• 10 2 1 * * ls (this would run at 2:10am on the first of every month)
• 0 1 1 1 * ls (this would run at 1am on January 1 every year)

If you have a more complicated command that you want to run, it is sometimes helpful to create a shell script and have that script run. You specify the shell script as you would any UNIX command. For example:

• 0 1 * * * /usr/www/myscript

There are some other crontab switches that are useful:

• crontab -l (lists your currently scheduled tasks)
• crontab -r (delete all currently scheduled tasks)
• crontab -e (directly edit your scheduled tasks)

Credits

• Originally created by Jason Hinkle
• Additional content provided by Dave Wojo

To keep things simple, let’s make the following assumptions:

a. pages should be readable/writable by the owner and readable by the web visitor.
b. scripts should be readable/writable/executable by the owner and readable/executable by the web visitor.
c. data-config files should be readable/writable by the owner and readable/writable by the web visitor.
And also, lets use the following abbreviations:

- – - (or 0) = no permission
r – - (or 4) = read-only permission
rw – (or 6) = read/write permission
rwx (or 7) = read/write/execute permission

To change UNIX file permissions using your shell account (Telnet):

When changing file permissions on a UNIX server, there are three groups to which you assign permissions: owner, group, other. Owner is typically you. Group is typically all users with accounts on your server. Other is typically the web visitors. Using the chmod command on a UNIX server, you can set the permissions for each of those groups.

1. Log into your account and go to the directory where the files are located
2. Use the chmod command to change permissions like so:
2a. chmod 604 page.html
2b. chmod 705 script.cgi
2c. chmod 606 config-data.txt

To change UNIX file permissions using your FTP software:

1. Log into your account and go to the directory where the files are located.
2. Highlight the file that you want to change permission.
3. Locate the “file permission” or “chmod” command on your FTP software software (you may need to refer to the manual or help file)
4. There should be three groups. Each group should have either checkboxes or a selection for the permission type.
4a. set pages to rw- for the owner, no permission for the group, and r–for other
4b. set scripts to rwx for the owner, no permission for the group, and r-x for other
4c. set data/config files to rw- for the owner, no permission for the group, and rw- for other

Before you begin: In order to install modules, you have to have SSH or Telnet access to the server. If you don’t have this access (or you don’t know what SSH/Telnet means) then you’ll probably have to get your system administrator to install modules for you.

I recently wanted to install the DBD::CSV module on my virtual host server (UNIX FreeBSD) and found that it was more challenging than I would have liked. I’m not positive I have the best approach, but it did work for me in the end. Following are the steps that I had to take to get the module and all those on which it depends installed. The primary problem is that on the virtual server, I don’t have root/administrator privledges. So, I have to install Perl modules in an alternate directory. The scripts have to be altered to point to that directory as well.

To install my beloved DBD::CSV, I notice that I also have to have all of the following modules installed and working:

DBI
File::Spec
Text::CSV_XS
SQL::Statement

So, we will install those first, then finally install DBD::CSV.

First, I set up MCPAN. This is a Perl utility that automatically downloads, unpacks, compiles and installs Perl modules. Since I don’t have root, I was only able to utilize MCPAN for the downloading and upacking part. I still had to compile and install the modules manually. If you don’t have access to, or don’t want to bother with MCPAN, then you can just download the modules directly from http://www.cpan.org and unpack them yourself.

To run MCPAN, you enter something like this (this will start the process of installing DBI, the first required module):

perl -MCPAN -e 'install DBI'

The first time I ran this utility, I was automatically taken through an installation process. A directory ~/.cpan was created in my home directory and I was prompted with several questions. I simply used all the defaults. There was only one question that I had trouble with, which was something like “What is your favorite CPAN mirror.” This seemed to be asking where to look for downloadable modules. I wish I remembered what I put, but it took me several tries to find one that worked. I finally wound up entering a server in Japan, which I’m sure is not good. But it worked. You might check for possible server locations here: http://www.perl.com/CPAN

Anyway, after running that the first time, the DBI module installation files were saved in ~/.cpan/build/DBI-1.14. (in case you don’t know ~/ usually means your home directory), however the installation failed because it tried to write some stuff to the main Perl installation location and, again, I don’t have permission to write there. however, when you are manually installing modules, I do know that you can specify an alternate directory. So, I went into the ~/.cpan/build/DBI-1.14 directory and manually installed it like so:

cd ~/.cpan/build/DBI-1.14
perl Makefile.PL INSTALLDIRS=site INSTALLSITELIB=/usr/www/users/myaccount/cgi-bin/lib
make
make test
make install

When I installed it, I see that I got a few errors and such. Upon closer inspection, it seems that the POD documentation and other stuff is still trying to go in the main Perl library location. I ignore these errors, since it doesn’t seem to effect anything but the documentation. Obviously, you want to replace /usr/www/users/myaccount/cgi-bin/lib with the location on your server where you want to save the modules.

Anyway, now I try the File::Spec module:

perl -MCPAN -e 'install File::Spec'
cd ~/.cpan/build/File-Spec-0.82
perl Makefile.PL INSTALLDIRS=site INSTALLSITELIB=/usr/www/users/myaccount/cgi-bin/lib
make
make test
make install

That one was easy. I still got errors, but I just ignore them. Now I try Text::CSV_XS:

perl -MCPAN -e 'install Text::CSV_XS'
cd ~/.cpan/build/Text-CSV_XS-0.21
perl Makefile.PL INSTALLDIRS=site INSTALLSITELIB=/usr/www/users/myaccount/cgi-bin/lib
make
make test
make install

Same old thing. More errors. Moving along to SQL::Statement…

perl -MCPAN -e 'install SQL::Statement'
cd ~/.cpan/build/SQL-Statement-0.1016
perl Makefile.PL INSTALLDIRS=site INSTALLSITELIB=/usr/www/users/myaccount/cgi-bin/lib
make
make test
make install

Another one bites the dust. The final one, DBD::CSV is more tricky because when I tried the same thing, it doesn’t work. I can’t do the Makefile.PL part of it because it says I am missing some required modules. What is happening is that the installer is looking in the standard Perl path – however we have been installing all of our goodies to an alternate location and Perl doesn’t know about it. My solution is that I simply comment out the lines in Makefile.PL where it checks for all the required modules! That’s a crappy way to do it, but it works.

perl -MCPAN -e 'install DBD::CSV'
cd ~/.cpan/build/DBD-CSV-0.1024

Now I edit Makefile.PL and comment out these lines (about 20 lines down from the top or so)

# $ok &&= CheckModule('DBI', '1.00');
# $ok &&= CheckModule('Text::CSV_XS', '0.16');
# $ok &&= CheckModule('SQL::Statement', '0.1011');

That’s it. the rest is the same.

perl Makefile.PL INSTALLDIRS=site INSTALLSITELIB=/usr/www/users/myaccount/cgi-bin/lib
make
make test
make install

All done at last! I tried my script and it worked just fine. One adjustment that you might have to make to your script is to add the location of your libraries to your script. You do this by putting the location in a BEGIN clause in your script like so:

BEGIN {
unshift(@INC,"/usr/www/users/myaccount/cgi-bin/lib");
}

Put this at the top of your script before any other subroutines or anything. That tells your script to look there when loading modules. Since you use the “unshift” function, your path is added to the front of the list. If you would rather your script look in the regular places first, and look in your custom path last, then you can use “push” instead of “unshift.”

One final thing. I went into ~/.cpan/build/ and deleted all the files and folders. I get charged for disk space overusage, so no use keeping all those installation files, right?

Starting vi:

vi [filename] – opens a file using the vi text editor. if this is an existing file, it will edit. otherwise, it will create a new, blank file.

Panic Button!

:q! then hit the enter key= exit without saving. useful when things go out of control!

Switching “modes”

the first confusing part is that vi has different “modes” while you are editing a file. They are known as “command” mode and “input” mode.

Esc – takes you back to command mode.

i, a, A, r or R – (while in command mode) goes into insert mode.

Moving Around:

Moving around the file is done in command mode. if your terminal is set up correctly, the up,down,left,right arrows will nmove the cursor around.

if your terminal is not set up correctly, then you have to use j=down, k=up, h=left, l=right.

/[search term] then hit enter = the slash followed by a search term will move the cursor to the next occurance of that term. handy for locating configuration settings.

?[search term] then hit enter = same as search, but searches backwards.

ctrl+shift+R = screen refresh. especially when scrolling, vi has a tendency not to redraw the whole screen correctly. use this to refresh the screen.

Deleting

Deleting is again done from command mode. This is probably the most confusing part of vi for me personally. because input mode allows you to enter new characters. but to delete existing ones, you must exit back to command mode and delete them.

x = delete current character
dd = delete entire current line
u = undo last edit

Inserting / Editing

i = enter insert mode starting before current char
a = goto insert mode starting after current character
A = goto insert mode at end of current line.
r = overwrites next character typed then exits back to command mode
R = goto insert mode, but overwriting instead of inserting

when you enter insert mode, you just start typing as you would with any editor. it’s pretty simple. When you’re done typing, or you want to move the cursor to make a correction, hit Esc to return to command mode.

Exiting vi with and without saving

(This is all done in command mode)

:q! then hit enter = exit without saving

shift+ZZ then hit enter = save and exit.

Getting Help

:viusage = shows vi commands
:h = general help screen

I find a lot of surprising security problems as I work on client’s sites. Even large, reputable companies often have gross security issues. I know more than anyone how difficult it can be to get a cgi script installed and working. It’s tempting to walk away without double-checking the security. One of the most common things that I see is poor security of the cgi-bin. Depending on the setup of your server, someone can take total control of your account easily through a poorly secured cgi-bin.

The particular problem i’m writing about involves writable files/directories within your cgi-bin, or scripts that make calls to external programs (like sendmail). These are both very common types of scripts that you would find in just about any cgi-bin.

The writable file issue is that most cgi scripts rely on a datafile to store their information. In some cases, they need an entire writable directory to store data (file uploads, etc). The tricky part is that you have to allow the script write access to the file/directory. If your server is running as “nobody” then you need to allow world write access to the file. This is dangerous because other users on the server also have the ability to run under the “nobody” user – which means they can also write to those files. Some servers are configured so that scripts execute under your own userid. Otherwise sensible people are fooled into thinking that they are protected by this. Although it does protect you from the “nobody” exploits, it actually make the potential damage much worse if you have poor security settings.

The issue with scripts that make calls to external programs (like Formail for sending email via sendmail, etc) is that if they are not coded properly, someone can input malicious text that causes an arbitrary shell command to run in addition to the sendmail command. This command will run under whatever userid that the original script has.

One dangerous situation is a script that allows file uploads and it’s writable directory is in the cgi-bin. Any script like this should have serious security checks in place to prevent malicious files from being uploaded. If the script doesn’t check file types as they upload, any anonymous user can upload a script or executable file right to your cgi-bin.

Another situation is on a virtual host where you share your account with lots of other users. This exploit is only available to people who have an account on your machine, however it is no less a problem. All users on your server can install cgi scripts in their account which run under the “nobody” permissions. If they install a simple command processing script, they can manipulate any file in your account that allows world write access.

So, take a look at your cgi-bin and look for any writable files or directories. Imagine what would happen if someone could edit or add any file there in your cgi-bin. A writable directory is particularly bad because the other person on your server can actually write a new script file there and then browse to the url to execute it.

Normally if someone can totally compromise your site in this way, they are limited to running as the user “nobody.” However, there is still quite a bit of damage that can be done. Formmail scripts can be installed to send spam. Scripts to snoop into your datafiles can be installed. Large files can be uploaded and shared (using your bandwith). I once had a client who incurred a $10,000 bandwidth bill after their server was compromised by hackers sharing video game software. Nothing more than “nobody” access is needed to do this.

If cgi-wrap is enabled, the situation is compounded because the scripts in your cgi-bin can be executed through cgi-wrap to run under your own userid. At that point, they own your account.

How To Secure cgi-bin:

There’s a few simple things that can help lock down your cgi-bin.

1. Never, ever have a file with both world-execute and world-write permissions. This can be overwritten with any arbritrary code by any user on your server. Once they overwrite, they can execute it through the browser. Scripts themselves should never require write permission. Read/Execute is fine (chmod 505 is nice and secure).

2. If possible, never have any writable directories or files in the cgi-bin. Not even writable by your own user id. there is no reason that a file needs to be writable within the cgi-bin. Depending on what scripts you have installed, this can be challenging. The solution is to move all datafiles to an area that is not accessible through the web browser. If this is not possible, see # 3

3. If you must have writable files or folders in the cgi-bin because of the functionality of a script, keep them in a subdirectory and put an .htaccess file in there that has the contents “deny from all” in it. Your scripts can still read/write files there, but nothing can be executed through the browser. if you are not able to put them in a separate directory, you can deny access to specific files using .htaccess.

4. Never give any permissions to the “group.” In UNIX you have three permissions to grant – owner, group, world. for example, chmod 644 grants 6 (rw) to owner, 4 (r) to group and 4 (r) to the world. The group is almost always other accounts on your server. You generally do not know these other users and there is no reason to give them any permissions for any file in your account. The middle value should always be zero. for example: chmod 604 gives the group 0 (no access) which is fine.

5. be very careful when cgi-wrap is enabled or your cgi-bin executes using your own account’s userid. in this case you have to make sure that nothing can be written arbitrarily into your cgi-bin even using your own account permissions. Keep in mind that you do not need permission to write to a script. You can remove the write permission even for yourself. If you need to change it later, you first change the permission to allow write, then change it back. It doesn’t need to sit there with write permissions. You have to be very cautious about what scripts are installed, because any script with an exploit can be dangerous. if someone can write or upload to your cgi-bin, they can create their own script and run it under you userid. If you use cgi-wrap, there is no reason for the group or the world to have any permissions on your files. so, you should change permissions something like this: chmod 400 (only you have read permission). scripts can be chmod 500. writable datafiles can be chmod 600, but should not be stored in a public area. remember that if someone can run arbitrary code as your userid, they own your account!

6. Try to break into your own account. Go through your scripts and try to upload a file that shouldn’t be allowed. Look at scripst that send email and see if you can enter data in such a way that code gets executed.

Summary:

The moral of the story is to be cautious with your cgi-bin. Especially look for writable files and directories. Never trust other users on your server. It may not seem important to take security seriously for your homepage with a bulletin board and formmail script. But there are malicious people out there always scanning for easy targets. Your data can be compromised or your bandwidth stolen – leaving you with the bill. A little bit of extra time can save you a lot of grief later.