1. Implementing Cyber Security during the Development of
a Capstone Project
T. Dottie, J. Lindstrom, A. McQueen, S. Orozco, and T. Walls (students)
Department of Computing and Technology, Cameron University, Lawton Oklahoma, USA
Abstract – During the spring 2015 IT 4444 Capstone course
at Cameron University, students experienced firsthand what
was to be expected of members of a software development
team. The Capstone project gave students the opportunity to
build a system for a real-world client, Comanche County
Memorial Hospital’s Information Technology (IT)
department. The team built an inventory control system that
would initially be used exclusively for the IT department;
however, the system would be scalable for future use by the
entire organization. The authors of this study assumed the
roles of security specialists and had the responsibility of
ensuring the security and integrity of the system during all
phases of the project. The responsibilities included
identifying the security vulnerabilities associated with the
system, testing the integrity of the data fields in the database,
and attacking the PHP code with industry standard testing
protocols. This study chronicles the processes and methods
used to successfully ensure the security and integrity of the
Capstone project.
Keywords: Capstone, Security, Vulnerability Testing,
Penetration Testing.
1 Introduction
Cameron University’s spring 2015 Capstone IT 4444
course utilized approximately seventy students from various
degree fields and concentrations and integrated them into
three separate teams. Each team developed a complete,
secure application to be utilized by a real-world client. The
Comanche County Memorial Hospital’s IT department, a
part of Comanche County Hospital Authority (CCHA), was
the client. Teams were created through blind resumes and
cover letters. This procedure resulted in three separate teams
with groups inside each team based upon a student’s major
or concentration. The majors/concentrations represented in
this project included computer science, multimedia, database,
cyber security, and technical writing. Each team consisted of
a project leader, the leader’s deputy, a lead tech writer from
the English department, and leads for database, computer
science, multimedia, and cyber security. The focus of this
study concentrates on the development and testing of the
information assurance and security protocols used by the
cyber security specialists of two of the three teams.
1.1 Initial Interview
To ascertain what was necessary to create the
application software and determine the security requirements
of the system, the teams conducted a meeting with the client.
During the meeting team members asked questions
pertaining to the project. From this interview, the team was
able to determine the best course of action for the project.
The first task of the Cyber security team was to determine the
purpose and scope of their portion of the project.
1.2 Purpose
The purpose of this study was to provide a scientific
methodology for the accurate characterization of operational
security through examination and correlation of test results in
a consistent and reliable manner. The commitment to the
client consisted of ensuring confidentiality, integrity, and
availability.
1.3 Scope of Project
The activities within the scope of cyber security
testing included the following: (a) information gathering, (b)
penetration testing of the system, including the database,
middleware, and user interface, (c) configuration gathering,
(d) data validation, (e) vulnerability testing, and (f)
assessment of system components.
1.4 Not in Scope of Project
The activities not within the scope of the cyber
security testing included the following: (a) social engineering
to acquire sensitive information, (b) testing disaster recovery,
(c) business continuity, and (d) emergency response plan.
2 Identifying Vulnerabilities
It was determined by the cyber security team that
identifying the possible vulnerabilities was the first priority
in developing their security strategies. The website
owasp.org [1] included the OWASP top ten list of
vulnerabilities, which are included in Figure 1.

2. OWASP Top 10 – 2013
A1 – Injection
A2 – Broken Authentication and Session Management
A3 – Cross-Site Scripting (XSS)
A4 – Insecure Direct Object References
A5 – Security Misconfiguration
A6 – Sensitive Data Exposure
A7 – Missing Function Level Access Control
A8 – Cross-Site Request Forgery (CSRF)
A9 – Using Known Vulnerable Components
A10 – Unvalidated Redirects and Forwards
Figure 1. The OWASO Top 10 List
3 Testing Tools
The tools used for testing were an important part of
the research and development of the project. Access to
Cameron University computers was restricted, and
permission had to be granted by the university’s IT
department. The cyber security groups were allowed
limited administrative privileges utilizing computers that
were part of an isolated network that provided a controlled
environment. In this controlled environment, a sandbox
was created to administer the testing.
3.1 Sandbox
A sandbox is used to create an environment for
experimentation and testing of software code and web
applications. The testing environment isolates the
tested materials and testing tools from the actual
network and production environment. This precaution
prevented any unwanted changes or unauthorized
access to the university’s network. The Cameron
University IT department supplied desktop computers
with administrator privileges with which to work in
the sandbox. The cyber security group used
phpMyAdmin [2] as the sandbox for testing the
MySQL database and PHP code. With phpMyAdmin,
group members used dummy data created by the
database groups to test the following: logon and logout
procedures, password security, user privileges, and
inventory request and management [3].
The security team also utilized its own computers
to perform some of the tests. The team used the
Localhost on their laptops and were able to perform
various tests with tools available. Localhost is the
default name describing the local computer address,
also known as the loopback address. When setting up
a web server or software on a web server, 127.0.0.1 is
used to point the software to the local machine. After
loading the web application on its computers the team
was able to test it using the Localhost IP address.
3.2 Virtual Machine
Oracle Virtual Box [4] was the core component of the
sandbox. It provided a stable and controlled environment
within the computer system itself. This system was the best
choice for Cameron University’s IT department. The virtual
environment prevented potentially hazardous code from
being executed on its systems and was also capable of using
many different operating systems. Figure 2 shows a
screenshot of the Oracle VM management page.

3. Figure 2. Oracle VM Manager
3.1 Kali
Kali [5] is an open source operating system that was
used for testing the system. It is Linux-based and compatible
with many of the software testing tools available for
penetration testing.
3.2 Nessus
Nessus [6] is a security and compliance auditing tool
that monitors configurations, patches, and web applications
for errors and vulnerabilities [7]. The team used Nessus to
perform five separate scans that included the following:
• Host Discovery scan
• Bash Shellshock Detection
• Web Application Test
• Basic Network Scan
• Advanced Scan
The team ran Nessus in Kali Linux. To do so, Nessus
was launched from the command line in Kali with the
command /etc/init.d/nessusd start. Once Nessus was running
as a service, Ice Weasel was opened and the local host at
127.0.0.1:8834 was launched which opened the Nessus tool
itself. From this point each separate scan was configured and
launched.
3.3 Owasp/ZAP
The OWASP Zed Attack Proxy Tool (ZAP) [8]
is an open source tool used for web application
penetration testing. Its main function is to scan web
applications for possible vulnerabilities with its
passive scanning feature. The other important features
of ZAP are as follows: use of spiders to find all the
possible web pages; scanning for vulnerabilities and
confirming them with active scanners; and using
intercepting proxies to track and possibly change
requests that go from the host computer to the web
application. The team used the ZAP tool within the
Kali Linux virtual machine to test the database and
website of the inventory tracking system for possible
general vulnerabilities. The team also used the spider
feature to find any possible hidden or overlooked
webpages. ZAP was used to back up the findings the
team found with Nessus [8, 9]. Figure 3 shows a
typical Owasp/ZAP screen.
Figure 3. Owasp/Zap
3.4 SQLMap
SQLMap [10] is an open source tool that uses the
command line features on Windows and Kali Linux to detect
possible SQL injection vulnerabilities in a web application’s
database server. The tool scans the database server and
provides information that includes the following: usernames,
passwords, password hashes, and the database structure. The
tool supports multiple databases: MySQL, Oracle, Microsoft
Access, and so on. The team used SQLMap to scan the
MySQL database of the inventory tracking system to find any
possible sql injection vulnerabilities. The team used this tool
on a Windows 7 virtual machine, scanned the database, and
found vulnerabilities that could be used to exploit the
database to find usernames and inventory information [11].
Figure 4 shows a typical SQLMap screen.

4. Figure 4. SQLMap
3.5 Hydra
Hydra [12] was written as a proof of concept code. Its
intended use was to be a tool for showing that it is easy to
bypass passwords and gain entry to a system from a remote
location. This password-cracking tool supports multiple
protocols and multiple attack forms. It is also designed to
compile on multiple operating systems. This tool was used
for testing user authentication during the testing phase of the
project.
Hydra utilizes a simple graphical user interface with
tabbed pages. Each page sets up a different part of the
targeting process. The initial target is designated by entering
an IP address either for a single target or a group of targets
and a port number, if needed, as well as the protocol used, as
shown in Figure 5. Once a target has been entered, the
password tab can be used to define specific parameters to be
used by Hydra. Figure 6 shows an examples of this step.
Figure 7 shows the start/output page. Once a target has been
entered and parameters have been set, the start button is
clicked, and all data generated by Hydra for that attempt is
displayed in the output window.
Figure 5. Hydra Target setup tab
Figure 6. Hydra Password tab
Figure 7. Hydra Start tab and Output panel

5. 4 Testing Results
The team used the tools described previously to find
possible vulnerabilities that could be present in the CCHA
inventory tracking system. The initial tests did find some
vulnerabilities in the application. Working with the
computer science students and the database developers, the
vulnerabilities were addressed, and the security team was
able to run tests that did not show significant issues. The
results of the tests are described in the following
paragraphs.
4.1 Owasp/ZAP
Zap was a very user friendly application used
to test the software. Initial tests showed fifty-two
vulnerabilities possible within the application,
however, most of them were redundant. There were
only eight individual vulnerabilities identified with
this test. One was considered a significant, or high
threat, five were considered a medium threat, and two
were considered a low threat. The Owasp/ZAP
software identified the vulnerabilities and then gave
feedback on how to mitigate them. The team shared
this information with the development team and they
were able to utilize this information to correct the
problem. Figure 9 shows the summary of the ZAP
scan. Figure 10 shows some of the suggestions ZAP
made for mitigation of the vulnerabilities.
Figure 8. Owasp/ ZAP Scanning Report
Figure 9. Owasp/ZAP Solution

6. 4.2 SQLMap
SQLMap proved to be insignificant in our testing
procedures. The Owasp/ZAP software was able to
identify the problems associated with the application,
and SQLMap was not able to identify any unique
vulnerabilities.
4.3 Hydra
The team used hydra to perform brute force attacks
upon the sandbox. The method of attacking was to
brute force with a username and password list. Using
username and password lists, the first hydra brute
force testing used a username list called usernames.txt
and a password list called passwords.txt. The two lists
contained commonly used username and passwords,
and the account usernames for the MySQL database
and CCHA inventory tracking system. The students
began the testing by attacking the IP address 127.0.0.1
over port 80 and using the usernames.txt and
passwords.txt files. The results yielded all the possible
usernames found in the usernames.txt file and
matched them with the passwords from the
passwords.txt file. Hydra found that the usernames
were compatible with sixteen of the passwords. All of
the passwords for MySQL and the CCHA inventory
system were chosen, so there were matches with the
account usernames and passwords. Figure 10 show the
results of the test.
Figure 10. Using username.txt and passwords.txt Files
The second part of this test used the inventory
system’s administrator account name xxx.xxxx and the
database administrator account spargota instead of the
usernames.txt file. Hydra found possible matches with
sixteen passwords for each account. Figure 11 shows those
matches.
Figure 11. Using spagota as the Username
4.4 Nessus
All of the test result information in this
section was taken from the test reports generated by
the Nessus scans.
The host discovery scan gave this result: this plugin
attempts to determine if the remote host is alive using one or
more ping types:
- An ARP ping, provided the host is on the local subnet and
Nessus is running over Ethernet.
- An ICMP ping.

7. - A TCP ping, in which the plugin sends to the remote host a
packet with the flag SYN, and the host will reply with a RST
or a SYN/ACK.
- A UDP ping (DNS, RPC, NTP, etc).
The host discovery scan did not reveal any threats, it
simply provided information that indicated the status of the
local host.
The bash shellshock detection scan gave this result:
this plugin runs 'netstat' on the remote machine to enumerate
open ports. The following ports were found open:
Port 68/udp was found to be open. Port 68 / udp Hosts
127.0.0.1
Port 2734/udp was found to be open. Port 2734 / udp Hosts
127.0.0.1
Port 8834/tcp was found to be open. Port 8834 / tcp / www
Hosts 127.0.0.1
Port 11005/udp was found to be open. Port 11005 / udp Hosts
127.0.0.1
The web application test ran the same netstat scan as
the bash shellshock detection scan. The result of both tests
were the same.
The basic network scan produce many more results
and included: the server's X.509 certificate does not have a
signature from a known public certificate authority. This
situation can occur in three different ways, each of which
results in a break in the chain below which certificates
cannot be trusted.
First, the top of the certificate chain sent by the server
might not be descended from a known public certificate
authority, this can occur either when the top of the chain is
an unrecognized, self-signed certificate or when intermediate
certificates are missing that would connect the top of the
certificate chain to a known public certificate authority.
Second, the certificate chain may contain a certificate
that is not valid at the time of the scan, this can occur either
when the scan occurs before one of the certificate's
'notBefore' dates or after one of the certificate's 'notAfter'
dates.
Third, the certificate chain may contain a signature
that either didn't match the certificate's information, or could
not be verified. Bad signatures can be fixed by getting the
certificate with the bad signature to be re-signed by its issuer.
Signatures that could not be verified are the result of the
certificate's issuer using a signing algorithm that Nessus
either does not support or does not recognize.
If the remote host is a public host in production, any
break in the chain makes it more difficult for users to verify
the authenticity and identity of the web server, this could
make it easier to carry out man-in-the-middle attacks against
the remote host. The solution would be to purchase or
generate a proper certificate for this service.
The advanced scan provided the same results as the
basic network scan so the authors chose not to include those
results.
From all of the scan results only one vulnerability was
identified which was the certificate not being from a known
authority. All of the remaining issues were providing
information about the system, this information was not
relevant to the testing. Figure 12 shows a screenshot of
setting up a target for scanning.
Figure 12. Target Scan

8. 5 Recommendations
The security team researched best practices
throughout the semester and utilized knowledge obtained
from their previous studies. The team recommended two
key security elements for CCHA in regards to the finished
application. The first recommendation was for CCHA to
conduct their own security testing of the product. Security
is an ongoing dynamic process and should be integrated
into a routine on a regular basis. Because the application
was intended to be scalable for use in other areas of the
hospital and the application was accessible from outside
their intranet by remote web services, the second
recommendation was a layered approach for storage
purposes. The team suggested that the program be stored
on a virtual server in order to mitigate easy access from
outside sources. By utilizing a virtual server not only would
there be an additional layer of protection but this layer
would have a firewall available that could be used for more
added security.
6 Summary
The spring 2015 IT 4444 Capstone course gave students the
opportunity to apply their abilities in a real-world environment.
The cyber security team experienced first-hand how cyber
security testing is conducted in a business environment. The
team used their knowledge and skills to test the newly
developed CCHA inventory tracking system. By utilizing testing
tools available to them the security team attempted to ensure a
stable and secure application. The tests which were conducted
helped identify vulnerabilities that were present in the system
and worked with the development team to mitigate the risks.
The testing procedures taught valuable hands on skills and
processes that could only be experienced in this type of learning
environment.

9. [1] References
Owasp.org,. 'Category:OWASP Top Ten Project -
OWASP'. N.p., 2015. Web. 17 Apr. 2015.
[2] PhpMyAdmin. (n.d.). Retrieved April 17, 2015.
[3] Network Penetration Testing and Research, Brandon F.
Murphy, NASA John F. Kennedy Space Center, July 2013
[4] VirtualBox, Oracle, N.p. Web. April 1, 2015.
[5] Our Most Advanced Penetration Testing Distribution,
Ever. (n.d.). Retrieved April 17, 2015, from
https://www.kali.org/
[6] Nessus Vulnerability Scanner. (2012, December 18).
Retrieved April 17, 2015.
[7] Web Penetration Testing Using Nessus and Metasploit
Tool, Indraneel Mukhopadhyay, Shilpam Goswami, Eshita
Manda, ISOR Journal of Computer Engineering, Volume 16
Issue 3, May-June 2014
[8] OWASP Zed Attack Proxy Project, OWASP. N.p. Web.
April 1, 2015.
[9] The Basics of Hacking and Penetration Testing: Ethical
Hacking and Penetration Testing Made Easy, Second
Edition, Patrick Engebretson, page 160-163, Syngress
Publishing, 2013
[10] SQLMap Project, SQLMap. N.p. Web. April 1, 2015.
[11] Heuristic-Based Approach for Detecting SQL-Injection
Vulnerabilities in Web Applications, Ciampa, Visaggio, Di
Penta, SESS ’10 Proceedings of the 2010 ICSE Workshop on
Software Engineering for Secure Systems, pages 43-49, 2010
[12] THC-HYDRA - fast and flexible network login hacker.
(n.d.). Retrieved April 17, 2015.