1. A Hierarchical Classification
Of
Web Vulnerabilities
Sean Roberts
Information Security Practicum
Professor Ling Liu

2. ABSTRACT
This paper presents a hierarchical classification of web vulnerabilities based on their
causes. The purpose of this paper is to educate website administrators (also called
"webmasters") about the various types of web vulnerabilities, and inform them what (if
anything) can be done to prevent or reduce the damage these vulnerabilities may cause.
INTRODUCTION
As the Internet and World Wide Web become more and more a part of daily life, the
threats posed by security vulnerabilities in web pages are also becoming more dangerous.
For example, an improperly designed file upload system on a website might allow a
hacker (also referred to as an "attacker" in this paper) to install a virus on the system of
anyone who visits the site [17]. Due to the severity of some of these web-based attacks,
it is imperative that webmasters are aware of the different types of web vulnerabilities.
A simple Google search on "web vulnerabilities" will return nearly 22 million results, and
many of these pages will describe various types of vulnerabilities such as cross-site
scripting (XSS) or SQL injection. However despite this wealth of available information,
very little work has been done to group different types of vulnerabilities together in a way
that illustrates their similarities and differences. This is unfortunate because
understanding the differences between web vulnerabilities can sometimes help eliminate
them. For example, webmasters should be aware that certain vulnerabilities only apply to
specific services. If a service such as PHP has a buffer overflow bug that Ruby on Rails
does not, a webmaster might decide to use Ruby on Rails instead of PHP. Because
understanding the similarities and differences between web vulnerabilities can be useful
in defending against web-based attacks, this paper presents a hierarchy that groups
similar vulnerabilities together based on their causes. Each group is discussed using
examples that illustrate how to either eliminate or reduce the threats posed by those types
of vulnerabilities.
2

3. WEB VULNERABILITY HIERARCHY OVERFIEW
Figure 1: Hierarchy of Web Vulnerabilities
There are two main groups of web vulnerabilities in the hierarchy: general vulnerabilities
that affect all web servers, and service-specific vulnerabilities, which are found in the
particular services (such as PHP or Apache) running on a web server. There are 3 sub-
groups of general vulnerabilities--feature abuse, unvalidated input, and improper design--
and 2 sub-groups of service-specific vulnerabilities--feature abuse and implementation
bugs. The lowest level of the hierarchy provides specific examples of vulnerabilities that
belong to each sub-group.
The hierarchy structure is useful for two reasons. First from a top-down perspective, a
webmaster can attempt to setup their site to avoid an entire group of vulnerabilities such
as unvalidated input and then get more specific as the site matures. Second from a
bottom-up perspective, a webmaster can eliminate a particular vulnerability such as SQL
injection, and then start considering the different problems that can be solved by
validating all user input.
General vs. Service-Specific
The choice was made to divide the types of vulnerabilities into general and service-
specific because it provides a good reference for taking a "divide-and-conquer" approach
to securing websites. For example, if a webmaster is developing a new site, they may be
interested in learning about the vulnerabilities that are common to all web servers. In
addition, when deciding what web server program to run the site on, the ability to classify
all the vulnerabilities that are specific to a particular server program (such as Apache or
Microsoft's IIS web server) would certainly help in making the decision.
3

4. GENERAL WEB VULNERABILITIES
There are 3 groups of general web vulnerabilities: feature abuse, unvalidated input and
improper design.
1. Feature Abuse
A general feature abuse vulnerability occurs when an attacker might be able to launch an
attack based on information obtained by using a legitimate feature of a web protocol.
Although these features were originally intended to be helpful, attackers have found ways
to use them for malicious purposes [2]. Keep in mind that although a feature abuse
vulnerability might be classified as general and therefore apply to all programs of a
certain type (for example web servers), the method by which a webmaster might
eliminate or reduce the impact of the vulnerability could be specific to the particular
program they are using. For example, removing a general web server feature abuse
vulnerability when running Apache might be different than fixing that vulnerability in
IIS.
Example: Cross-Site Tracing (XST)
HTTP TRACE requests are typically used to debug web connections and are
supported by all web server programs. When a server is sent a TRACE request, it
will echo the request back to the sender, including header information. In a cross-
site tracing (XST) attack, certain vulnerable browsers can be scripted to send a
TRACE request to a particular site, and then send the result to the attacker [13].
Since browsers will only send authentication details and cookies to the sites that
issue them, this means a user's browser could be tricked into sending their cookies
or authentication details to an attacker. A basic XST attack works as follows:
1. Assume the victim has secret authentication and cookie information for
www.secret.com.
2. The victim visits the attacker’s site.
3. The attacker’s site causes the victim’s browser to send a TRACE
request to www.secret.com. And because the victim has authentication
credentials for the site, the header of the TRACE request will contain
these credentials.
4. After receiving the request, the server will echo it back, and the
attacker’s site will send the victim's request containing their authentication
credentials to the attacker.
In order to prevent XST attacks, a web server must be configured to disable
TRACE requests. The method in which TRACE requests are disabled varies
depending on the server program. To do this in Apache, the following lines must
be added to the httpd.conf file [3]:
RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^TRACE
RewriteRule .* - [F]
4

5. 2. Unvalidated Input
When users provide input to a web page, the input is typically used to perform actions
such as querying a database or producing dynamic web content. Suppose for example,
that a login page took as input a username and then displayed a new page that said "Hello
<USERNAME>." If "Sean" was entered as the username, a page that said "Hello Sean"
would be displayed. The input was most likely placed directly into the code of the new
page. Consider what would happen if the following was entered as the username:
<script language=Javascript>alert('Hi');</script>
Most likely, the person who entered this would be taken to a page that displayed a pop-up
box saying "Hi." This is because the input was directly placed in the code of the new
page. So providing anything supported by the page (such as HTML tags, PHP
commands, or SQL queries) as input could alter the appearance and behavior of the page.
The danger here should be obvious, as these vulnerabilities can give hackers the ability to
change a dynamic page on a web server.
These types of problems are classified as unvalidated input vulnerabilities because the
web pages doe not check to make sure the user provided proper input [20]. These
problems are also commonly referred to as "injection vulnerabilities" because they allow
attackers to inject code into a page. This paper classifies them as unvalidated input to
better illustrate their cause and solution.
Validating user input eliminates these vulnerabilities. There are various ways to do this,
depending on the type of input that needs to be prevented and also the method in which a
page processes input. If, for example, PHP is used to take user input and display it on a
dynamic page, the filter_var() function can be used to remove any tags from the input
[19]. Assume that this is the code for the "Hello <USERNAME>" page:
Hello <?php print $_GET["username"];?>
Changing the above line to:
Hello <?php print filter_var($_GET["username"], FILTER_SANITIZE_STRING);?>
will remove any tags from the input [19].
So the input:
<script language=Javascript>alert('Hi');</script>
becomes:
alert('Hi');
and will produce a page that displays "Hello alert('Hi');."
5

6. Example 1: Cross-Site Scripting (XSS)
One of the most common web vulnerabilities is called cross-site scripting (XSS),
where an attacker can inject a malicious script into a website due to a lack of input
validation [7]. If a user visits a previously trusted site that contains an injected
script, their browser will execute the malicious code. The issue here is one of
false trust. The user and browser both trust the site, and have no way of knowing
that the malicious script has been injected into the site covertly and should
therefore not be executed. Validating input by removing any tags before
processing will eliminate XSS vulnerabilities.
Example 2: SQL Injection
One of the most popular web-based attacks is a SQL injection, where instead of
the expected input, a malicious user enters a SQL query in order to perform an
unauthorized database operation [9]. For example, assume a login page takes as
input a username and password, and then queries a database to verify the login
information. If the login is correct, access to the site is granted, and if incorrect,
the user must enter their information again. If the web page makes a direct SQL
database query without performing validation first, an attacker could enter a SQL
query as their username to read, add or delete information from the database. The
following example shows how SQL injection can be used to retrieve all the
records from a database:
Assume a web page makes the following SQL query [16]:
select * from MYTABLE where name=" + username
where “username” is the input provided by the user. If an attacker provides
"name' OR 'a'='a'" as input, the query will be:
select * from MYTABLE where name= 'name' OR 'a'='a';
The OR statement will always be true because ‘a’ will always equal ‘a.’ As a
result, the where portion of the query becomes 1:
select * from MYTABLE where 1
This evaluates to:
select * from MYTABLE;
which will return all the records from MYTABLE.
In order to prevent SQL injection, input must be validated to ensure that if it does
contain SQL commands, they are ignored or removed before the query is made.
One way of doing this is by using parameterized statements, where user input is
passed as a parameter to a predefined SQL statement, as opposed to the traditional
6

7. method of simply concatenating input with a query. Defining a parameterized
statement varies depending on the language a web page is written in. The
following code shows how to create one using PHP [4]:
$statement = $db->prepare("select * from MYTABLE username=:username");
$ statement->bindParam(':username', $username)
$stmt->execute();
Here the query has already been prepared and the user input in the PHP variable
“$username” is safely passed as a parameter to the query using the bindParam()
function. Parameterization prevents the query from simply being concatenated
together with user input, and as a result, prevents the SQL injection attack
described above from working.
3. Improper Design
An improper design vulnerability occurs when a poor design decision could be used to
launch an attack on a site. For example, several sites display SQL error messages to the
user when there is a problem updating a database. These errors can reveal sensitive
information such as the name of a particular table or field in the database, which could be
used to perform a SQL injection attack. Error messages that display the particular
version of SQL running on a server are also dangerous, as an attacker could attempt to
exploit a vulnerability for that version.
A number of improper design vulnerabilities arise because most webmasters do not
initially consider security when creating a site. Often the goal is to get a site up and
running as quickly as possible, and as a result, design decisions are made that introduce
unforeseen vulnerabilities. While some of these problems can be fixed rather easily in
the future by validating input or removing error messages that reveal information about
the server, other aspects of a site (such as the ability to upload files, which will be
explained in more detail in the malicious file execution example below) might have to be
completely redesigned to remove a vulnerability. As a result, when creating a website, it
is imperative that security be built-in to the design to avoid the problems that might occur
when attempting to add it later.
It should be noted that because validating user input is also a design decision, the
unvalidated input group in the vulnerability hierarchy could technically be considered a
sub-group of improper design. However, because there are such a large number of
vulnerabilities which result from not validating input, it was decided that making
unvalidated input vulnerabilities a separate group would help to better illustrate the
importance of input validation.
Example 1: Malicious File Execution
A malicious file execution vulnerability allows an attacker to run a malicious
program on the victim web server. This vulnerability can occur in two ways:
7

8. 1. Remote File Execution: An attacker is able to provide input that
references a malicious program on a remote system, which will then
execute on the server they are trying to exploit. This vulnerability can be
avoided by validating input to ensure that if an attacker enters the URL of
a remote file or script, it will not be executed.
2. Upload File to Server: In this case, an attacker is able to upload a
malicious file to the web server, which then executes [17]. This
vulnerability typically occurs when a site is designed to allow users to
upload various files such as documents, pictures, etc, but the site does not
filter the type of file a user enters, and therefore any type of file can be
uploaded.
To prevent this type attack, a webmaster should explicitly restrict the type
of files that can be uploaded. If an upload function is only meant to be
used for text files, then all other file types should be explicitly denied.
Also, files should be uploaded with the most restrictive permissions
possible, making certain to explicitly deny the ability to execute files.
This way if an executable file is somehow able to be uploaded (possibly
by renaming the file so it appears to be a document or other file type that
is allowed to be uploaded), it will still not be able to run on the web server.
Unless absolutely necessary, root (or any other user account with
administrative privileges) should not be the owner of any uploaded files.
This will help reduce the damage a malicious program could cause if it is
able to execute. Lastly, uploading all files to a directory that is outside (or
unable to access) the web server program could also help limit the amount
of damage a malicious file execution could cause, although some
programs might be able to access and exploit the server even if they are
stored and executed in a separate directory.
Example 2: Username Enumeration
When designing a login system for a website, it is imperative that an incorrect
login attempt does not reveal information regarding the validity of either the
username or password. An improperly designed login system might display the
phrase, "Incorrect Username" when supplied a username for which there is no
account on the server. Similarly, the system might give the response "Incorrect
Password" when the username entered is the name of an actual account, but the
password given does not match the corresponding account password. Error
messages such as these are dangerous and introduce additional vulnerabilities
because they can provide a hacker with information that can be used to gain
access to a site.
Username enumeration occurs when a hacker repeatedly enters possible
usernames (with any password) until they receive the error "Incorrect Password"
instead of "Incorrect Username" [8]. This signals that the name of a valid account
has been found. Once this is done, a hacker will usually attempt to brute-force
8

9. crack the password, which involves repeatedly trying all possible character
combinations for the password.
While additional steps should be taken to prevent brute-force attacks (such as
locking an account after 3-5 unsuccessful login attempts), it is also necessary to
prevent username enumeration by providing a more ambiguous error message
such as "Invalid username or password." This reveals no critical information and
is therefore much more secure than messages that explicitly state whether the
username or password is correct. As a result, a hacker would have to try all
possible usernames in conjunction with all possible passwords in order to gain
access to the site through the login system, which is exponentially more difficult
that attempting to brute-force the password of a single account with a known
username.
SERVICE-SPECIFIC WEB VULNERABILITIES
There are 2 groups of vulnerabilities that pertain to specific services running on a web
server: feature abuse and implementation bugs.
1. Feature Abuse
This is the same type of vulnerability group as discussed previously in the general web
vulnerabilities section. However, in this case, these vulnerabilities are the result of a
feature of a particular service.
Example: PHP Information Disclosure (OSVDB-12184)
PHP has a feature called "expose_php" that will disclose version and other
sensitive information when the server receives certain HTTP requests [1]. By
sending specially crafted HTTP requests, an attacker can get the server to send
this information and use it to develop a targeted attack on the web server to take
advantage of its particular configuration. For example, by learning what version
of PHP is running on a server, an attack can be written that takes advantage of
vulnerabilities in that version. Therefore, unless absolutely necessary for testing
purposes, expose_php should be disabled by changing the following line in
php.ini from:
expose_php = On
to:
expose_php = Off
2. Implementation Bugs
These vulnerabilities are the result of errors in the way a particular service was
programming. While feature abuse vulnerabilities take advantage of something that the
service was intended to do, implementation bugs are the result of unintentional
programming errors made by the developer of a service.
9

10. Unfortunately, unless these vulnerabilities exist in code that was written in-house, a
webmaster must wait until the company that developed the software releases a patch
correcting the bugs. As a result, service updates and patches should be applied regularly.
In fact, an exploit is often written to take advantage of a bug that has already been fixed.
But because many users do not apply patches regularly, their systems remain vulnerable.
For example, the initial rapid spread of the recent Conficker worm was attributed to the
fact that some users had not applied Microsoft's patch--which was released in October of
2008--that fixed the vulnerability the worm used to infect systems. The worm was first
detected in November of 2008, and by January 2009, it was estimated that 3 out of 10
users had yet to download the patch [15].
Example: Buffer Overflow
A buffer overflow vulnerability occurs when a user can put more data into a
buffer than the programmer intended [11]. For example, if a programmer created
a buffer that can hold 10 bytes of data but does not check the size of the user’s
input, the user could input hundreds of bytes into the buffer. Adding more data to
a buffer than it was designed to store can overwrite a function's return address,
which can either cause the program to crash or execute code at the new address.
Attackers insert their own code into the buffer which then executes and can
perform any number of functions. Buffer overflow exploits are typically used to
perform privilege escalation on a system, where an attacker is given
administrative rights that under normal circumstances they should not have [11].
Again there is little that can be done on the webmaster's end to remove a buffer
overflow vulnerability. If the exact nature of the bug is known (as in how much
data can be put into the buffer before it overflows), restricting the size of the input
passed to the buffer could help. For example, if the vulnerable service processes
the username that is entered on a login page, and the overflow occurs after
entering more than 30 characters, restricting the size of the username entered
could prevent any problems. It should be realized, however, that while validating
input in this case stops the vulnerability, the actual cause is an implementation
bug, which is why a buffer overflow vulnerability is not considered an
unvalidated input vulnerability.
RELATED WORK
Despite the fact that there has been no work on establishing a hierarchy for web
vulnerabilities, several other aspects of computer security have well-defined hierarchical
classification systems.
Malware Naming
The common standard for naming malware (malicious software) is:
<malware_type>://<platform>/<family_name>.<group_name>.<infective_length>.<sub_variant>
<modifiers> [12], [10]
10

11. The fields above are defined as follows [14]:
Malware Type: Virus, worm, Trojan horse, etc
Platform: Operating system type (i.e. Windows, Linux)
Family Name: Members of a malware family behave similarly
Group Name: Sub-class of family, rarely used
Ineffective Length: Length of malware code
Sub-Variant: Small variant of an existing malware program (often denoted A, B, C, etc.)
Modifiers: Denotes which polymorphic engine a polymorphic malware program uses
While this is certainly a very structured classification system, the information it provides
has limited uses. Similar to the biological classification system for naming plants and
animals, the purpose of this malware naming scheme is to show the relationships between
malicious programs (for example, what family of viruses a particular strand evolved
from). However, because it is difficult to protect against malware infection, this
classification system does not provide the same usefulness as the web vulnerability
hierarchy in terms of potential methods of protection. (Although, it could be argued that
to protect against worm infection, a user could disconnect their system from a network
since worms propagate over networks. Also, if a user wanted to avoid being infected by
a Windows virus, they could use Linux instead. But these examples are trivial and their
usefulness is limited at best).
Network Vulnerability Classification
Unlike the standard for malware naming, there are a number of different network
vulnerability classification systems, including Matt Bishop's renowned work, "A
Taxonomy of UNIX System and Network Vulnerabilities" [5]. While very thorough and
in-depth, this classification system is too specific to provide a useful method for
describing the relationships among different vulnerabilities. Each vulnerability is
categorized by class, when it was discovered, why it exists, and what effect the
vulnerability has on a computer system. While this information is certainly useful if a
person wants to learn more about a specific vulnerability, it is not very helpful in
attempting to eliminate or understand an entire group of vulnerabilities.
My web vulnerability classification system has some similarities to another work by
Bishop (and three colleagues) entitled "Tree Approach to Vulnerability Classification"
[6]. The specific system presented by Bishop for classifying protocol vulnerabilities
(shown below) has three groups: mis-configuaration, design, and implementation. The
latter two are similar to the improper design and implementation bug groups,
respectively, in the web vulnerability hierarchy.
Figure 2: Bishop's Classification Hierarchy for Protocol Vulnerabilities [6]
11

12. WEB VULNERABILITY DETECTION
While writing this paper, I was also developing a program to detect web vulnerabilities
called "SKR Web Server Scanner." A main component of my application is the
vulnerability database. Since there was not enough time to research thousands of web
vulnerabilities and create my own database, I used the open-source database found in the
application Wikto [21], a Windows-based web vulnerability scanner based on Nikto [18],
a popular vulnerability scanner for Linux. Wikto has only 2800 web vulnerabilities in its
single database file, whereas Nikto has many more complicated vulnerabilities spread out
across 9 different files. Due to my limited experience with web vulnerabilities, I chose to
use the simpler Wikto database for my application.
SKR Web Server Scanner works by sending the server it is scanning a request from the
database that is designed to exploit a given vulnerability. The application records the
server's response, and then creates another request that is similar to the first.
(Specifically, the string "FakeVuln" is added to some portion of the original request to
produce the second). The second request is sent to the server and the response is
recorded. The two responses are compared, and if they are different, the application
detects that the server has the vulnerability the original request was attempting to exploit.
The detection logic works as follows: The first request sent from the database is
designed to exploit a specific vulnerability, which if present on the server, will produce a
particular response. However, HTTP responses can be quite long (and vary slightly
depending on the web server program), and therefore cannot effectively be stored in a
vulnerability database. So my application records the server's response, then sends a
second request (similar to the first), and again records the response. Because the second
request was modified to ensure it does not exploit the vulnerability, if the server is in fact
vulnerable to the first request, the two responses will be different. But if the server is not
vulnerable, the two responses will be similar (both could simply be "HTTP/1.1 400 Bad
Request"). A threshold rating is used to determine how different the two responses must
be for SKR Web Server Scanner to detect a vulnerability.
Results
It was difficult to thoroughly test my program due to a lack of available web servers to
scan. However, on a baseline Apache installation, SKR Web Server Scanner detected 18
potential problems, including an XST vulnerability as well as a few instances of the
"expose_php" feature abuse vulnerability discussed earlier (In fact, I first became aware
of this particular vulnerability after it was discovered by my scanner). Despite the
inability to effectively test my program, SKR Web Server Scanner does detect the same
vulnerabilities as Wikto, (which makes sense, since both applications use the same
database), so it is at least as effective as other web scanners. Testing also showed that a
threshold rating of 0.9 was sufficient for detecting vulnerabilities (higher values produced
too many false positives). A screenshot of the application is shown below (NOTE: The
entries listed as "This might be interesting..." are potential attacks that have been added to
the Wikto database but have not been verified as exploiting actual vulnerabilities):
12

13. Figure 3: Output of SKR Web Server Scanner
CONCLUSION
As illustrated in the improper design vulnerability section, security should be built-in to a
website from the beginning. Adding security measures at a later time could be
problematic and in some cases might require redesigning some (or even all) of the site.
While performing tasks such as input validation or using a vulnerability scanner can help
eliminate some problems, it is unfortunately impossible to remove all vulnerabilities from
a website. Hackers are constantly developing new attacks, and in the future there could
even be an entirely new group of vulnerabilities not covered by the hierarchy presented in
this paper. As a result, webmasters must continue to educate themselves about new web
vulnerabilities, and start designing sites from a more security-oriented perspective (in
other words, they need to start thinking like attackers). Hopefully this paper can be used
as a first step in developing a continuing website security education.
13

14. REFERENCES
[1] "12184: PHP Version and Information Disclosure." OSVBD: The Open Source
Vulnerability Database. Accessed: November 22, 2009. http://osvdb.org/12184
[2] "[Abuse of Functionality] Threat Classification." Web Application Security
Consortium, 2005. Accessed: November 2, 2009.
http://www.webappsec.org/projects/threat/classes/abuse_of_functionality.shtml
[3] “Apache Week. Security issues force release of 2.0.44.” Apache Week, January 20,
2003. Accessed: November 8, 2009. http://www.apacheweek.com/issues/03-01-24
[4] Bango, Matt. "Prepared Statements in PHP and MySQLi." April 9, 2008. Accessed:
November 21, 2009.
http://mattbango.com/notebook/web-development/prepared-statements-in-php-and-
mysqli/
[5] Bishop, Matt. "A Taxonomy of (Unix) System and Network Vulnerabilities."
Department of Computer Science, University of California at Davis, May 1995.
Accessed: November 21, 2009.
http://cwe.mitre.org/documents/sources/ATaxonomyofUnixSystemandNetworkVulnerabi
lities[Bishop95].pdf
[6] Bishop, M, Sophie Engle, Damien Howard, Sean Whalen. "Tree Approach to
Vulnerability Classification." Department of Computer Science, University of California
at Davis, May 1995. Accessed: November 21, 2009.
http://www.cs.ucdavis.edu/research/tech-reports/2006/CSE-2006-10.pdf
[7] "Cross-site Scripting (XSS)." The Open Web Application Security Project. Accessed
November 20, 2009. http://www.owasp.org/index.php/Cross-site_Scripting_(XSS)
[8] DelGrande, Jordan. "Web Application Username Enumeration." Security Technology
Science Pty Ltd, 2007. Accessed: December 3, 2009.
http://securitytechscience.com/resources/whitepapers/webapp_username_enumeration.pd
f
[9] Doshi, Pratiksha, and Sumit Siddharth. "Five common Web application
vulnerabilities." Security Focus, April 28, 2006. Accessed: November 21, 2009.
http://www.securityfocus.com/infocus/1864
[10] Fitzgerald, N. "A Virus By Any Other Name: Virus Naming Revisited." Virus
Bulletin – pp. 7-9. January 2003.
[11] Frej, Piotr, and Maciej Ogorkiewicz. "Analysis of Buffer Overflow Attacks."
November 8, 2002. Accessed: November 18, 2009.
http://www.windowsecurity.com/articles/Analysis_of_Buffer_Overflow_Attacks.html
14

15. 15
[12] Gordon, Sarah. "Virus and Vulnerability Classification Schemes: Standards and
Integration." Symantec Corporation, 2003. Accessed: November 13, 2009.
http://www.symantec.com/avcenter/reference/virus.and.vulnerability.pdf.
[13] Grossman, Jeremiah. "Cross-Site Tracing (XST): The New Techniques and
Emerging Threats to Bypass Current Web Security Measures Using TRACE and XSS."
WhiteHat Security, January 20, 2003. Accessed: November 8, 2009.
http://www.cgisecurity.com/whitehat-mirror/WhitePaper_screen.pdf
[14] Klinder, Bernie. "Computer Virus Primer for Network Administrators."
LabMice.net, September 2002. Accessed: November 13, 2009.
http://labmice.techtarget.com/antivirus/articles/avprimer.htm
[15] Leyden, John. "Three in 10 Windows PCs still vulnerable to Conficker exploit."
The Register, January 19, 2009. Accessed: November 18, 2009.
http://www.theregister.co.uk/2009/01/19/conficker_worm_feed/
[16] McDonald, Carol. "Top 10 web security vulnerabilities number 2: Injection Flaws."
Open Web Application Security Project (OWASP), October 2, 2009. Accessed:
November 21, 2009.
http://weblogs.java.net/blog/caroljmcdonald/archive/2009/10/02/top-10-web-security-
vulnerabilities-number-2-injection-flaws
[17] McDonald, Carol. "OWASP Top 10 number 3: Malicious File Execution." Open
Web Application Security Project (OWASP), October 8, 2009. Accessed: November 13,
2009. http://weblogs.java.net/blog/caroljmcdonald/archive/2009/10/08/owasp-top-10-
number-3-malicious-file-execution
[18] "Nikto." CIRT.net, October 6, 2007. Accessed November 22, 2009.
http://cirt.net/nikto2
[19] “PHP Tutorials Examples Filtering Data with PHP.” Accessed November 20, 2009.
http://www.phpro.org/tutorials/Filtering-Data-with-PHP.html
[20] "Unvalidated Input." The Open Web Application Security Project. Accessed
November 20, 2009. http://www.owasp.org/index.php/Unvalidated_Input
[21] "Wikto: Web Server Assessment Tool." SensePost, December 2009. Accessed
November 22, 2009. http://www.sensepost.com/research/wikto/