Being a system administrator and abuse officer for an in the Netherlands based international orientated (shared) web hosting provider, one of my responsibilities is keeping an eye on vulnerabilities in (by our clients) widely used applications. Clients can use scripts written in ASP.NET (1.1, 2.0), ASP, PHP and Perl, so there is a lot to keep an eye on.
If you are a system administrator for a company yourself, you know one thing: Clients don't read. An other thing they don't do is keeping up with updates, (security-)information and patches. And yes, they are suprised when they find their web site defaced... A little while ago, Maurice wrote something about an Internet Drivers License, well... I am fan of this idea.

The recent storm of Mambo / Joomla! component advisories was a nightmare at the office. Within a few days a great number of advisories was released which showed major XSS (Cross Site Scripting) vulnerablities in used Mambo / Joomla! components. We (my collegues and I) are the first contact for our clients who's web sites got defaced. The information send out by our department to clients is too technical for most clients, and because they don't read and don't want to understand, we had to take action ourselfs. Because we do all our webhosting on Windows 2003 web servers (IIS 6), one of the few possible things to do was to set up server wide ISAPI_Rewrite rules. These rules would block specific exploit attempts, for example:

# http://www.milw0rm.com/exploits/1995
RewriteRule .*(?:com_forum/download.php?phpbb_root_path=).* / [F,I,L]
# http://www.milw0rm.com/exploits/1723
RewriteRule .*(?:/admin/addentry.php?phpbb_root_path=http(://|%3A%2F%2F).*?).* /
[F,I,L]
# http://www.milw0rm.org/exploits/2092
RewriteRule .*(?:com_lmo/lmo.php?mosConfig_absolute_path=http(://|%3A%2F%2F)).* /
[F,I,L]

Since we installed these rules I haven't heard of more web sites being defaced. Until new vulnerabilities are discovered of course.

In the same category as these Mambo / Joomla! component XSS vulnerabilities belong "ordinary" XSS vulnerabilities. Many web sites are build that by looking at a querystring it is determend what information needs to be displayed. Static files can be included, for example the following PHP code:

<?PHP
$page = $_GET["page"];
$file = fopen("$page","r");
if(!$file) {
    print "file not found";
}
else {
    include("$page");
}
?>

If allow_url_fopen is set to on in the php.ini, this code makes it possible to include files from remote web sites, if the GET variabele is not properly santinized. Spammers make use of these vulnerabilities a lot to include a PHP mailform in a website to send out their spam e-mail. On not properly secured webservers this could result in a system compromise.
The PHP script can be protected by defining which pages may and pages may not be included:

<?PHP
$page = $_GET["page"];
$pattern = "(http://|ftp://|../)";
if(eregi($pattern, $page)) {
    print "Wrong value submitted in querystring";
    exit();
}
$file = fopen("$page","r");
if(!$file) {
    print "file not found";
}
else {
    include("$page");
}
?>

TIMTOWTDI (There Is More Than One Way To Do It):

<?PHP
$allowed =
array("about.php","contact.php","page2.php","page3.php")
$page = $_GET["page"];
if(!in_array($page,$allowed) {
  Header("Location: /index.php");
  exit();
}
else {
  include("$page");
}
?>

A real pain in the @$$ are Email Injection attacks in email forms. These attacks give a real work load because in IIS it is not always easy to determine which web site form was abused. Really hundred thousands of e-mails can be send out in one attack, if not noticed in an early stage.
Unfortunately we (the company I work for) have had vulnerable example scripts on our helpdesk pages (currently used by thousands of clients...) and after the release of the Email Injection advisory and PoC (Proof of Concept), there was an enormous rise in sent out spam and abused mail forms. We have rewritten our example scripts and secured them against these attacks. Input validation has become real important for website builders and programmers.

For example, we have a POST variable from and use it as the from address:
  $headers = "From: " .$_POST['sender'];

When someone enters a linebreak and carriage return (%0D%0A), it is possible to inject a Cc header field. Unless the input is santinized by trimming these characters:
  $sender = trim($_POST['sender']);
  if (eregi("r",$sender) || eregi("n",$sender) || eregi("%0A",$sender) || eregi("%0D",$sender) ) {       exit();
  }
  $headers = "From: " .$sender;

We all know these Email Injection attacks are mostly done by bots, automatically. To prevent a direct call on the script, it is possible to include a hidden HTML form value and to compare that value with a predefined value. But because hidden formfields can be displayed in the brower when viewing the source, one must add something to it in the PHP script to make it unguessable:

HTML form:

<input type="hidden" name="code" value="V3v1DaSriNg0" />

In the PHP script, we define a code: 6a5949b7fc4a23136f2bbfdbbaf2f1c6
This is not just some random code, it is a md5 hash of our hidden HTML-code with "geheim" ("secret" in Dutch) in front of it. When we compare both values and they are equal, the POST was valid. But I love to do things the other way around, so I test if they are not equal:

$secret_code = $_POST['code'];
$our_code = "6a5949b7fc4a23136f2bbfdbbaf2f1c6";
if (md5("geheim".$secret_code) != $our_code) {
  // de secret codes are not equal, exit
  // the script.
  exit();
}

My point of this article is: It is a lot of fun to work for a big web hosting company but unfortunately you need to do the thinking for your clients. Even if others build the web sites. They expect this from you (they are wrong... you and I both know that). In my line of work I see different kinds of (Internet) abuse all the time and I believe we can reduce it if do just a little more for our clients.

A lot of good information about securing web applications can be found on and via the websites:
CGISecurity.com: http://www.cgisecurity.com
Web Application Security Consortium: http://www.webappsec.org