1 Server-side security

In order to make scripts secure, all user input must be carefully checked. The best way to check user input is by writing regular expressions which specify the exact pattern of the expected input. This will be further explored in Week 8 . This tutorial focussed on understanding the risks and applying simple checks.

Exercises

1.1 Directory indexing and path traversal:
Login to your DCS account. Create a new directory under your public_html and change its permission (chmod 755). Create a file in that directory. Then look at that directory through your browser. Can you see which files are in the directory? Create a file called index.html in that directory. Look again at the directory through your browser.

1.2 HTML injection:
Create a simple web form with a textfield and a simple script that prints the user input from the textfield. (You can use the script from Week 2 for this exercise if you still have it.) Apply no security at this stage. Try entering text with html tags into the textfield (for example "<i>hello</i>") and see what happens.

1.3 Defacing:
Continuing from the previous exercise, enter an image tag (<img src='...' >) with a valid URL into the textfield. See what happens.
In order to fix these basic security risks: if you are using PHP, apply functions, such as htmlspecialchars() and strip_tags(), and observe what they do.
If you are using Perl, apply the following code (assuming that $textfield is the content from the textfield) $textfield =~ s/</&#60;/g; $textfield =~ s/>/&#62;/g;. These regular expressions will be explained later in the semester.

1.4 GET and POST requests:
Change the method on your form to GET and then to POST. In each case, observe what happens. While the form method is GET, observe how the query string changes. Edit the query string while it is displayed in the browser and press enter. While the form method is POST, add a print statement to your script that prints the Content_Length environment variable (for PHP: echo "\$_SERVER['CONTENT_LENGTH'] = ". $_SERVER['CONTENT_LENGTH']; for Perl: print "CONTENT_LENGTH is $ENV{'CONTENT_LENGTH'}";)

2 Mini browser

The following code is a Perl script that acts as a "mini browser" and allows raw data exchange with an HTTP server. Save the file as "webget.pl". Then run the script on the Unix command-line by typing, for example, 
perl webget.pl www.dcs.napier.ac.uk /index.html | more
Note that the slash (/) in front of the document is necessary. Host and document must be separated by a space. The Unix programs curl or wget can also be used in this manner, but the advantage of webget.pl for security testing is that it is raw code and easy to modify. 
#!/usr/bin/perl -w
use IO::Socket;
unless (@ARGV > 1) {die "usage: $0 host document ..."}
$host = shift (@ARGV);
foreach $document (@ARGV){
        $remote =IO::Socket::INET->new(Proto => "tcp",
        PeerAddr => $host,
        PeerPort => "http(80)",
        );
        unless ($remote) { die "cannot connect to http daemon on $host"}
        $remote->autoflush(1);
        print $remote "GET $document HTTP/1.0\n";
        print $remote "Host: $host\n";
	print $remote "\n";
        while (<$remote>) {print}
        close $remote;
}

Exercises

2.1 Try this mini browser on a variety of websites. Instead of "/index.html" use "/" or another document. Try it on some of your own websites. Try it on a site that sets cookies.

2.2 Add a seurity requirement to one of your own scripts that tests HTTP_REFERER and exits if the REFERER is not the correct form. Then add "REFERER: ..." to webget.pl in order to pretend to come from the correct form. (In this case, really "REFERER" and not "HTTP_REFERER".)

Exercises: Check the security of your own pages

3.1 Unix security:
Ask the person who is sitting next to you what their matric number is and tell them what is yours. Then have a look at their files through your account on DCS. Talk to them about what they can see in your DCS directory. If you don't like the level of security of your files, then change it. Your top level directory must have execute permission for others, but it does not require read permission for others. Only the files in public_html must have read permission for others. All your other files and directories can be protected from other users on the same machine!

3.2 PHP/Perl security of your own files:
Have a look at the security of the script files that you created so far. Which of them are secure? If you have insecure files which you created during previous tutorials, it is best to remove the execute permission of these files at the end of the tutorials. Make sure that your directories which contain scripts cannot be listed via a browser.

3.3 Security of your files for the coursework:
If you are using PHP on DCS, it will be very difficult to protect your files from other students' eyes. You might consider changing the execute permissions each time you logout or using some "security through obscurity" (i.e. strange filenames and locations).
If you are using Perl, make sure your scripts have permission 700.