Abstract - · PDF fileEach of the tasks do not have anyone one solution nor does ... values to inject malicious SQL code or ... Berkeley Lab’s Cyber Security

Open Source Vulnerabilities in a Virtual Environment

1 Florida State University iSchool

THE ULTIMATE COVER UP: PLUGGING THE HOLES IN

SQL INJECTION AND XSS

Michael Kimball Matthew Shearer Bernard Hudgins Florida State University Florida State University Florida State University

[email protected] [email protected] [email protected]

Bradley Prior Andrew Anderson Patrick Burke

Florida State University Florida State University Florida State University

[email protected] [email protected] [email protected]

Abstract The purpose of this research paper is to extrapolate potential security flaws within a basic Linux based web server

in a controlled virtual environment, and analyze the potential dangers of the lack of security in a real world setting. A hacking exercise was attempted, to exploit server vulnerabilities in a Linux variant operating system and scripts

enabled by the PHP open source scripting language. Apache and PHP files were used in the formation of a dummy

website on the server, which needed a degree of security measures to eliminate the risk of remote users executing

scripts as shell commands. For this research project the website was hosted on this virtual server, and then injected

with shell commands in a text field, which allowed for the manipulation of the server side scripting. This

demonstrated the potential, veritable flaws within the security features that could be found within a web server. In

addition to finding to determining flaws in a basic server setup, an exercise in cross site server was also attempted,

which exploited vulnerabilities on the host end of a web client to host interaction. In this exercise, a server was set

up to host a dummy web page with parameters to accept input from a user to establish a session, and is then

directed to another site that proceeds to steal the cookie established by the user. This demonstrates that securing a

web server requires defensive measures both on the server end, and also on the user end. The results of these

experiments were documented, and then analyzed to show how the vulnerabilities within this test environment can

also exist in a real world setting, and the implications that this has for server security on both the client and host

side. Keywords: Apache, PHP, Open Source, Linux, Scripting, Server Vulnerability, Injection,

Security

Introduction In today’s society there has been a boom in the security industry for security professionals to take up the digital

shield and defend against online hackers who seek to take advantage of systems and users for their own malicious

ends. For the purpose of our research endeavor a group of Information Technology students were given two tasks,

the first to hack a server using scripts to take advantage of vulnerabilities on the server side of a system. The second

task hacks a web application from the client’s side of a system taking advantage of user input. All of the actions

taken to test the security were documented and evaluated for their potential application in a real world setting. These

two tasks represent the general notions of how an attack may occur, the first task aimed towards the server, the

second task aimed toward the user. Each of the tasks do not have anyone one solution nor does the problem exist in

any one state. The problems and solutions discussed in this paper are aimed for educating and informing possible

real world occurrences, while demonstrating a controlled demo of simulated attacks.

This paper is for educational purposes only and demonstrates technical actions that may be regarded as illegal and

have serious consequences outside of the controlled environment. It is critical to evaluate web security in the digital

age to ensure protection against attacks that have become commonplace in the real world. The paper is an attempt at

replicating these attacks so that defenses can be built and refined in the future. The first step in the group’s first

project was to gain access to Florida State University’s College of Communication and Information’s course

mailto:[email protected]








website: labs.cci.fsu.edu in order to access Dr. Ho’s folder which contains a remote desktop app. The remote

desktop app allows for the use of virtualized servers, which is the environment that this scenario was executed in. During this experiment on security vulnerabilities, Apache, PHP, and MySQL were used to set up the target web

server, with no other functionalities in order to preserve the sterility of the testing environment. Referred to as

LAMP, (Linux server with Apache, MySQL, PHP) this environment is extremely popular in a real world setting.

This allows us to make inferences on how the security standards for the test web server can handle real threats. Some of the limitations of this research paper are in its limited scope: the environment is only conducive to open

sourced software. Throughout this research paper the scope of this experiment will be elaborated on, and then

analyzed to provide context on the nature of these vulnerabilities through other referenced research papers.

Literature Review Sanitizing Inputs Defending against Buffer Overflow Vulnerabilities is from the Nanyang Technological University in Singapore and

explains techniques on how to patch buffer overflow vulnerabilities (Padmanabhuni and Tan, 2011). They discuss

how most web applications are written in the C language. The C language writes Linux’s operating system. If the

memory is not allocated correctly the attacker can exploit this weakness and inject malicious code. They explain

methods in prevention such as sanitizing data and making sure that the memory is allocated correctly. Stanford University’s study on the subject of vulnerabilities called Static Detection of Security Vulnerabilities in

Scripting Languages by Vichen Xie and Alex Aiken, provides background on potential flaws with server security

(Xie, 2006). Personal Home Page: Hypertext Processor, commonly known as PHP, is a server side scripting

language that is currently running on the virtual server for our research. PHP is a Perl-based language, and its

vulnerabilities are based on some of the security flaws of its origins. One of the most common forms of security

vulnerabilities is ‘SQL injections’ which occurs when PHP is used in conjunction with Sequel, a relational database

language that is used to store data. Variable values in PHP are not bound in the same way that they are in Java,

allowing for users to manipulate the variable values to inject malicious SQL code or circumvent insertion

limitations. In addition to PHPs vulnerabilities with SQL, the unused variables within PHP’s code are left as null

when not used. This can cause serious problems, as posited by the Stanford research paper.

Securing Servers University of California-Berkeley Lab’s Cyber Security department explains how to properly secure an Apache

server, where they discuss the details of proper server configuration. Apache is the most frequently used Web

server, and while it is true that it is more secure than most available web servers it is far from being completely

secure. A common issue with many Apache web servers is not with the server software itself, but with the way it is

setup, which can leave it vulnerable and open to attack; much like the activity done for this project.

The article from the International Journal of Advanced Research in Computer Science gives a thorough breakdown

of the multitude of virtual environments that exist, and potential vulnerabilities. Virtualization allows for the

optimization of resources within a particular organization. There are different types of virtualization that include

desktop, network, server, application, and storage virtualization. There is a convenience in allowing VMs to connect

to other VMs or directly to the host. An obvious vulnerability to this is the access to host resources and file systems.

This can lead to an exhaustion of virtual and host resources or serve as a gateway for harmful programs. Good

isolation methods ensure that these machines do not have a cascading effect to the others as well as the host. Careful

configuration must be administered when isolating virtual environments to prevent VM (virtual machine) take-over

and access to the underlying host. Configuration is key to a fully functioning and fully secure VM environment

where denial of service attacks are rendered ineffective through the proper allocation of resources, disallowing any

guest to drain resources from other virtual machines (Kanth, 2013).

Web Server Vulnerabilities and a Defense in Depth Strategy Using the Squid Proxy (2004) by Brewer, is about a

security strategy for a web server that includes using a proxy. This paper covers many types of vulnerabilities,



namely Invalidated Input, Parameter Tampering, Cookie Poisoning, Cross Site Scripting, SQL Injection, Improper

Error Handling, Insecure Storage and Denial of Service. Then it talks about Squid and what it does, most of its

features, and why it’s important. Then it talks about building a network and what components to use that work with

Squid and overall recommendations. As it teaches you how to setup your server with the proxy, it notifies you when

you plug holes and protects against vulnerabilities.

Secure Technologies In "The Tragedy of the Cybercommons: Overcoming Fundamental Vulnerabilities to Critical Infrastructures in a

Networked World", Emily Fyre states how "Computers power the economy...The economy operates because of the

functionality that computers provide; computer should be viewed as a critical infrastructure"(Fyre, 2002). Because

of this, servers need to be protected at the highest level. Systems were originally designed for trusted individuals,

however nowadays users require more access to the Internet, increasing potential security risks. When the

communication mechanism TCP/IP was introduced, Fyre states how it "was not designed for security; it was

designed for usability...TCP/IP made sense because the user base still was presumed to consist of trusted

participants" (Fyre, 2002). While this is no longer the case, TCP/IP still is not inherently designed with security in

mind, and security is not native to its core.

In Sharon D. Nelson's and John W. Simek's "Data Breaches: Damage Control after the Dam Bursts", they look into

these matters and inform the reader on how "The Ponemon Institute reported in February 2007 that only 18 percent

of companies routinely encrypt their data, despite the fact that 61 percent of executives and IT managers believe it is

important to do so"(Nelson - Simek, 56). That was a mere seven years ago, a time where smartphones had begun to

become the standard in communication for the general population, a time where technology was looking quite

advanced, but was not being protected well enough. Nelson and Simek go on to state how data breaches are

extremely hard to bounce back from, and that prevention works immensely better than a cure or damage control. Their words "Security is cheap- data breaches are not"(57), stands quite true, as there are a number of encryption

software options available which can be applied to servers, as well as the standards of Triple-DES and RSA. Also,

by providing clear administrative and user limitations, as well as eliminating back doors in the network, servers

become more secure. Not allowing a low-level user to install programs on a computer connected to a server could

prevent them from loading a key logger and releasing sensitive information. Although servers will never be

complete secure, with active maintenance and management to security, the risk can be significantly dropped.

Cross Site Scripting Cross Site Scripting (XSS) takes advantage of web applications by injecting attacking scripts into the web

application after which they execute with the privileges of the current web site on browsers. This type of attack as

explained by Helen Wang in Attacks Target Web Server Logic and Prey on XCS Weaknesses, has been plaguing

Web application vulnerability for a long period of time. Cross Channel Scripting (XCS) however is a more

sophisticated form of XSS attacks according to The Emergence of Cross Channel Scripting by Hristo Bojinov, Elie

Bursztein, and Dan Boneh. XCS is when attack injection and execution are carried out via different protocols,

typically these attacks use non-web channels such as File Transfer Protocol (FTP) or Simple Network Management

Protocol (SNMP) to inject a persistent XSS exploit into web content that runs in a different security context. These

attacks aim to carry out a variety attacks that include gaining sensitive data, redirecting the user to a malicious site,

or exploiting the user IP to setup a DDoS attack. The attacker’s targets are prevalently consumer electronics such as

digital photo frames, wireless routers, and network attached storage appliances (Bojinov, Bursztein, Boneh, 2010). Since XCS attacks are very similar to XSS attacks, they also can be prevented in a similar manner, according to the

Stanford University team. They recommend, as we will later in this paper, that one of the best defenses against any

injection attack is the sanitization of all code and the user’s web browser.

The article Exploitation of Cross-Site Scripting (XSS) Vulnerability on Real World Web Applications and its Defense

explains how hackers attack web application using HTML and JavaScript to perform Cross-Site Scripting attacks. This article goes into detail about vulnerabilities that are being exploited by the attackers to steal web browser’s



resources (cookies, credentials, etc.) by injecting malicious JavaScript code into the victim’s web applications. The

hackers exploit these vulnerabilities by changing the client side, where they can collect the users’ information. The

authors talk about how to fix these vulnerabilities using a sandbox environment to test the web applications.

Cross-site scripting attacks are one of the most common ways hackers try to gain unauthorized access. When a user

is logged in on a website the server creates a cookie to store the state of each user. Cookies are hashed private keys

that cannot be forged and whenever the user makes a request the server compares the cookies received through the

user’s browser for authentication purposes. If the cookies do not match the session between the user and website

will be disconnected. Cross-site scripting attacks occur when there are flaws in the server-side web applications

(Zuchlinski, 2003). Hackers can steal cookies through linking malicious script code that the user cannot see to

textboxes that are not sanitized for HTML characters. The hacker can then insert arbitrary HTML then they would

be able change the execution of the page through the permissions on the site (Zuchlinski, 2003). The page will be

redirected to another location of memory in the shell code where the attacker has full control of the program

(Zuchlinski, 2003). The GET method is placed on the rendered page so when user enters their username and

password and is unaware that someone has stolen their cookie now has access. For example there are online banking

account which the hacker later could perform a masquerade attack to steal money or other important information

without having to use the victim’s password. Attacks can also use JavaScript code to redirect a page as well

(Zuchlinski, 2003).

In the article C and C++: Vulnerabilities, Exploits and Countermeasures the author writes about how C is a function

oriented programming language created in the early 1970’s by Bell labs. It is an influential computer language and

many later languages such as Perl and PHP borrowed code in their creation. Linux is also written in C, which

provides certain vulnerabilities in the foundation of Linux. Because other languages have used C as a base for their

creation, they display vulnerabilities as well. One such vulnerability is memory. The programmer must control

memory allocation and relocation. There are three methods of memory allocation: dynamic and static. The compiler

for C does not detect errors in memory allocation, which can be problematic for Linux. For example, when writing

the bounds of the allocated memory, a hacker can recognizes error and override memory locations inhibiting the

system so an attack may be performed.

The C language greatest vulnerability is buffer overflow. Buffer overflow occurs when a program is writing to a

buffer. Data overruns the buffer’s boundary and begins to overwrite other memory (Younan, 2013). This corruption

causes the program run slow or become unresponsive. C also is inefficient at identifying strings. An array is a string

of characters. Programmers must be aware of the limitations of the strings and fix them. In Linux, once a hacker is

aware of the strings, he or she must perform a SQL injection. A SQL injection occurs when the attacker can insert

malicious code to a field therefore altering or dumping database memory to the hacker.

Cookie Authorization Protocols

Cookies on computers are not the sweet smelling treat most people think they might be. According to Microsoft,

“Cookies are small files that websites put onto your hard drive when you first visit.” (Microsoft 2014) Cookies are

unique identifiers that help websites customize themselves for the viewer. Cookies in both terms are great, but they

can be manipulated to gain access to restricted data. Cookie authorization protocols were created so that hackers

when hackers manipulate the cookie, the website will not read it.

In a paper written by three students at Michigan State University wrote about cookie authorization protocols and

how they need to provide certain services. These services are: Authentication, Confidentiality, Integrity, and Anti

Replay. These students created, tested, and implemented their own cookie authorization protocol named “Fu’s



cookie protocol.” After, they discussed the results of the “Fu cookie protocol” and compared it to other functioning

protocols.

Authentication is key in the cookie authorization protocol process. It has to be known to the server that the cookie its

reading was written by the website and not something foreign. They first say that cookie authorization starts at

authenticating the client by the server. In a secure web application, this is easily accomplished with the use of two

phases, the login phase and the subsequent-requests phase. In the login phase, there is a mutual authentication

process between the server and client. The client double-checks the URL and the site layout to make sure that the

website that he is attempting to gain access to be the correct website and not a copy. Then the client inputs his

credentials, which can include a username, and a password to unlock the username’s data. After logging in, the

server sends a cookie to the client’s hard drive, which is also called an authentication token, or authenticator. Because the cookie is sent, and the server accepted the credentials, the client will be able to access all of the user’s

data because of the authenticator. A good cookie authorization protocol will be clear to the client and efficient and

secure for the server.

Confidentiality is important for cookies, because nothing other than the specific website should be able to read its

own particular cookies. If anyone can read and understand the cookies, the server’s data would be very vulnerable.

In this paper, they discuss two types of confidentiality, High-level and Low-level. The difference between High and

Low levels of confidentiality according to the authors are that Low-level cookies can be read by both the client and

the server. High-level cookies are to be read by the server only. With that being said, all cookies sent to a client’s

computer are encrypted for protection. Amazon and Google to help them know which ads or products to advertise

would use Low Level cookies. High Level Cookies could be username and password data, or possibly credit scores,

or bank account information. A good cookie authorization protocol should be able to support both high and low

levels of confidentiality configurations.

Integrity and Anti Replay, although very important, do not have many attributes. Integrity is simply being able to

determine if something has been modified or manipulated. In this case, the server should be able to determine

whether or not the cookie last sent to the hard drive has been modified by any way by any third party applications.

Also, the server should be able to determine when a cookie expires. This is a Anti Replay service, not letting the

next client on possibly the same hard drive access the first user’s data. This makes sure that the second user cannot

use the same cookie to gain access to the server’s data. Therefore, a good cookie authorization protocol is be able to

identify if the cookie has been modified, or if it being reused.

In Fu’s Cookie Authorization Protocol, the cookie issued to each hard drive consists of 4 sub fields. These subfields

are: User Name, Expiration Time, Data, and a Keyed-Hash Message Authentication Code (HMAC). The user name

is a primary key, a unique identifier between the client and the server. The expiration time is a set time, expressed as

seconds past 1970 GMT, shows when the server should deny the cookie. The data placed in the cookie is any

information that the server wants to store on the clients hard drive. For example, this could be what items are in your

shopping cart when shopping online at Macy’s. The Keyed-Hash Message Authentication Code has a particular

value given the above data and the server’s individual key.

The first problem they encounter is with Cookie Confidentiality. Fu’s cookie authorization protocol does not

account for this. A solution would be to use the server key to keep it secures, but if you gather enough cookies,

using software and mathematical analytics, you would be able to decode the server key. You could generate a

random key for each cookie, but then it would overload the database, and when one cookie with the encryption key

is deleted, every cookie with that key would be disabled. They decide to use the HMAC as the encryption key. With

this, it is a new encryption key every time because of the new expiration time. It keeps the server key secure. It does

not require any more data storage as it is create dynamically.



The next problem is Replay Attacks. An attacker would first steal a cookie from an authorized user. Then they use

the cookie in a SSL connection with the server. Their solution is to add the SSL session key into the HMAC, this

would make each session unique and unable to be reused. The cookie would be specifically made for the current

session and the current session only. Each new session would have a new key. Therefore you cannot reuse the

cookie. You couldn’t change the session key in the cookie because it is implanted into the hashed code.

The final problem is Volume attacks. A volume attack against this server would be first collecting many cookies

using the same key, and discovering the key. One inefficient solution could be changing the server key periodically.

But using multiple keys to identify code is obviously inefficient. They plan to use the encryption key, the HMAC.

This changes every time, is unable to be forged, and it doubles as the encryption. It’s like picking an impenetrable

lock, and each time you take a break, or if you take too long, the lock changes and you start from scratch.

After testing their new cookie authorization protocol from Fu’s cookie protocol, it surpasses the original in every

stage. Each problem that the old protocol faced, the new one fixed. They were very close to efficiency but the new

protocol surpassed the old one in security. In conclusion, the basics of the cookie authorization protocols and what

they are made to do can be useful in updating and creating a new and improved protocol.

Discussion

Term-A Lab Exercise

Computing Environment

The computer environment installed on our virtual machines is called LAMP (Linux, Apache, MySQL, and PHP).

LAMP is a stacked open source software packet that is installed on half the servers in the world. We have Ubuntu

12.04 installed on our virtual machines, which is a version of Linux. We are using Apache 2.2 which is an open web

server application used to create websites. MySQL is a relational database management system used to create and

store databases. Lastly, PHP is a server-side scripting language, which is used in web development. This language

helps store data from the web pages to the MySQL database. The reason this environment was used for this project

is due to how widespread it is used on web servers around the world, which is important when making inferences to

the effect that the vulnerabilities within a LAMP stacked software can have in the real world.

Methodology

The research project required us to first access the required website “extremeinsecure.” The website represented a

mock business that developed and sold vulnerable software that could be easily accessed by hackers. The next step

was to setup permissions to the files to enable it to read, write, and execute as needed. The permissions instructed

were a 604 setting for files, and 705 for directories. In UNIX when setting permissions the proper setting is an

important factor to creating a secure environment.

These settings both yielded different results; a 604 would give the user permissions to read and write and others

permission to read only, no group permissions were set. A 705 yielded that a user has all permissions (read, write,

and execute) while others had both read and execute access, still not setting any group permissions. Another

important permission that needed to be set up was for the file process.php, it had to be given execute rights for

others, in other words invoking a chmod o+x command for the file. The reason behind this is if one wanted to access

the page that required process.php to run, one wouldn’t have access to it and that would make the website poorly

designed since users wouldn’t be able to access a normal function of the website. After placing the files in their correct location and setting their proper permissions, accessing the site was the next

step. After browsing the site searching for vulnerabilities, the products page is where the main vulnerability was



located. Process.php is what runs the search function and it is the main flaw in the server’s security. However

because of the vulnerabilities you are able to inject shell commands by starting out with a | or; then typing any

normal UNIX command. Some of the commands that we used to complete the project were “ls” and “cat.” “ls”

helped us get read what files were in the directory we were in. The “cat” command helped us open or run the files in

the directory. With this information, some of us were able to run some files to find some extra credit for the

assignment. Following the instructions that came after this discovery and injecting some shell commands, it led to

the end of the project.

Figure 1. All of the files in the directory that hosts the ‘extremeinsecure’ website on the server.

Results

The website was launched using Apache2, then using Mozilla from the remote desktop to navigate the page. The

page functioned normally and no vulnerabilities were apparent from the surface. Due to lax parameters and file

permissions within the products and process files, shell commands could be executed through a text entry on the

web page. Process.php does not filter any text entered into products.htm. This allows users to execute shell

commands, or scripts, through the text entry gaining access rights that should not be available. Viewing the page

source or running a cat command on process.php will give further information regarding server-side scripting. Ultimately this vulnerability allows users to explore file systems, possibly gaining access to critical files and

information that should not be readily available.

One of the vulnerabilities discovered during the hacking exercise is cross-site scripting. Cross Site Scripting, known

as XSS, can happen because of invalidated input. It is when a web application takes untrusted data and sends it to a

web browser without proper Validation. Attackers can use this to direct traffic from safe sites by means of

hyperlinks to the attackers cite, which could try to implant viruses or steal data from the user. The attacker can trick

the user into inputting his data into the website. For example, if you misspell popular social media website

“Facebook”, and put “faecbook” it will send you to a website that offers you a prize for filling out your information.

SQL injections are put in where you input data, such as a username and password. Then it will be able to read your

data, and possibly insert, update, or delete data. It could even go as far as shutting down the DBMS, recover other



files, or send commands to the OS. SQL injections are dangerous because they spoof identity, tamper with data, and

create many issues.

Figure 2. The process.php file acts as a simulated vulnerability for the web server.

Proper Error Handling is important because you don’t want to give the attack more information than you have to. The less the attack knows about your database, tables, and other important information, the harder it is for the

attacker to gain access to your information. When error messages are sent, usually it will give a reason for the error. In the past, when you enter your username and password and incorrectly type your password, it would give you a

message that your password was incorrect. If you incorrectly put in your username and your typo didn’t result in a

name of another user, it would tell you that the database could not find your username. Now when you put an

incorrect username or password, it will not tell you if your username or password or both were wrong. It only tells

you that you have an incorrect combination. This way, the attacker doesn’t know if the database even has that

unique username.

Insecure storage is when the way sources hold their storage, data, and databases are not secure. This could be

because they don’t encrypt critical data, secure keys, passwords, or certificates, randomness, poor algorithms, or no

support for encryption keys or regular server maintenance.

DoS attacks are any attacks that attempt to make a specific resource, a site, application, or server, to be unavailable.

This can be by manipulating network packets, programming, and many other ways. If successful, the attack though

these DoS attack can access critical information and command the operating system. This can be huge for

businesses that need to be up all day every day. If someone can flood the site and bring it down, or get inside the

server, they can do a lot of damage deleting files or stealing them.



In our initial exercise Term-A we created a server-side scripting vulnerability. Anything entered into the text box

will also be executed as a shell command. This is using invalidated data, because this website that we created was

using code that wasn’t properly validated. This is also very similar to SQL injections as it works the same way. This

vulnerability takes what is inputted and issues a Linux command. SQL injections do the same thing, except using

Linux commands it issues a SQL command. All of these attacks and this exploited vulnerability that we created on

our servers are all about the same thing. They are about stealing secure data. There are many different

vulnerabilities that can be easily exploited in servers. Using this specific proxy server, you can make a rule that

protects about injecting SQL into the website. Also it would protect against attaching Linux commands to the input

box.

Figure 3. products.htm represents the potential resources that would

be accessible due to the vulnerabilities on the server.

Term-B Lab Exercise

For the lab part of this project, we were instructed on how to carry out a Cross-Site Scripting (XSS) attack. These

types of attacks are often used on web applications and involve injecting code into the client-side of the program. In

our XSS attack, we change the redirection link in the html files of an extremely insecure website. By changing the

link to the local address, this allows us to input our own test information instead of having it input remotely. Our

objective in performing this attack is to steal the cookies of the client. Cookies are authenticators that are sent by the

server and stored on the client side. The client is not able to create or forge the cookie on his or her own. By using a

XSS attack, we are able to steal the cookies by injecting our script into the webpage, which the victim has accessed.

We use the victim’s browser request to call for the cookies from the server. After the request is received, the server

sends the cookie. Our code is then interpreted as JavaScript by the victim’s browser, and runs a method with steals

the cookie.



Computing Environment

The same computing environment was used in this part of the exercise as the first part, we used our virtual machines

loaded with LAMP that ran and hosted our web server. The browser used to locally input our test information was

Mozilla Firefox. By using the virtual Linux machine, we are assured that are computing environment is stable

because it uses very little resources and only does what you give it commands to do. Another dimension added to

our computing environment is that of HTML and JavaScript, via the .htm and .php files, be it by our own script or

that which was already provided.

Methodology

Within our virtual Linux machine, we used terminal commands to download, un-archive, edit, and run the files

needed. We began the project by downloading a zipped folder, titled ‘webhacking.zip’. Not only did this folder

contain the necessary files to retrieve the cookies, but also provided the actual website to carry out the attack on. After downloading the zipped folder and extracting it, we changed the permissions to the files, which it contained so

that we would be able to run them, read them, and write to them. Afterwards we needed to edit the links within

malURL.htm (Figure 4) file that contained two links, both of which redirected you to malicious pages, however we

just needed to edit these links to fit our virtual environments.

Figure 4 Displays the contents of malURL.htm, which will redirect you to the malicious page.

The first one brings you to the setgetcookie.htm, which is where you set your cookie that will be stolen later on; this

page is shown in Figure 5. After setting the cookie and heading back to the malURL.htm page, clicking on the

second link brings you to a .php page that steals the cookie that you just set, in this case it is your name. To verify

that the cookie has been stolen, performing the ‘cat’ function on log.txt reveals that the cookie you entered has been

captured and recorded within this file. Figure 6 shows the stealcookie.php that steals the cookie and puts the stolen

cookie into log.txt.



Figure 5. The process.php file acts as a simulated vulnerability for the web server.

Figure 6. stealcookie.php and its code, which ends up logging the stolen cookie in log.txt.

Results

This project is by no means an efficient or guaranteed way of carrying out a XSS attack. We were able to steal the

cookies, but only because the coding and security of our mock webpage was minimal. Whatever text was input into

the field, we were able to retrieve. All of the files used to carry out the attack, as well as the webpage files, were all

on the same site. If the input cookie in redirectpage.htm were replaced with another site, then the attack would not

have worked. This is because most modern browsers are aware of XSS attacks (older browsers are still vulnerable

however). If we had created a link, which forces the user to first visit a vulnerable site, then we would have a higher

chance of success for an older browser with more protection. Process.php could be utilized to print the values



passed for the username, as well as carrying out the script needed to change the document location to

stealcookie.php. However, as stated, this would do nothing on a newer browser, because they filter out scripts from

links and do not relocate to new sites. XSS attacks can also be prevented implementing proper input validation

before processing a data request. Scripting attacks are still a viable means for hackers to obtain information; they

just have to know how to approach security measures that are in place, as well as how to deliver their own code

Suggested Remedies

Setting Proper File and Directory Permissions Apache is the most frequently used Web server, and while it is true that it is more secure than most available web

servers it is far from being completely secure. The first step that should be taken for hardening a server running

Apache is running an update on the software. By having the latest update, you protect your system against many of

the common bugs and potential exploitations that could occur with hackers trying to manipulate Apache to gain

access to the data on your server. In addition, Apache has the unfortunate habit of displaying the entire contents of

its directories in an index format. You can turn off directory listing, thus preventing an unknown user from having

direct access to all of the files held within that particular directory on the web server, by changing the Options

directive within the Apache files. Apache also uses numerous modules that, if not used by the web server, should be

removed as they offer a potential tool for an attacker to access the server contents. A common issue with many

Apache web servers is not with the server software itself, but with the way it is setup, which can leave it vulnerable

and open to attack; much like the activity done for this project. Berkeley Lab’s Cyber Security department explains

how to properly secure an Apache server, where they discuss the details of proper server configuration.

Figure 7. Removing read permissions for others

Figure 8. Shell injection no longer works after ‘chmod o-r’

Running your apache server, as a super-user is not recommended; a super-user is a user who has access to all

permission and can perform any administrative function. This is also known as the root user and if you are not a

super-user you can invoke a "sudo" command to gain those administrative functions. If you are running Apache as a

super-user then you leave the server vulnerable because an attacker can exploit a bug in Apache and then gain access

to those super-user privileges. This is similar to what was done in the project as we were able to inject shell

commands and access unauthorized information partially due to a lack of permission control. We were able to

mitigate the shell injection performed by simply changing permissions around. For example, in the instructions after

assigning permissions to all files and folders, simply take away read permissions from other users to the main



directory where the site files are located (Figure 7) and anyone is still able to access the page as intended without

being able to inject shell commands into the products query, if attempted only the normal function is processed and

the shell injection is ignored (Figure 8). The only difference is whenever a user wants to invoke any kind of

command while in this directory, they would have to invoke super-user rights with sudo, as shown in Figure 9.

Figure 9. Access within this directory requires ‘sudo’

Keeping all software up-to-date New software releases mean functionality will change, making penetrating or manipulating different versions of

software a new task for hackers. Common implementations can mean newer functions such as security

implementations or upgrades. This in turn make the server and its operating software much more secure. Using

older versions just for the reason of being "familiar" is also something an attacker can rationalize. If it’s an older

version then attackers have had more time to prod and poke at its vulnerabilities and understand the flaws, when you

update the software you may have to stay on your toes to learn the new changes, but so will any potential attacker.

In this exercise we used Apache version 2.2.2 while the latest version is 2.4.1, and for Ubuntu we used version

12.04 while the latest version is 14.04. Both the server and OS used were not up to date and while this didn’t play a

direct role in the issue, it can help facilitate this type of attack.

XSS recommended defenses

There are a number of remedies to cross site-scripting (XSS) attacks depending on the nature of the scripting attack. However, even the most robust defenses cannot completely harden a website to prevent all forms of attack, due to

the fact that any website that requires user input has a potential vulnerability. We can only protect against the

possible malicious user input that we are currently aware of in the world. Some of the general areas to cover in order

to prevent XSS attacks are as follows.

First and foremost is to scan the current system for vulnerabilities to see what is most susceptible to an attack.

Security professionals can gear towards particular defenses depending on the state of the system and code. An

automated scanner should be considered to routinely find vulnerabilities as they appear, especially after taking steps

to secure the system or changes that might occur from policy.

Filtering content is a simple method that can catch keywords as they appear, such as <SCRIPT>, this is

accomplished through some extra code appended to the web application or dedicated libraries. Filters do have the

potential to remove valid input as they are an automated process, so developers and security professionals should

use them at their own discretion (Cross Site Scripting in Action, 2012). Updating resources also means an update to

filters that undergo routine patches.

One of the more potent methods to defend against XSS attacks is implementing escaping methods. Escaping is a

process of telling the browser that data should not be interpreted in any way, thus escaping any scripts that the data

may contain to harm the user (Cross Site Scripting in Action, 2012). These escape mechanisms must be positioned

appropriately according to the web application’s code so that they may still operate without interfering with the

websites functionality itself.

Current state and future strategies

Developers and programmers are partly responsible for the preservation of a system. Security is mostly discarded as

unimportant or unnecessary when compared to customer convenience or speedy deployment, especially at a critical



time like a system’s inception. If at all possible programmers or anyone qualified should gear the system’s design

against XSS attacks. Following simple rules that reflect sound security protocol, such as encoding data by the user,

sanitizing input data, or using filters to expose harmful code (Alani, 2011).

Education would also be a combatant towards XSS attacks. Without knowing what cross-site scripting is there can

be no defense against it. It’s important for developers to understand the nature of cross-site scripting attacks in all its

varying forms, such as reflection or stored attacks. Security needs to be taught, at the least suggested, to aspiring

developers not only to inform, but to foster an understanding that grows with experience in the field (InfoSec

Institute, 2013). There are researchers willing to aid developers with the development process, most often finding

incredible attack vectors before hackers and are willing to share this information to help patch vulnerabilities.

Conclusion

Securing a web server against potential malicious input, and protecting user information, is key to providing optimal

service. Too often though, many security measures and defenses are waylaid in favor for simplicity, and due to extra

overhead traffic on the network. The value for security is frequently ignored when no one is trying to access your

personal information, and only becomes important after an attack has happened. What needs to be understood is that

attacks happen every single day, and at such a large scale that the anonymity that the Internet provides cannot

guarantee that your resources will be protected. Technical literacy has reached a point where SQL injection, XSS, IP

Spoofing, and other attacks can be carried out by anyone with the ability to access Google. This is why information

security is important; it provides a set methodology to hardening, and securing server resources, as demonstrated in

the exercises performed in the scope of this research paper.

In the first research exercise we observed the potential dangers of not securing a web server against malicious user

inputs. Often websites will allow for user input, either to search through a database, or to enable a certain process on

the website. However in some cases, a user can find ways to input code into a website, which is read by the server,

resulting in a breach of security. There are many methods to secure against this type of code injection, but the most

common and effective way is to sanitize user input. Sanitizing, or the process of taking user input and stripping it of

any potential symbols or characters that could be used to insert code, allows for a user to insert data to a website and

automatically filter out the malicious component of any input. Without enabling security procedures that sanitize

input, or similar security processes, the data within the server is vulnerable to manipulation and theft. The second research exercise demonstrated the potential security issues that can occur from stealing session

variables, also known as ‘cookies’. Sessions, a fundamental part of networking and layer 6 of the OSI model, are

fundamental to establishing links between a host and a server. Misfeasors can misuse cookies, by using the data

within them to spoof the server into believing that they are an authenticated user, and access protected resources. In

this exercise we explored how threats like this could occur, using a single server to act as both the valid webserver,

and also the malicious user. While this scenario is not applicable in a real world environment in most cases, due to

the fact that the attacker is rarely the administrator in control of the web server you are accessing. However due to

the fact that users are saving their login information on remote servers in order to access secure websites without

having to constantly enter authentication information, the potential for misuse of session’s variables has increased. Thus, to prevent against such attacks, servers should have authentication processes with a challenge component,

which insures the veracity and integrity of the user.

The purpose of this paper is to analyze potential security vulnerabilities found in server-host interactions that are

replicated in test environments, and used to discern the best methods to prevent such vulnerabilities. By setting up

these exercises in a basic Linux server setup (with Apache, MySQL, and PHP) we can make extrapolations as to the

nature of common security practices, due to the popularity of this technology stack. From this we can determine the



best course of strategy for securing our networks against these common, but often dangerous, attacks. The ultimate

purpose of information security: to observe and analyze the nature of malicious users, and determine the best

method to defend against their attacks.

References

Alanazi, F. (2011). The History of Web Application Security Risks. International Journal of Computer Science and

Information Security, 9(6), 40-47

Brewer, J. (2004). Web server Vulnerabilities Defense in Depth Strategy Squid Proxy. Global Information

Assurance Certification Paper

Cookie Poisoning. (2014, January 1). Retrieved October 21, 2014, from

http://www.imperva.com/Resources/Glossary?term=cookie_poisoning

Cyber Security. (n.d.). Retrieved October 17, 2014, from https://commons.lbl.gov/display/cpp/Securing Apache

WebServers

Cross Site Scripting (XSS) in Action. (2012). Oeconomics of Knowledge, 4(3), 2-2.

Bojinov, H., Bursztein, E., & Boneh, D. (2010). The Emergence of Cross Channel Scripting. Communications Of

The ACM, 53(8), 105-113. doi:10.1145/1787234.1787257

http://www.imperva.com/Resources/Glossary?term=cookie_poisoning

https://commons.lbl.gov/display/cpp/Securing



Wang, H. (2010). Attacks Target Web Server Logic And Prey on XCS Weaknesses. Communications Of The ACM,

53(8), 104. doi:10.1145/1787234.1787256

Frye, E. (2002). The tragedy of the cyber commons: Overcoming fundamental vulnerabilities to critical

infrastructures in a networked world. The Business Lawyer, 58(1), 349-382.

How to Prevent Cross-Site Scripting Attacks - InfoSec Institute. (2013, October 10). Retrieved November 24, 2014,

from http://resources.infosecinstitute.com/how-to-prevent-cross-site-scripting-attacks/

Insecure Storage. (2013, November 28). Retrieved October 21, 2014, from

https://www.owasp.org/index.php/Insecure_Storage

Kanth, S., Jindal, R., & Mishra, S. (2013). Security Issues in Server Virtualization Environment. International

Journal of Advanced Research in Computer Science, 4(0976-5697), 263-270.

Olzak, T. (2006). Web Application Security: Unvalidated Input.

Liu, A., Kovacs, J., Huang, C., & Gouda, M. (2009). A Secure Cookie Protocol.

What is a cookie? (n.d.). Retrieved November 24, 2014, from http://www.microsoft.com/security/resources/cookie-

whatis.aspx

OWASP Top 10 - 2013. (2013).

Sharon D. Nelson, & Simek, J. W. (2007). Data breaches: Damage control after the dam bursts. Gpsolo, 24(5,

Privacy:It's None of Your Business), 54-58.

SQL Injection. (2014, August 14). Retrieved October 21, 2014, from

https://www.owasp.org/index.php/SQL_Injection

Web Parameter Tampering. (2010, March 1). Retrieved October 21, 2014, from

https://www.owasp.org/index.php/Web_Parameter_Tampering

Xie, Y. (2006). Static Detection of Security Vulnerabilities in Scripting Languages. Stanford University.

https://www.usenix.org/legacy/event/sec06/tech/full_papers/xie/xie_html/

Bojinov, H., Bursztein, E., & Boneh, D. (2010). The Emergence of Cross Channel Scripting. Communications Of

The ACM, 53(8), 105-113. doi:10.1145/1787234.1787257

Wang, H. (2010). Attacks Target Web Server Logic and Prey on XCS Weaknesses. Communications Of The ACM,

53(8), 104. doi:10.1145/1787234.1787256

Padmanabhuni B. and Tan H. (2011). “Defending against Buffer Overflow Vulnerabilities.” Retrieved October 20,

2014.

Younan, Y. (2013). "C and C++: Vulnerabilities, exploits and countermeasures." Security Research Group. Retrieved from

http://secappdev.org/handouts/2012/Yves%20Younan/C%20and%20C++%20vulnerabilities.pdf.

Zuchlinski, G. (2003). The Anatomy of Cross-Site Scripting, Anatomy, Discovery, Attack, Exploitation. Retrieved

on November 20, 2014

Shashank G. and Sharma L. (2012). Exploitation of Cross-Site Scripting (XSS) Vulnerability on Real World Web

Applications and its Defense International Journal of Computer Applications (0975 –8887) Volume 60

http://resources.infosecinstitute.com/how-to-prevent-cross-site-scripting-attacks/

http://www.microsoft.com/security/resources/cookie-whatis.aspx

http://www.microsoft.com/security/resources/cookie-whatis.aspx



https://www.owasp.org/index.php/Web_Parameter_Tampering



http://secappdev.org/handouts/2012/Yves%20Younan/C%20and%20C++%20vulnerabilit

Documents

Abstract - · PDF fileEach of the tasks do not have anyone one solution nor does ... values to inject malicious SQL code or ... Berkeley Lab’s Cyber Security