Lis4774.term paper part_a.cyber_eagles

Utilizing Command Line Arguments to Exploit Server
Vulnerabilities
Scott Lombard
Florida State
University
sal14j@my.fsu.edu
Zachary Potesta
Florida State
University
ztp17b@my.fsu.ed
u
Alexis Harvey
Florida State
University
aph15c@my.fsu.ed
u
Michael Costello
Florida State
University
mvc09@my.fsu.ed
u
Vincent Williams
Florida State
University
vew17c@my.fsu.ed
u
Abstract
Often times system engineers carelessly configure web servers, allowing for an unlimited trial and
error attack against an otherwise benign, public-facing search query. Such queries can be used
for malicious activities and can leave user information extremely vulnerable. This study was
completed to demonstrate the effectiveness of said strategies used to compromise an Apache web
server and what measures can be taken to prevent intrusive command line instructions. To provide
scale and relevance of the methods used, the computing environment has been clearly defined and
alternative attack methods have been included. The analysis of the conducted study clearly
indicates that command line injection was successful in breaking into the file structure of the
test-environment web server.
Keywords: Apache, Ubuntu, PHP, Command Line, Intrusion, Server Vulnerability
Introduction
The command line study that was conducted was based on previous examples seen in The Basics of Web Hacking
(Pauli, 2013). By seeing different implementations of the exploit our group was able to recreate a manipulatable
environment. To do so, it was necessary that two machines were present - one for browsing the web, and one for
hosting the site locally. Communications between the two computers were crucial to the functionality of the exploit.
It is common for the files producing front-end pages to be available. Therefore, it was appropriate for us to
determine which scripts were responsible for redirections and accessing the database. Behind the smoke and mirrors
lay a PHP file. Our group then researched which files types and found that we should target all PHP files. Due to the
design the web page and call to a certain PHP file, it was possible to use unix commands where a user would
typically conduct a normal search. The commands performed queries with administrative access giving the intruder
no limitations. Granted, this exercise was carried out in a sandbox environment, it is most certainly a possibility that
these types of exploits are available on public facing systems.
Review and Discussion of related articles
Florida State University School of Information
1

Utilizing Injection Scripts to Exploit Server Vulnerabilities
Surviving the deep end: PHP security is a book that provides great information related to input data and various
types of injection methods. Specifically, this section of the article talks about Directory Traversal. This is an
important concept to understand because it is very common and can manipulate the back-end of a web server. This
vulnerability has the ability to influence a “web application by injecting parameters capable of manipulating the file
paths employed by the backend operation”(Brady, 2017). The most important factor of path traversal is being able to
alter its path to a certain file and have it point to another. An attacker may use the “Dot-Dot-Slash sequence allows
an attacker to tell the system to navigate or backtrack up to the parent directory” allowing access to particular files
not intended for a public user to be granted rights. This is very similar to the vulnerability performed in the treasure
hunt exercise.
This book: The Basics of Web Hacking : Tools and Techniques to Attack the Web has valuable information about
tools used by attackers but also ways to prevent web application exploitation. The material in this book covers things
needed to know about web servers and their functionalities to web server recon, scanning, and exploitation with
injection. Chapter 2 is related to basics on web server hacking, and specifically, the process attackers would take
when exploiting a web server. The recon stage “is widely considered as the most important aspect of a
network-based attack” (Pauli, 2013). An example of this in relation to this stage in our treasure hunt exercise would
be to simply search through various file systems that are unprotected or can be given permissions easily. By
searching through the file system we were able to find .php files and various different directories. Just by utilizing
the first stage in the basics of web hacking like recon, provided us with valuable information being used to run the
web page.
The article: SQL Injection Cheat Sheet & Tutorial: Vulnerabilities & How to Prevent SQL Injection Attacks goes in
depth on how SQL command line injections work and how users use this type of attack to retrieve information for
the web application. A SQL injection works by ultimately allowing a web application to accept untrusted data.
“When an application fails to properly sanitize this untrusted data before adding it to a SQL query, an attacker can
include their own SQL commands which the database will execute” and return information that should not be
released. (Veracode, 2018). This is a common injection used my many attackers who prey on web server
administrators who fail to prevent unsanitized command inputs from being accepted.
This article: SQLiDDS: SQL injection detection using document similarity measure relates to SQL injections but
specifically a tool used to help prevent SQL injections from being used. This team is using a concept called
document similarity that is “typically used for web search, text categorization, information retrieval and in several
other domains”(Kar, Panigrahi, & Sundararajan, 2012). The technique has been implemented into what is now a tool
called SQLiDDS (SQL injection Detection using Document Similarity). They tested this tool on five different web
applications testing to be effective on all of them. SQLiDDS acts like a firewall that can “can protect multiple web
applications interacting with a database server such as in shared hosting environments, which gives it an edge over
existing methods” (Kar, Panigrahi, & Sundararajan, 2012).
Clarke’s book: SQL Injection Attacks and Defense is another great resource related to SQL injections. Clarke has
gone in depth into each stage of SQL injections and what to look for during that stage. When testing for injection
vulnerabilities it was stated that there are so many ways to perform these tasks that it is more effective to learn the
concepts of SQL injections and be able to apply those concepts rather than learn of every single SQL injection
possible. Overall the goal is to “trigger anomalies by sending unexpected data”(Clarke, 2012). Although not a SQL
injection, in the case of this exercise we were able to add a semicolon and enter additional commands to reach
information intended to be inaccessible.
The information in Makan’s book: Penetration Testing with the Bash Shell is intended for users that want to learn
practical skills on system penetration testing specifically with bash shells, and kali linux command-line based tools.
Network reconnaissance begins differently using bash or linux. Because you are on these operating systems you are
able to use a command that comes shipped with many of these OS systems called “whois”. “During a penetration
test, you may be given a list of IP addresses to work with, or a domain name that resolves to an IP address” (Makan,
2014) which can be used to perform whois commands gathering further information about that web server.
2 Florida State University School of Information

Additionally, a user can use a “dig” command which will return any information related to that DNS and IP address.
This book goes into amazing detail when exploiting vulnerabilities in a bash environment.
The Open Web Application Security Project (OWASP) is a foundation whose shares information about software
security. Their goal, as written by on their about page, is to be an “open community dedicated to enabling
organizations to conceive, develop, acquire, operate, and maintain applications that can be trusted”. The OWASP
connects with many security experts, to build documents, tools, guidelines, books, and other materials for
organizations to use to secure their code and systems. The project, being as big as it is, also has an in-depth section
that talks about cross-scripting attacks. The section goes into great detail about the types of XSS attack there are,
examples of what they look like, and some ways to combat the attacks or to prevent them out right.
Looking through all the sources, a common link that we found was the command line and interfering with the
back-end features of a website or server. What most of the sources agree on is that the lack of sanitizing the
command inputs is the main reason why command line vulnerabilities are still prevalent. The main aim is that,
without input sanitation, any user is allowed to just put in whatever they want, which may end up allowing them to
access the back end features of the website. This argument, to us, makes sense as troublesome things are likely to
happen when someone gains unauthorized access to the back-end of a website or server. Things like finding one’s
computer location or opening unauthorized files become very easy to do through this method. This link is something
that our team will want to focus on when moving forward with our research and tests.
Computing Environment
Due to the nature of the research, it is our responsibility to play devil’s advocate in constructing the web server
environment. While the purpose of this project is to exploit vulnerabilities, the server is setup with a realistic level of
integrity. The following subsections detail the various steps involved in launching an Apache web server. The
machines used to create this exercise consisted of one windows 7 virtual machine and one virtual machine running
Ubuntu. The machines are hosted in the same location and can therefore “see” one another. Because of the
accessibility, we were able to conduct penetration tests on the Apache web server.
Initial Server Configuration
Apache is to be installed on a machine running a Linux based operating system, such as Ubuntu, The command to
accomplish this is “sudo apt-get install apache2”. Establishing the ability to host a site from your Linux machine is
the single most important step in the outlined process.
In this scenario, we will unpack our site files from a precompiled directory that has been zipped and imported for
our convenience. If you are to recreate a similar scenario with a different site, you must perform a file transfer of the
local files you wish to host. Our site directory, extreme insecure, was zipped and located in the /home/admin
directory. Because the extreme insecure directory was zipped, it was necessary to unzip and move the files from the
/home/admin directory. The command to do so is “sudo unzip extreme insecure -d /var/www/”. The previous
command tells the computer to unzip the zipped specified directory, indicated by the -d flag, and to move it to the
new file location var/www/. Take note of the permissions to the left of “root root” on each file. “w” meaning the file
can be overwritten, “r” meaning the file can be read by the current user, and “x” meaning the file can be executed.
The permissions of files will play a critical role on what you can see and do once you’ve broken into the directory.
By establishing yourself inside of a victims directory as an administrator or superuser, you can “chmod 777 *” to
give yourself read write and execute permissions on all files.
3

It is then necessary to to configure your new virtual host. You will want to preserve the default configuration in case
you wish to repeat this process at a later time, or need to reset your configuration. The command “sudo cp
/etc/apache2/sites-available/000-default.conf /etc/apache2/sites-available/mynewsite.conf” will accomplish this.
These are the most essential steps in establishing a virtual host that is ready to support a website.

1. If you would like to add extra functionality to your server through the configuration file, you must do so in
XML format:
<Directory /var/www/
+<YourFunctionHere>
</Directory>
Beware, for the sake of convenience you may feel these additions are harmless and helpful. However, by
enabling these configurations you are giving a potential intruder more access points to enter and ways to
manipulate your machine.
After you completed these essential steps, your website will be accessible through the Apache server’s IP
address. You may simply type the IP address into the url bar in your secondary windows virtual machine to
see what you are hosting.
5

The above attack tree is derived from the thought process of what steps you take in order to
compromise a web server.
Due to the nature of our research and study, we thought it would be necessary to understand how hackers operate.
We came to learn that, when attempting to compromise a web server, it is possible to go about breaking in through a
countless number of ways. Our research indicates the methods discussed in The Basics of Web Hacking (Pauli,
2013), were the most suitable for an introduction to the skill.
Hacker, must collect and compiling useful data that can provide potential access points is, which will become the
foundation for an intrusion. Once that is set up, the next thing a hacker would focus on is the method of attack. The
methods we looked into is:
Command Line Injection
This method is often used to manipulate PHP vulnerabilities through site functionality. For example, a search bar
can potential grant access to backend operations. Directory traversal is a common subsection of command line
injection. By traversing the file structure with command line style statements, it is possible to gain access to critical
documentation (even if just read permissions enabled).
SQL Injections
This is the most popular tool of choice when compromising a web server because of their simplicity and
effectiveness rate. As the title implies, the injection calls various backend SQL queries that return user information
directly from the database. One location to inject, for example, would be the username field in a web form.

Log Injections
Often times logs are generated by applications and stored at the public or just below the public facing internet. The
most basic of logs writes basic data to a text file. For example, a login screen will grab whatever input you attempt
to submit and return whether it was valid or not. Regular expressions are used to break up data and parse through it.
One can manipulate the parsing sequence to insert false information. Using the logs can trigger exposure of their
stored information or even a disguise of failed administrative login attempts. The solution to this problem is to
sanitize the inputs your site takes from its users, limiting log functionality to an unauthorized party.
XSS: Cross-site scripting
Cross-site scripting (XSS) are attacks that inject malicious code into the targeted web applications or web browsers
and is executed on the client-side rather than the server side. It is one of the most common software vulnerabilities to
this day, as the attacks uses multiple computer languages (namely JavaScript and HTML), which most web browsers
and websites run. That said, the attack itself isn’t harmful towards the affected site, as the site itself isn’t the aim of
the attack. The attack of a XSS is aimed directly at the users who sues the infected web application or web browsers.
An attacker’s aim when executing a XSS to gather sensitive information from a victim or to gain access to the
victim’s machine. Things like: accessing your web browsing cookies, making http request to other websites, or even
gaining access to your machine’s location or using the webcam becomes possible through XSS attacks. What makes
this kind of attack even more terrifying is that – the attack itself is easy to circumvent but – due to the attacks
looking very similar to legit situations (such as seeing a link that looks real or seeing an email that looks convincing)
people will always fall prey to this kind of attack.
XSS attacks has been developed into many different strategies to gain specific types of information or web access
from their victims and have been only advancing more and more over the years, making it harder for the average
person to tell if they are being attacked. That said, most XSS attacks can be broken down into 3 types of attacks:
Stored attacks, Reflected attacks, and DOM-based attacks.
Stored XSS
Stored cross-site scripting is considered the most dangerous of all the 3 types of XSS. It involves the attacker
injecting a script into the victim’s application and having it permanently residing there. From the infected
application, the malicious code will gather the input and other information of the victim and will store the
information. What makes this type of attack extremely hard to avoid is that, once infected, the simple act of clicking
on a webpage could trigger the malicious code, to execute whatever the code needs to do.
Reflected XSS
Reflected cross-site scripting is code injection that is sent as part of the response from a victim’s request. While it is
easy for a victim to circumvent a reflected XSS attack, what makes it difficult is what forms the attack takes. One of
the forms a reflected XSS attack can take in is the form of phishing emails or fake error messages, which are aimed
to tricked the victim into downloading the script itself. Another form that the attack takes is in the form of links. The
attacker could set up a link on a specific webpage and any user who clicks on that link becomes a victim to the
attacker.
DOM-based XSS
A Document Object Model (DOM)-based cross-site is an attack that takes a different approach to infecting victims
compared to reflected and stored XSS, in that DOM-based XSS attack is a client side attack rather than a server side
attack. As the name suggest, the vulnerability (and attack) takes place in the DOM. Because the attack is client-side
– thus making the payload extremely difficult to find due to it looking extremely similar to the source code – the
attack is a lot harder to detect by firewalls.
7

Cookies
Cookies are tiny files that are stored on a computer and are made to keep data that is specific to a certain website or
client, and can be accessible by a web server or client computer. Cookies are most commonly used for tracking
website activity. The way this works is when first visiting certain sites your server will give you a cookie that will
behave as an id that wants to store information such as, a name, a coded number, domain name of site, activities, ip
address, login information, etc. Every time you revisit a site the cookie will send a message to the browser that your
id is back and it will remind it of your activities, preferences, and other personal data. Cookies are generally used to
make a website more personal and browsing more convenient, but they can have many drawbacks.
Though, cookies aren’t a direct threat and don’t transmit malware, they can be dangerous or a threat to privacy in the
way that they are used in the real world. Cookie profiling is when multiple tracking cookies are used to track your
overall activities online, ip addresses, locations, authentication information, and more. Data like these can be used in
practices for third-party, first-party, session, persistent, and secure cookies. Third-party advertisers take cookies
from users while they are exploring other sites, and use the data they get to target advertise. First-party cookies are
generally used for personalizing a website to the user. Session cookies are stored temporarily and are used to allow
websites to link user activities during the browser session. Persistent cookies are given an expiration date by the
website creator, and are usually given that to remember a user for some time. Lastly, secure cookies are only
transferred using https, thus the information in the cookie is encrypted when passing between a site and the browser.
Secure cookies are usually found in online checkout pages. Though, the use of cookies isn’t always harmful, it can
be when they are taken without consent by a third-party or a hacker.
A major threat to a user is the ability for an attacker to steal their cookies, which could contain authentication
information. Cookie stealing or session hijacking, is when an attacker is able to log into a site that is protected with a
user’s authentication information, by stealing their session data in real-time. There are many different ways to steal
cookies such as, cross scripting attacks or xss attacks, viruses hidden in harmless software, or using tools over a
local lan. With a packet sniffing tool, an attacker can detect and copy cookies that are unencrypted, making it
extremely simple for an attacker to hijack the user’s session. Man-in-the-middle and dns based attacks are when the
attackers redirects the user’s traffic to the computer system the hacker controls, and once connected, the attacker can
see all the user’s unencrypted data. Cross-scripting is another popular way to steal cookies. Cross scripting works by
embedding php scripts into webpages. Even though, there are security controls for these types of attacks, many
websites are still vulnerable to them. One way they may do this is by simply linking the web resources that has their
script to a post or script code. When the script is executed on the user’s browser, it will send copies of active cookies
to another web browser or other resource. If an attacker is successful in stealing a user’s cookie, especially one with
sensitive authentication or credit card information, the user may be vulnerable to multiple threats of their web
browsing accounts and their system.
Methodology
The first step to accessing the website was to find the IP address of the website itself. We are able to see this easily,
since we are the webmasters hosting the site on a local machine. In the Linux command line, enter the command ip
addr to see the IP address and other network data. In a professional setting, an attacker could just enter the website’s
URL into a browser like a regular visitor.

In this instance, we see that the IP address used for the site is 192.168.72.64. By switching over to the Windows
VM, and opening up a browser, we can type in the IP address and land on the index page.
9

Here, we typed 192.168.72.64 into the Chrome browser on the Windows VM, and are able to access the website.
By navigating to the products page, we are given access to a search bar. Here, we can experiment with different
queries to see how queries are processed on the back end, and glean information about the file structure. An attacker
that makes it to this page would attempt multiple search queries to see how inputs are sanitized, and what DBMS, if
any, is used. For example, if an attacker learned that a web admin didn’t properly sanitize the search bar’s input,
they could fake the terminator characters and add malicious script. For this exercise, the search bar feeds directly
into the apache server’s command lines. By simply adding a semicolon, we are able to enter Linux commands
directly into the command line, and see the results on the search results page.

The search script read the “;” as the end of the command, and proceeded to the next command. If this was a typical
search query, the results would have been displayed right above the injection site. Instead of using the echo
command to simply print text to the injection site, I can use a variety of linux commands to open different
directories and view different files. Malicious actors can use similar techniques to gain access to sensitive
information, such as username/hashed password combinations, customer data, credit card information, and more.
For this specific example, we can use linux commands to have the PointHere/points.htm file appear at the injection
site.
11

In this pair of screenshots, we use the cat command to print the PointsHere page to the results page. We are using
linux commands, which suggests that the website is run in a Linux environment. Since we are also the web admins
running the entire site on a local machine, we can confirm this. An attacker would probably attempt several queries
to understand exactly how inputs are sanitized and what kind of environment the server is run on.

Viewing the source code can be a valuable tool for anyone hoping to gain information about how a website is
structured. We wanted to find some information on how process.php was set up, and came across this message.
Next, we took a look into Cross-site sripting attacks and cookie stealing. In the beginning of this exercise, we
decided to change the document root address of our apache2 web server to reflect this exercise. Prior to this change
the apache2 document root was calling a destination to var/www/html file. We decided to change this document
room to just call the “var/www” directory so that when on the web interface side when we typed in the IP address of
our Linux machine, the apache2 web server would display the index of that destination. For the purpose of this
exercise the files within the var/www directory are what we wish to have access to. By displaying this index we
were now able to navigate through the directory. Moving back over to the Linux machine we are now able to edit
several files within the directories that we have now discovered on the web server side to match the structure on the
back end though Linux. By editing several .htm files we were able to test the stealing of a cookie with the .php
scripts provided. When opening the “setgetcookies.htm” file you are brought to a webpage (locally) that will
emulate “setting a cookie” by entering your name in and setting the cookie. By navigating back to the MalURL.htm
file which we edited to redirect to a redirect to a specific destination. A user clicking the links provided in this
webpage that we have edited to redirect to a page that a .php script will steal a user’s session cookie. By clicking the
second link after a user has “logged in” will allow you to use the same session as the victim, showing you as the user
in the address bar after username. The text entered as the “cookie” is shown in this example as the name you entered
for the cookie. In a real-world environment the attacker would create his/her own .php scripts to accomplish the
same task with more steps because the system directory you would be attacking would be unknown to the attacker.
The second part of this assignment is to emulate how a user can ask the system for more information when it should
not be given. Poorly created web pages with no security parameters to prevent cross-scripting can potentially be
catastrophic to the organization or client hosting the site. In this exercise we navigated back to the index where
“Script-attacks” directory is and are able to see that there are several files here. Without knowing the directory
structure, a user would click through the webpage to find a section where user input is allowed. Although we know
how the directory structure is organized in a real-world scenario you would not know this information. Once the user
finds a location on the web page where user input is allowed, the user can then enter content to retrieve information
not intended for the end-user. In this example we are presented with a sample.htm file to help illustrate this type of
attack. The web page does have text box with the ability for user input. The sample web page asks the user to enter
“roses, or lilies” to retrieve information about lilies or roses. The problem with this webpage is that if a user enters
“roses” but after roses includes a semicolon the back end will see this as a reasonable request for more information.
By adding “ls” after “roses” we are able to tell the system to display the information it has on roses and also list out
the directories where the ‘roses’ file is contained. When we do this task we are given the information about roses but
13

also we are now given a list of directories as well. Now we are able to see that there is a directory named
“confidential”. As a attacker we now know that the system is compromised by being able to display a list of
directories but more importantly now we know there is a directory that contains potentially “confidential”
information. We can now perform the same task asking to list the contents of the confidential directory. We now are
able to visually see that a file exists named “bankInfo” within the confidential directory. Knowing all of this
information now we are able to tell the system to return information about roses but also return the information
about “bankInfo”. This is a serious vulnerability on this web page as a user now has access to the bank information.
If this were a real-world web page that an individual has designed, then all of its client-information has been leaked.
Cookie Stealing
Next, we took a look into Cross-site sripting attacks and cookie stealing. In the beginning of this exercise, we
decided to change the document root address of our apache2 web server to reflect this exercise. Prior to this change
the apache2 document root was calling a destination to var/www/html file. We decided to change this document
room to just call the “var/www” directory so that when on the web interface side when we typed in the IP address of
our Linux machine, the apache2 web server would display the index of that destination. For the purpose of this
exercise the files within the var/www directory are what we wish to have access to. By displaying this index, we
were now able to navigate through the directory.
Moving back over to the Linux machine, we are now able to edit several files within the directories that we have
now discovered on the web server side to match the structure on the back end though Linux. By editing several .htm
files we were able to test the stealing of a cookie with the .php scripts provided. When opening the
“setgetcookies.htm” file you are brought to a webpage (locally) that will emulate “setting a cookie” by entering your
name in and setting the cookie. By navigating back to the MalURL.htm file which we edited to redirect to a redirect
to a specific destination. A user clicking the links provided in this webpage that we have edited to redirect to a page
that a .php script will steal a user’s session cookie. By clicking the second link after a user has “logged in” will
allow you to use the same session as the victim, showing you as the user in the address bar after username. The text
entered as the “cookie” is shown in this example as the name you entered for the cookie. In a real-world
environment the attacker would create his/her own .php scripts to accomplish the same task with more steps because
the system directory you would be attacking would be unknown to the attacker.
XSS attack
The second part of this exercise is to emulate how a user can ask the system for more information when it should not
be given. Poorly created web pages with no security parameters to prevent cross-scripting can potentially be
catastrophic to the organization or client hosting the site. In this exercise we navigated back to the index where
“Script-attacks” directory is and are able to see that there are several files here. Without knowing the directory
structure, a user would click through the webpage to find a section where user input is allowed. Although we know
how the directory structure is organized in a real-world scenario you would not know this information. Once the user
finds a location on the web page where user input is allowed, the user can then enter content to retrieve information
not intended for the end-user.
In this example we are presented with a sample.htm file to help illustrate this type of attack. The web page does have
text box with the ability for user input. The sample web page asks the user to enter “roses, or lilies” to retrieve
information about lilies or roses. The problem with this webpage is that if a user enters “roses” but after roses
includes a semicolon the back end will see this as a reasonable request for more information. By adding “ls” after
“roses” we are able to tell the system to display the information it has on roses and also list out the directories where
the ‘roses’ file is contained. When we do this task we are given the information about roses but also we are now
given a list of directories as well. Now we are able to see that there is a directory named “confidential”.
As an attacker we now know that the system is compromised by being able to display a list of directories but more
importantly now we know there is a directory that contains potentially “confidential” information. We can now
perform the same task asking to list the contents of the confidential directory. We now are able to visually see that a
file exists named “bankInfo” within the confidential directory. Knowing all of this information now we are able to

tell the system to return information about roses but also return the information about “bankInfo”. This is a serious
vulnerability on this web page as a user now has access to the bank information. If this were a real-world web page
that an individual has designed, then all of its client-information has been leaked.
Results and Suggested Remedies
Through the use of command line into the search query, we were able to access the Linux terminal on the website
and gain access to the back-end files, something that the web page user should not have access to. Fortunately, there
are ways you can remedy this vulnerability in a website.
The biggest remedy that we found was to this issue to have user input be validated - to have the search query allow
certain characters to be valid. In addition, having the search query neutralizing met characters is another excellent
remedy. In the case for the website we experimented on, if the search query was set to neutralize the special meaning
of the semicolon (in respect to its meaning for Linux terminals), then the search query vulnerability would be
resolved.
Data validation also extends to cookies and html on websites. According to the OWASP’s page on XSS, you can use
HTML variables to validate the inputted data before actually executing it. This serves an easy way to check and
make sure anything that is being entered by a user is valid data, as the user input is put into a variable and compared
to what is accepted. If it’s acceptable, then execute the user input; if not, then throw the code out.
Lesson Learned & Implications
While this was an experiment on a virtual machine – meaning it didn’t have any real impact on anyone in the real
world – this experiment prove to show just how easy it is for a hacker to breach security, as all they have to do is
find the tiniest flaw in it and they will exploit it. This lesson is something very important and something we need to
take note of when setting up our own web servers and web pages.
In addition, our research taught us another very important lesson, to test our web servers ourselves before releasing
anything into the public. Regardless of how many security measures there are, it doesn’t mean nothing if you don’t
actually test your website and check to make sure the security measures are working properly before releasing I out
to the public.
Conclusion
The level of insecurity that the experiment’s web server have is unacceptable but, web page insecurity of that level
isn’t uncommon to find in the real world with people not heeding the importance of security. As shown in the
experiment, it doesn’t take too much effort to breach the security of such web pages and servers, as using code
injection can do the job quite easily and quickly; and even then, it isn’t something difficult to prevent, as simply
using both user input validation and neutralizing met characters would’ve easily have prevented the security breach
in the search query.
This experiment and research gave us a look into the method of a hacker, the types of hacking strategies a hacker
may use, and a hands on experience of just how easy it was to hack into our own web servers that we set up. Going
forward, it is important for us to take this experience to heart and to make sure to thoroughly test the security of our
websites and servers before we release them to the public; to find any security vulnerabilities in them before an
unintended user does.
Acknowledgements
We thank all group members of Cyber Eagle for their diligent, tireless efforts in the compilation of this article. Our
sincerest gratitude is also greatly expressed to those who contributed to the sources referenced. Without the research
of our predecessors we would be that much further behind.
15

References
Brady, P. (2017). Survive The Deep End: PHP Security¶. Retrieved October 4, 2018, from
https://phpsecurity.readthedocs.io/en/latest/index.html
Clarke, J. (2012). SQL Injection Attacks and Defense (Vol. 2nd ed). Waltham, Mass: Syngress. Retrieved from
https://login.proxy.lib.fsu.edu/login?url=http://search.ebscohost.com/login.aspx?direct=true&db=nlebk&AN=4
90339&site=eds-live
Ho, S. M. (2018). LIS4774 Information Security. Boston, MA: Pearson Learning Solution.
Injection Attacks. (n.d.). Retrieved from
https://phpsecurity.readthedocs.io/en/latest/Injection-Attacks.html#path-traversal-also-directory-traversal
J. (2018, January 08). How To Prevent Command Injection. Retrieved from
https://affinity-it-security.com/how-to-prevent-command-injection/
Kar, D., Panigrahi, S., & Sundararajan, S. (2016). SQLiDDS: SQL injection detection using document similarity
measure. Journal of Computer Security, 24(4), 507–539. https://doi.org/10.3233/JCS-160554
Makan, K. (2014). Penetration Testing with the Bash Shell. Birmingham, UK: Packt Publishing. Retrieved from
83562&site=eds-live
Pauli, J. J. (2013). The Basics of Web Hacking : Tools and Techniques to Attack the Web. Amsterdam: Syngress.
Retrieved from
73954&site=eds-live
SQL Injection Cheat Sheet & Tutorial: Vulnerabilities & How to Prevent SQL Injection Attacks. (2018, September
14). Retrieved from https://www.veracode.com/security/sql-injection

Lis4774.term paper part_a.cyber_eagles

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Lis4774.term paper part_a.cyber_eagles

Similar to Lis4774.term paper part_a.cyber_eagles (20)

More from AlexisHarvey8

More from AlexisHarvey8 (6)

Recently uploaded

Recently uploaded (20)

Lis4774.term paper part_a.cyber_eagles